This is a proposal to amend the W3C Process with an Evergreen Recommendation track.

Editors: jeff, plh, ralph, wendy

As of March 21, 2019.

5.2.6 Working Group and Interest Group Charters

A Working Group or Interest Group charter must include all of the following information.

See also the charter requirements of section 2 and section 3 of the W3C Patent Policy as well as the @@@ER patent policy.

For each technical report being developed on the Evergreen track, the description of that deliverable in the proposed charter must provide the URL of the W3C GitHub repository for that document.

For every Recommendation or Evergreen Track deliverable that continues work on a Working Draft (WD) published under any other Charter (including a predecessor group of the same name), for which there is an existing Reference Draft, Evergreen Recommendation, or Candidate Recommendation, the description of that deliverable in the proposed charter of the adopting Working Group must provide the following information:

All of the above data must be identified in the adopting Working Group’s charter using the labels indicated.

The Reference Draft is the latest Working Draft published within 90 days of the First Public Working Draft or if no Working Draft has been published within 90 days of the First Public Working Draft it is that First Public Working Draft. It is the specific draft against which exclusions are made, as per section 4.1 of the W3C Patent Policy.

The Adopted Draft and the Exclusion Draft must each be adopted in their entirety and without any modification. The proposed charter must state that Exclusion Draft is deemed to be the Reference Draft or Candidate Recommendation of the Adopted Draft, and the date when the Exclusion Opportunity that arose on publishing the First Public Working Draft or Candidate Recommendation began and ended. As per section 4.3 of the W3C Patent Policy, this potentially means that exclusions can only be made immediately on joining a Working Group.

An Interest Group charter may include provisions regarding participation, including specifying that the only requirement for participation (by anyone) in the Interest Group is subscription to the Interest Group mailing list. This type of Interest Group may have public participants.

A charter may include provisions other than those required by this document. The charter should highlight whether additional provisions impose constraints beyond those of the W3C Process Document (e.g., limits on the number of individuals in a Working Group who represent the same Member organization or group of related Members).

6 W3C Technical Report Development Process

The W3C technical report development process is the set of steps and requirements followed by W3C Working Groups to standardize Web technology. The W3C technical report development process is designed to:

See also the licensing goals for W3C Recommendations in section 2 of the W3C Patent Policy. See licensing goals for W3C Evergreen Recommendations in @@@.

6.1 W3C Technical Reports

Please note that Publishing as used in this document refers to producing a version which is listed as a W3C Technical Report on its Technical Reports page

This chapter describes the formal requirements for publishing and maintaining a W3C Recommendation, Evergreen Recommendation or Note.

Typically a series of Working Drafts are published, each of which refines a document under development to complete the scope of work envisioned by a Working Group's charter. For a technical specification on the Recommendation track, once review suggests the Working Group has met their requirements satisfactorily for a new standard, there is a Candidate Recommendation phase. This allows the entire W3C membership to provide feedback on whether the specification is appropriate as a W3C Recommendation, while the Working Group formally collects implementation experience to demonstrate that the specification works in practice. The next phase is a Proposed Recommendation, to finalize the review of W3C Members. If the Director determines that W3C Member review supports a specification becoming a standard, W3C publishes it as a Recommendation.

For a technical specification on the Evergreen track, once review suggests the Working Group has consensus and met their requirements satisfactory for a new standard, including a level of substantial review, the draft can become an Evergreen Recommendation.

Groups can also publish documents as W3C Notes, typically either to document information other than technical specifications, such as use cases motivating a specification and best practices for its use, or to clarify the status of work that is abandoned.

Some W3C Notes are developed through successive Working Drafts, with an expectation that they will become Notes, while others are simply published. There are few formal requirements to publish a document as a W3C Note, and they have no standing as a recommendation of W3C but are simply documents preserved for historical reference.

Individual Working Groups and Interest Groups should adopt additional processes for developing publications, so long as they do not conflict with the requirements in this chapter.

6.1.1 Recommendations, Evergreen Recommendations, and Notes

A document may be initiated or developed on either the Recommendation track or Evergreen track based on the WG charter.

W3C follows these steps when advancing a technical report to Recommendation.

  1. Publication of the First Public Working Draft,
  2. Publication of zero or more revised Working Drafts.
  3. Publication of a Candidate Recommendation.
  4. Publication of a Proposed Recommendation.
  5. Publication as a W3C Recommendation.
  6. Possibly, Publication as an Edited or Amended Recommendation
Basic W3C Recommendation Track First Public Working Draft (FPWD) - Exclusion opportunity WG decision Director's approval Working Draft (WD) Publish a new Working Draft WG Decision: review needed, or No change for 6 months Advance to Candidate Recommendation Director's approval Candidate Recommendation (CR) - Patent Policy exclusion opportunity Publish revised Candidate Recommendation Working Group Decision, Directors approval Advance to Proposed Recommendation Director's approval Return to Working Draft WG or Director decision e.g. for further review Proposed Recommendation (PR) - Advisory Committee review Advance to Recommendation Advisory Committee Review Director's Decision Return to Candidate Recommendation AC Review, Director Decision e.g. for minor changes Return to Working Draft Advisory Committee review and Director's Decision, e.g. for further work and review Recommendation (Rec)

The Director may decline a request to advance in maturity level, requiring a Working Group to conduct further work, and may require the specification to return to a lower maturity level. The Director must inform the Advisory Committee and Working Group Chairs when a Working Group's request for a specification to advance in maturity level is declined and the specification is returned to a Working Group for further work.

W3C follows these steps when advancing a technical report to Evergreen Recommendation.

  1. Publication of zero or more Preliminary Drafts
  2. Publication of an Evergreen Recommendation


Evergreen Recommendations represent an experimental means of ensuring that standardization keeps up with the Evergreen Web.  This is consistent with what is often called Living Standards, but maintains a role for W3C's traditional values of review (e.g. horizontal view), and have an interaction with W3C's Recommendation track to ensure that W3C's processes such as AC review and Director approval are ultimately addressed.

W3C may end work on a technical report at any time. Transitions between the Evergreen track and W3C Recommendation track

A document previously on the Recommendation track may switch to the Evergreen track if permitted by its charter; typically this happens after Recommendation status, for maintenance.

If permitted by its charter, a document on the Evergreen track may enter the Recommendation track by satisfying the requirements for a WG Working Draft or Candidate Recommendation, and entering as such. Generally, when a WG wants to take a document to the Recommendation track they would first take an ER Snapshot to cement patent commitments to date.

Transition to the REC track does not necessarily mean that specification development as an ER stops because the work is entirely completed.  However moving a snapshot to the REC level provides validation for the work (e.g. complete cross-functional and AC review).There could still be an ER version that is further developed.

A document on the Recommendation track may enter the Evergreen path by satisfying the requirements for a WG Working Draft or Evergreen Recommendation and entering as such, provided that is supported by its charter.

6.1.2 Maturity Levels

Working Draft (WD)
A Working Draft is a document that W3C has published for review by the community, including W3C Members, the public, and other technical organizations. Some, but not all, Working Drafts are meant to advance to Recommendation; see the document status section of a Working Draft for the group's expectations. Any Working Draft not, or no longer, intended to advance to Recommendation should be published as a Working Group Note. Working Drafts do not necessarily represent a consensus of the Working Group, and do not imply any endorsement by W3C or its members beyond agreement to work on a general area of technology.
Candidate Recommendation (CR)
A Candidate Recommendation is a document that satisfies the technical requirements of the Working Group that produced it and their dependencies, or makes substantive corrections to a Recommendation that is not maintained by a Working Group, and has already received wide review. W3C publishes a Candidate Recommendation to
Note: Advancing to Candidate Recommendation indicates that no further improvement is expected without additional implementation experience and testing. A Candidate Recommendation is expected to be as well-written, detailed, self-consistent, and technically complete as a Recommendation, and acceptable as such if and when the requirements for further advancement are met. Announcement of a different next step should include the reasons why the change in expectations comes at so late a stage.
Proposed Recommendation
A Proposed Recommendation is a document that has been accepted by the W3C Director as of sufficient quality to become a W3C Recommendation. This phase triggers formal review by the Advisory Committee, who may recommend that the document be published as a W3C Recommendation, returned to the Working Group for further work, or abandoned. Substantive changes must not be made to a Proposed Recommendation except by publishing a new Working Draft or Candidate Recommendation.
W3C Recommendation (REC)
A W3C Recommendation is a specification or set of guidelines or requirements that, after extensive consensus-building, has received the endorsement of W3C Members and the Director. W3C recommends the wide deployment of its Recommendations as standards for the Web. The W3C Royalty-Free IPR licenses granted under the W3C Patent Policy apply to W3C Recommendations. As technology evolves, a W3C Recommendation may become:
An Edited Recommendation
A Working Group may make editorial or other minor changes to a Recommendation, and produce a new version which W3C publishes as a revised edition of the Recommendation.
An Amended Recommendation
An Amended Recommendation is a Recommendation that is amended to include substantive changes that do not add new features, and is produced by the W3C at a time when the Recommendation does not fit within the charter of any active Working Group. Since the W3C team rather than a Working Group moves it through the Process, there are implications regarding the scope of Royalty-Free IPR licenses granted under the W3C Patent Policy [PUB33].
A Superseded Recommendation
A Superseded Recommendation is a specification that has been replaced by a newer version that the W3C recommends for new adoption. An Obsolete or Superseded specification has the same status as a W3C Recommendation with regards to W3C Royalty-Free IPR Licenses granted under the Patent Policy.
An Obsolete Recommendation
An Obsolete Recommendation is a specification that the W3C has determined lacks sufficient market relevance to continue recommending it for implementation, but which does not have fundamental problems that would require it to be Rescinded. If an Obsolete specification gains sufficient market relevance, the W3C may decide to restore it to Recommendation status.
Rescinded Recommendation
A Rescinded Recommendation is an entire Recommendation that W3C no longer endorses, and believes is unlikely to ever be restored to Recommendation Status. See also clause 10 of the licensing requirements for W3C Recommendations in section 5 of the W3C Patent Policy.
Working Group Note, Interest Group Note (NOTE)
A Working Group Note or Interest Group Note is published by a chartered Working Group or Interest Group to provide a stable reference for a useful document that is not intended to be a formal standard, or to document work that was abandoned without producing a Recommendation.
Preliminary Draft
An Preliminary Draft is a document that W3C has published for review by the community, including W3C Members, the public, and other technical organizations. All Preliminary Drafts are meant to advance to Evergreen Recommendation. Any Preliminary Draft not, or no longer, intended to advance to Evergreen Recommendation should be published as a Working Group Note. Preliminary Drafts do not necessarily represent a consensus of the Working Group.
Evergreen Recommendation (ER)
An Evergreen Recommendation is a document that satisfies the technical requirements of the Working Group that produced it and their dependencies.  The W3C Royalty-Free IPR licenses granted under the @@ER Contribution Commitment policy apply to W3C Evergreen Recommendations. W3C publishes an Evergreen Recommendation to
Evergreen Recommendation Snapshot (ERS)
An Evergreen Recommendation Snapshot is an Evergreen Recommendation under the @@ER Specification Commitment policy.
A Registry document contains an index of labels or constants used for extensibility points found in W3C technical reports. It is an Evergreen Recommendation but not all requirements apply. W3C publishes a Registry to:
  • to prevent accidental collision of labels
  • to document what labels mean
  • to provide mapping information
  • to provide an list of alternatives, and the links to where those alternatives are specified

EdNote: this implies a Registry have Contribution Commitment, which may not be always needed...

Only sufficiently technically mature work should be advanced. Note: Should faster advancement to meet scheduling considerations be desired, this can be achieved by reducing the scope of the technical report to a subset that is adequately mature and deferring less stable features to other technical reports.

When publishing an updated version of an existing Candidate Recommendation or Recommendation, technical reports are expected to meet the same maturity criteria as when they are first published under that status. However, in the interest of replacing stale documents with improved ones in a timely manner, if flaws have been discovered in the technical report after its initial publication as a CR or REC that would have been severe enough to reject that publication had they be known in time, it is also permissible to publish an updated CR or REC following the usual process, even if only some of these flaws have been satisfactorily addressed.

Working Groups and Interest Groups may make available "Editor's drafts". Editor's drafts have no official standing whatsoever, and do not necessarily imply consensus of a Working Group or Interest Group, nor are their contents endorsed in any way by W3C.

6.2 General requirements and definitions

6.2.1 General requirements for Technical Reports

Every document published as part of the technical report development process must be a public document. The index of W3C technical reports is available at the W3C Web site. W3C strives to make archival documents indefinitely available at their original address in their original form.

Every document published as part of the technical report development process must clearly indicate its maturity level, and must include information about the status of the document. This status information

Every Technical Report published as part of the Technical Report development process is edited by one or more editors appointed by a Group Chair. It is the responsibility of these editors to ensure that the decisions of the Group are correctly reflected in subsequent drafts of the technical report. An editor must be a participant, per section 5.2.1 in the Group responsible for the document(s) they are editing.

The Team is not required to publish a Technical Report that does not conform to the Team's Publication Rules(e.g., for naming, status information, style, and copyright requirements). These rules are subject to change by the Team from time to time. The Team must inform group Chairs and the Advisory Committee of any changes to these rules.

The primary language for W3C Technical Reports is English. W3C encourages the translation of its Technical Reports. Information about translations of W3C technical reports is available at the W3C Web site.

6.2.2 Advancement for Technical Reports

All Technical Reports other than Note have the following properties: Advancement on the Recommendation Track

For all requests to advance a specification to a new maturity level other than Note (called "Transition Requests"), the Working Group:

For a First Public Working Draft there is no "previous maturity level", so many requirements do not apply, and approval is normally fairly automatic. For later stages, especially transition to Candidate or Proposed Recommendation, there is usually a formal review meeting to ensure the requirements have been met before Director's approval is given.

Transition Requests to First Public Working Draft or Candidate Recommendation will not normally be approved while a Working Group's charter is undergoing or awaiting a Director's decision on an Advisory Committee Review.

6.2.3 Reviews and Review Responsibilities

A document is available for review from the moment it is first published. Working Groups should formally address any substantive review comment about a technical report in a timely manner.

Reviewers should send substantive technical reviews as early as possible. Working Groups are often reluctant to make substantive changes to a mature document, particularly if this would cause significant compatibility problems due to existing implementation. Working Groups should record substantive or interesting proposals raised by reviews but not incorporated into a current specification. Wide Review

The requirements for wide review are not precisely defined by the W3C Process. The objective is to ensure that the entire set of stakeholders of the Web community, including the general public, have had adequate notice of the progress of the Working Group (for example through notices posted to and were able to actually perform reviews of and provide comments on the specification. A second objective is to encourage groups to request reviews early enough that comments and suggested changes can still be reasonably incorporated in response to the review. Wide Review for the Recommendation Track

Before approving transitions, the Director will consider who has been explicitly offered a reasonable opportunity to review the document, who has provided comments, the record of requests to and responses from reviewers, especially W3C Horizontal Groups and groups identified as dependencies in the charter or identified as liaisons, and seek evidence of clear communication to the general public about appropriate times and which content to review and whether such reviews actually occurred.

For example, inviting review of new or significantly revised sections published in Working Drafts, and tracking those comments and the Working Group's responses, is generally a good practice which would often be considered positive evidence of wide review. Working Groups should announce to other W3C Working Groups as well as the general public, especially those affected by this specification, a proposal to enter Candidate Recommendation (for example in approximately 28 days). By contrast a generic statement in a document requesting review at any time is likely not to be considered as sufficient evidence that the group has solicited wide review.

A Working Group could present evidence that wide review has been received, irrespective of solicitation. But it is important to note that receiving many detailed reviews is not necessarily the same as wide review, since they might only represent comment from a small segment of the relevant stakeholder community. Wide Review for the Evergreen Track

Operating on the Evergreen track necessitates pragmatic compromises between full wide review and the exigencies of an Evergreen web.  It is generally expected that Evergreen Recommendations have reached out to achieve wide review.  But it is also recognized that reviewers cannot always operate on that time scale.  So a measure of wide review is expected throughout the Evergreen track, and W3C confers status to those documents.  Yet it is still expected that those documents will ultimately move to the Recommendation track to achieve a more complete wide review, horizontal review, AC review, and Director approval.

6.10 Preliminary Draft

An Preliminary Draft is published on the W3C's Technical Reports page for review, and for simple historical reference. For all Preliminary Drafts a Working Group:

A Working Group should publish an Preliminary Draft to the W3C Technical Reports page when there have been significant changes to the previous published document that would benefit from review beyond the Working Group.

If 6 months elapse without significant changes to a specification a Working Group should publish a revised Preliminary Draft, whose status section should indicate reasons for the lack of change.

To publish a revision of an Preliminary draft, a Working Group:

Possible next steps for any Preliminary Draft:

6.11 Evergreen Recommendation

To publish an Evergreen Recommendation, in addition to meeting the general requirements for advancement a Working Group:

  • In rare occurences, an individual may register a Formal Objection to a decision. The Group:

    Possible next steps for any Evergreen Recommendation:

    6.11.1 Evergreen Recommendation Snapshot

    All Evergreen Recommendation other than Registries must be published as a revised Evergreen Recommendation Snapshot if 24 months elapse with significant changes to ensure they get a thorough IPR review as per the @@@ER patent policy.

    To publish an Evergreen Recommendation Snapshot, in addition to meeting the requirements for Evergreen Recommendation a Working Group:

    • must record the group's decision to request advancement.