Labels and Other Metadata for Issues and Pull Requests

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
Affect the degree of resistance to, or protection from, harm of Web technologies.
privacy
Affect the collection, processing and publication of personal data in Web technologies.
a11y
Affect the design of Web technologies for people with disabilities.
i18n
Affect the adaptation of Web technologies to different languages or regional differences.
architecture
Affect the underlying principles that should be adhered to by all Web technologies.
performance
Affect the download and display speed of Web technologies.
device independence
Affect 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.

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

WR-response-drafted
Response to commenter drafted by WG
WR-response-sent
Response send to commenter
WR-commenter-rejected
Response rejected by commenter
WR-commenter-agreed
Response agreed by commenter
WR-commenter-agreed-partial
Response partially agreed by commenter (needs more discussion)
WR-commenter-no-response
No Response received from commenter within the stated period

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".

Projects

Projects describe separate features within a larger specification. Usually, prefer to create a new repository to track greenfield feature development, and take it through the incubation process instead of using a project within an existing spec repository. Even when used, project names are generally not shared between specifications, so we don't list samples here.