This page describes how to use GitHub labels, milestones, and projects in a uniform way across W3C specifications.
Labels
Labels describe the kind of issue or specific work that's needed to advance an issue.Horizontal labels
Those labels are there to facilitate horizontal reviews.
- security
- Affects the degree of resistance to, or protection from, harm of Web technologies.
- privacy
-
Affects the collection, processing and publication of personal data in Web technologies.
- Accessibility
-
Affects the design of Web technologies for people with disabilities.
- Internationalization
-
Affects the adaptation of Web technologies to different languages or regional differences.
- architecture
- Affects the underlying principles that should be adhered to by all Web technologies.
- performance
- Affects the download and display speed of Web technologies.
- device independence
- Affects the ability of Web technologies to function on a wide variety of devices.
Testing and Implementations
Those labels are meant to track testing and implementation status.
- needs tests
- More tests will be needed in this area to exit the Candidate Recommendation state.
- needs implementation
- More implementation experience is needed in this area.
- test:missing-coverage
- More tests will be needed in this area.
Specifications
- editorial
- The reported issue can be addressed with an editorial change. This tag could be combined with others (except
substantive). - substantive
- The reported issue will only be addressed with a substantive change. This tag could be combined with others (except
editorial). - bug
- The specification is broken or misleading and need to change.
- enhancement
- The specification works as-is but could be improved.
- help wanted
- The editor and/or Group need to resolve this issue.
- invalid
- This issue or pull request was declared out of scope.
- duplicate
- This issue or pull request is a duplicate and will be closed if not already closed.
- wontfix
- This issue won't get addressed. Best is to combine this one with others, sich as
invalid. - w3c
- This is used to track non-technical W3C Process related issues, such as transitions.
- Errata
- Erratum for a W3C Recommendation (see w3c/display_errata)
- ErratumRaised
- Raised to become an Erratum later (see w3c/display_errata)
Milestones
Milestones describe the scheduling of bug fixes and changes. Often an issue is labeled with a particular milestone as a way to postpone work on it until after work needed for an earlier milestone.- experiment
- Resolve before experimenting with the new feature on general users.
- migrate
- Resolve before migrating the spec from the WICG to a Working Group.
- FPWD
- Resolve before creating a First Public Working Draft.
- CR
- Resolve before advancing the spec to Candidate Recommendation.
- PR
- Resolve before advancing the spec to Proposed Recommendation.
- REC
- Resolve before advancing the spec to Recommendation.
- level-2
- Work on these issues after the level-1 spec is complete.
- future-work
- Work on these issues at an unspecified time in the future.
Wide Review
1-The WG processes the comment, and provides a resolution.
- WR-open
- Comment received, not yet processed by the WG
- WR-pending
- Discussed but pending WG resolution
- WR-resolved
- WG resolution, (approved by WG)
- WR-spec-updated
- WG resolution and spec updated
- WR-resolved-partial
- Partial WG resolution (partially approved by WG)
- WR-spec-updated-partial
- Partial WG resolution and spec updated
- WR-rejected
- Comment Rejected by WG
For each comment, please fill a "type" with above labels
2-Once the WG has processed all comments, the next steps are to get approval from the commenter
For more information please refer to the TTWG wiki Wide Review page
.Note that groups may work on a level-2 spec concurrently with pushing the level-1 spec through the Recommendation process, so repositories may need milestones like "level-2-CR".