-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document the use of milestones and projects. #27
Conversation
Thank you for the idea, @jyasskin. I personally think that labels should not convey time-sensitive information — milestones and projects are for that. The meaning of “next version” is bound to change as new releases appear. For example, a change may be deemed long-term (thus no label), then planned for an upcoming release (so, “next version”), but overlooked in that release (so, expected for the current release; no label again), etc. Labels, IMHO, should reflect static attributes of items. I find projects are better suited to organise cycles of work. |
That's plausible. Would it make sense to include advice on using projects and milestones in this document? I'd like to be able to point folks to one place to explain how to manage issue metadata in a way that's consistent across web specs. |
@jyasskin: that (documenting good practices about milestones and projects) makes more sense to me, yes. I don't know if W3C groups have enough experience yet managing GH milestones and projects as to put that in writing. Especially the latter. I have seen groups using those features, but I'm not sure that a consistent pattern, or a W3C way of doing things, has emerged yet from that usage. I suspect you know more about this than I do. By all means feel free to draft a section in the FAQ, or something like that. (I suggest you run Thank you again for contributing! |
This moves spec-labels.* to issue-metadata.* so that the documentation for all three kinds of metadata can live together.
Here's a proposal. I'll try to get some feedback from folks who've edited some more specs. |
I've used I think a really useful thing would be to have matching color coding for the labels across repositories, and a script whoever's creating the repo could invoke to create those by default. Worthwhile talking with @marcoscaceres about the repo-scaffolding work he's setting up for WICG. |
@sandhawke also worked on this, suggesting a common set of labels and providing detailed instructions to import that set into a repo: It may be worth merging efforts somehow. |
+1 to merge @sandhawke's labels into this repository, specify colors for labels, and include this set in the repo-generation tools. I'd prefer to make progress on the labels in a different PR, after the structure for milestones and projects is set up in this one. I believe colors aren't relevant for milestones? |
@tobie I've added the rest of the REC-process milestones to the sample list, "future-work" for things that are just vaguely postponed, and a mention that folks might wind up combining "level-2" with a process step to form "level-2-CR", for example. |
LGTM |
Long-lived preview: https://rawgit.com/jyasskin/w3c.github.io/patch-1/issue-metadata.html