This is a proposal to amend the W3C Process with an Evergreen Recommendation track.
Editors: jeff, plh, ralph, wendy
As of March 21, 2019.
A Working Group or Interest Group charter must include all of the following information.
EdNote: having a date beyond the charter end date provides a clear indication of the intent to not publish the document as a W3C REC in the charter period.
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).
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 @@@.
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 https://www.w3.org/TR.
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.
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.
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.
[INSERT HERE PRETTY AND ACCESSIBLE SVG GRAPH OF THE ER TRACK]
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.
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.
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.
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.
All Technical Reports other than Note have the following properties:
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.
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.
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 public-review-announce@w3.org) 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.
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.
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.
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:
To publish an Evergreen Recommendation, in addition to meeting the general requirements for advancement a Working Group:
Note: Similar to in the W3C Recommendation track, the Chair has a responsibility to ensure the Group operates under consensus. In the Evergreen Recommendation track, it will likely be less likely to issue calls for consensus or assess consensus as a result of a poll of participants; however, the Chair has an important oversight role to ensure that the group's discussions proceed according to the procedural approach chartered for the group, are in accordance with CEPC, and has the responsibility to be an impartial facilitator to decision-making when necessary. Finally, of course, the Chair is the arbiter to whom participants appeal when they disagree with the way that the editors are documenting the evolving consensus of the group. The chair can facilitate discussion between the participant and editor, issue informative calls for consensus, or engage in other discussions to see whether consensus can be reached or whether the editor can adjust their position. Ultimately, the Chair has the authority to overrule the Editor and remove them if necessary.
Note: Appealing to the Director is a last resort and should be avoided. Other inputs, like a review from the TAG, should be seeked before involving the Director.
EdNote: See also ISSUE-34: Role of Director.
Possible next steps for any Evergreen Recommendation:
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: