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

Specifications

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.