7 W3C Recommendation Track Process (original) (raw)

On 1 August 2014, W3C began a transition away from this document; see the current W3C Process Document.

W3C Process Document

The Recommendation Track process is the set of steps and requirements followed by W3C Working Groups to standardize Web technology. The processes followed by a Working Group to manage specifications and guidelines -- called technical reports in this section -- include:

The W3C Recommendation Track process is designed to maximize consensus about the content of a technical report, to ensure high technical and editorial quality, and to earn endorsement by W3C and the broader community.

The following sections describe:

Maturity levels are described first, followed by the steps on the Recommendation Track and the requirements for each step.

7.1 Recommendation Track Process Maturity Levels

The maturity level of a published technical report indicates its place in the Recommendation Track process. The maturity levels "Working Draft" and "Working Group Note" represent the possible initial states of a technical report in the Recommendation Track process. The maturity levels "Recommendation", "Working Group Note", and "Rescinded Recommendation" represent the possible end states.

7.1.1 Maturity Levels When Advancing a Technical Report Towards Recommendation

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.

Candidate Recommendation (CR)

A Candidate Recommendation is a document that W3C believes has been widely reviewed and satisfies the Working Group's technical requirements. W3C publishes a Candidate Recommendation to gather implementation experience.

Proposed Recommendation (PR)

A Proposed Recommendation is a mature technical report that, after wide review for technical soundness and implementability, W3C has sent to the W3C Advisory Committee for final endorsement.

W3C Recommendation (REC)

A W3C Recommendation is a specification or set of guidelines that, after extensive consensus-building, has received the endorsement of W3C Members and the Director. W3C recommends the wide deployment of its Recommendations.Note: W3C Recommendations are similar to the standards published by other organizations.

7.1.2 Maturity Level When Ending Work on a Technical Report

Working Group Note

A Working Group Note is published by a chartered Working Group to indicate that work has ended on a particular topic. A Working Group MAY publish a Working Group Note with or without its prior publication as a Working Draft. W3C MAY also publish "Interest Group Notes" and "Coordination Group Notes" for similar publications by those types of groups. Interest Groups and Coordination Groups do not create technical reports that advance toward Recommendation.

Note: To avoid confusion in the developer community and the media about which documents represent the output of chartered groups and which documents are input to W3C Activities (Member Submissions and Team Submissions), W3C plans to stop using the unqualified maturity level "Note."

7.1.3 Maturity Level When Editing a Recommendation

Proposed Edited Recommendation

A Proposed Edited Recommendation is a technical report that W3C has published for community review of important changes, some of which may affect conformance. When there is consensus about the edits, the document is published as a Recommendation.

7.1.4 Maturity Levels When Rescinding a Recommendation

Rescinded Recommendation

A Rescinded Recommendation is an entire Recommendation that W3C no longer endorses.

7.2 General Requirements for Advancement

A Working Group MUST fulfill certain requirements in order to qualify for each step towards Recommendation.

For publication of first public Working Draft up to but not including publication as a Recommendation, the Working Group MUST record the group's decision to request advancement.

For a Last Call announcement up to and including publication as a Recommendation, the Working Group MUST:

  1. Indicate whether the document has been modified substantively since the previous step. A substantive change (whether deletion, inclusion, or other modification) is one where someone could reasonably expect that making the change would invalidate an individual's review or implementation experience. Other changes (e.g., clarifications, bug fixes, editorial repairs, and minor error corrections) are minor changes. A Working Group MUST document changes (both substantive and minor) between steps.
  2. Fulfill the relevant requirements of the Working Group charter and those of any accompanying requirements documents, or report which relevant requirements have not been fulfilled. For relevant requirements that have not been fulfilled, the Working Group MUST provide rationale to the satisfaction of the Director.
  3. Indicate which dependencies with other groups the Working Group believes it has satisfied, and report which dependencies have not been satisfied.
  4. Show evidence of wide review.
  5. Formally address all issues raised about the document since the previous step. In practice, once a Working Group wishes to advance to Candidate Recommendation or beyond, the Director expects positive documentation that issues have been formally addressed (e.g., in an issues list that shows their disposition). For earlier stages on the Recommendation Track, less formal documentation generally suffices (e.g., evidence in an archived mailing list).
  6. Indicate any formal objections.

The following information is important to the decision to advance a technical report and therefore MUST be publicly available:

7.3 Reviews and Review Responsibilities

Experience shows that the following help build consensus around technical reports:

  1. Frequent publication (see the three-month rule).
  2. Early review, to find errors quickly and decrease the chances of diverging technologies.
  3. Wide review, including from other groups in and outside of W3C.

A document receives review from the moment it is first published. Starting with the first publication through the end of a Proposed Recommendation review, a Working Group MUST formally address _any_substantive review comment about a technical report and SHOULD do so in a timely manner. However, reviewersSHOULD NOT send substantive technical reviews late on the Recommendation track. Reviewers SHOULD NOTexpect that a Working Group will readily make substantive changes to a mature document. The more evidence a Working Group can show of wide review, the less weight substantive comments will carry when provided late on the Recommendation Track. Worthy ideas SHOULD BE recorded even when not incorporated into a mature document.

The Working Group MUST be able to show evidence of having attempted to respond to and satisfy reviewers. Reviewers MAY register a formal objection any time they are dissatisfied with how a Working Group has handled an issue.

A Working Group SHOULD negotiate review schedules with other groups expected to review a document, including relevantliaisons.

There are two formal review periods with fixed durations when advancing to Recommendation: after a Last Call announcement and after a Call for Review of a Proposed Recommendation. Out of consideration for the Working Group, reviewersSHOULD send their comments early in a review period. A Working Group SHOULD NOT start a new review before the scheduled end of an ongoing review (e.g., do not start a new Last Call review before the scheduled end of an ongoing Last Call review).

Ordinarily, reviewers SHOULD NOT raise substantive technical issues about a technical report after the end of a Last Call review period. However, this does occur, and as stated above, a Working Group's requirement to formally address those issues extends until the end of a Proposed Recommendation review period. However, to allow the Working Group to make progress on a technical report, the Working Group MAY decline to make substantive changes to address issues raised between the end of a Last Call review period and publication of a Recommendation. A reviewer MAY register a formal objection.

Advisory Committee representatives SHOULD NOT(but MAY) raise new substantive technical issues during a Proposed Recommendation review period. The Working Group MAY respond to the reviewer after the close of the Proposed Recommendation review period. Note: It may be necessary to change confidentiality level when conveying issues raised by Advisory Committee representatives to the Working Group.

During review by the Members, the Working Group SHOULD also formally address informed and relevant issues raised outside the Advisory Committee (e.g., by the public or another W3C Working Group), and report them to the Director in a timely fashion.

When a Working Group receives a substantive issue after the end of Proposed Recommendation review period, the Working Group MUST respond to the reviewer but MAY decline to formally address the issue. In this case, the Working Group MAY consider the issue as part of tracking errata.

7.4 Advancing a Technical Report to Recommendation

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

  1. Publication of the first public Working Draft.
  2. Last Call announcement
  3. Call for Implementations. Note: The Director MAY permit the Working Group to skip this step if the entrance criteria for the next step have already been satisfied.
  4. Call for Review of a Proposed Recommendation.
  5. Publication as a Recommendation.

In general, Working Groups embark on this journey with the intent of publishing one or more Recommendations. However, W3C MAY end work on a technical reportat any time, or MAY require a Working Group to conduct further work, possibly repeating one or more steps.

Between publication of the first public Working Draft and Last Call announcement, a Working Group publishes revisions that generally include substantive changes. Between any two steps after a Last Call announcement, the Working Group MAY publish a new draft of the technical report at the same maturity level provided there are no substantive changes since the earlier step.

The Team MUST notify the Advisory Committee and other W3C groups of a revision to a Candidate Recommendation or Proposed Recommendation.

These steps of the Recommendation Track process can take considerable time, so participants are encouraged to read the tips on getting to Recommendation faster [PUB27].

Refer to "How to Organize a Recommendation Track Transition" in the Member Guide for practical information about preparing for the reviews and announcements of the various steps.

7.4.1 First Public Working Draft

Document maturity level: Working Draft.

Announcement: The Director MUST announce the first Working Draft publication to other W3C groups and to the public.

Purpose: The publication of the first public Working Draft is a signal to the community to begin reviewing the document.

Entrance criteria: Director approval is REQUIRED in order for a Working Group to publish a first public Working Draft (or version for review beyond the membership, e.g., if another organization has been asked to review a draft that is not yet public).

Ongoing work: Once a Working Draft has been published, the Working Group continues to publish revisions; see the three-month rule.

In order to make Working Drafts available to a wide audience early in their development, the requirements for publication of a Working Draft are limited to an agreement by a chartered Working Group to publish the technical report and satisfaction of the Team's Publication Rules [PUB31]. Consensus is not a prerequisite for approval to publish; the Working Group MAY request publication of a Working Draft even if it is unstable and does not meet all Working Group requirements.

Working Groups SHOULD encourage early and wide review of the technical report, within and outside of W3C, especially from other Working Groups with dependencies on the technical report. Advisory Committee representatives SHOULD encourage review within their organizations as early as first public Working Draft, i.e., before a Last Call announcement and well before a Call for Review of a Proposed Recommendation.

The Working Group SHOULD be responsive to and facilitate ongoing review by addressing issues in a timely manner and clearly indicating changes between drafts (e.g., by providing "diffs" and summaries of important changes).

Possible next steps:

7.4.2 Last Call Announcement

Document maturity level: Working Draft.

Announcement: The Working Group MUST announce the Last Call to other W3C groups and to the public.

Purpose: A Working Group's Last Call announcement is a signal that:

In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels.

A Working Group SHOULD work with other groups prior to a Last Call announcement to reduce the risk of surprise at Last Call.

Ideally, after a Last Call announcement, a Working Group receives only indications of support for the document, with no proposals for substantive change. In practice, Last Call announcements generate comments that sometimes result in substantive changes to a document. A Working Group SHOULD NOT assume that it has finished its work by virtue of issuing a Last Call announcement.

Entrance criteria: Before announcing a Last Call, the Working Group MUST have fulfilled the general requirements for advancement.

A Last Call announcement MUST:

  1. specify the deadline for review comments;
  2. identify known dependencies and solicit review from all dependent Working Groups;
  3. solicit public review.

Duration of the review: The announcement begins a review period that SHOULD last at least three weeks but MAY last longer if the technical report is complex or has significant external dependencies.

Ongoing work: During the review period, the Working Group solicits and responds to comments from the Team, the Members, other W3C groups, and the public.

It is important to ensure the proper integration of a technical report in the international community. Starting at this step in the Recommendation process, the technical report SHOULD include a statement about how the technology relates to existing international standards and to related work outside of W3C.

Possible next steps:

7.4.3 Call for Implementations

Document maturity level: Candidate Recommendation.

Announcement: The Director MUST announce the Call for Implementations to the Advisory Committee.

Purpose: At this step, W3C believes the technical report is stable and appropriate for implementation. The technical report MAY still change based on implementation experience.

Entrance criteria: The Director calls for implementation when satisfied that the Working Group has fulfilled the general requirements for advancement.

The Working Group is NOT REQUIRED to show that a technical report has two independent and interoperable implementations as part of a request to the Director to announce a Call for Implementations. However, the Working Group SHOULD include a report of present and expected implementations as part of the request.

In the Call for Implementations, the Working Group MAY identify specific features of the technical report as being "features at risk." General statements such as "We plan to remove any unimplemented feature" are not acceptable; the Working Group MUST precisely identify any features at risk. Thus, in response to a Call for Implementations, reviewers can indicate whether they would formally object to the removal of the identified features.

After gathering implementation experience, the Working Group MAY remove features from the technical report that were identified as being "at risk" and request that the Director Call for Review of a Proposed Recommendation. If the Working Group makes othersubstantive changes to the technical report, the Director MUST return it to the Working Group for further work.

The request to the Director to advance a technical report to Candidate Recommendation MUST indicate whether the Working Group expects to satisfy any Proposed Recommendation entrance criteria beyond the default requirements (described below).

Advisory Committee representatives MAY appeal the decision to advance the technical report.

Duration of the implementation period: The announcement MUST indicate a minimal duration, before which the Working Group MUST NOT request a Call for Review of a Proposed Recommendation; this minimal duration is designed to allow time for comment. The announcement SHOULD also include the Working Group's estimate of the time expected to gather sufficient implementation data.

Possible next steps:

7.4.4 Call for Review of a Proposed Recommendation

Document maturity level: Proposed Recommendation.

Announcement: The Director MUST announce the call for review to the Advisory Committee.

Purpose: At this step, W3C seeks endorsement of the stable technical report. The outcome of this review is taken as an indication of the organization's support for the technical report.

Entrance criteria: The Director calls for review when satisfied that the Working Group has:

  1. Fulfilled the general requirements for advancement;
  2. Shown that each feature of the technical report has been implemented. Preferably, the Working Group SHOULD be able to demonstrate two interoperable implementations of each feature. If the Director believes that immediate Advisory Committee Review is critical to the success of a technical report, the Director MAY accept to Call for Review of a Proposed Recommendation even without adequate implementation experience;
  3. Satisfied any other announced entrance criteria (e.g., any included in the request to advance to Candidate Recommendation, or announced at Last Call if the Working Group does not intend to issue a Call for Implementations).

Advisory Committee representatives MAY appeal the decision to advance the technical report.

Duration of the review: The announcement begins a review period that MUST last at least four weeks.

Ongoing work: During the review period, the Working Group requests endorsement and support from Members (e.g., testimonials as part of a press release).

Possible next steps:

7.4.5 Publication of a W3C Recommendation

Document maturity level: Recommendation.

Announcement: The Director MUST announce the publication of a W3C Recommendation to the Advisory Committee.

Purpose: W3C publishes Recommendations when it believes that the ideas in the technical report are appropriate for widespread deployment and that they promote W3C's mission.

Entrance criteria: The Director publishes a W3C Recommendation when satisfied that there is significant support for the technical report from the Advisory Committee, the Team, W3C Working Groups, and the public. The decision to advance a document to Recommendation is a W3C decision.

If there was any dissent during the Member review, Advisory Committee representatives MAY appeal the decision to publish the Recommendation.

Possible next steps:

The Director MAY submit a W3C Recommendation to another standards body for adoption and formal approval by that body.

7.4.6 Returning a Document to a Working Group for Further Work

A technical report is returned to a Working Group for further work in either of the following situations:

  1. The Working Group makes substantive changes to the technical report at any time after a Last Call announcement and prior to Publication as a Recommendation,except when the changes involve the removal of features at risk identified in a Call for Implementations. In the case of substantive changes, the Working Group MUST republish the technical report as a Working Draft.
  2. The Director requires the Working Group to address important issues raised during a review or as the result of implementation experience. In this case, Director MAY request that the Working Group republish the technical report as a Working Draft, even if the Working Group has not made substantive changes.

The Director MUST inform the Advisory Committee and group Chairs when a technical report has been returned to a Working Group for further work.

After republication as a Working Draft, the next forward step available to the Working Group is a Last Call announcement. The Last Call announcement MAY occur at the same time as the publication of the Working Draft.

The Director MAY ask the Working Group to republish a technical report as a Candidate Recommendation. At the same time as publication, the Director issues a Call for Implementations.

7.5 Ending Work on a Technical Report

Work on a technical report MAY cease at any time. When a Working Group completes its work on a technical report, it publishes it either as a Recommendation or a Working Group Note. For example, a Working Group might publish several Working Drafts of a requirements document, and then indicate that it no longer plans to work on the requirements document by publishing a Working Group Note.

Work MAY also cease because W3C determines that it cannot productively carry the work any further. For instance, the Director might close a Working Group, the participants might lose interest in a technical report, or the ideas might be subsumed by another technical report. If W3C decides to discontinue work on a technical report before completion, the technical report SHOULD be published as a Working Group Note.

Possible next steps:

7.6 Modifying a W3C Recommendation

W3C makes every effort to maintain its Recommendations (e.g., by tracking errata, providing testbed applications, and helping to create test suites) and to encourage widespread implementation. The following sections discuss the management of errors and the process for making normative changes to a Recommendation.

7.6.1 Errata Management

Tracking errors is an important part of a Working Group's ongoing care of a Recommendation; for this reason, the scope of a Working Group charter generally allows time for work after publication of a Recommendation. In this Process Document, the term "erratum" (plural "errata") refers to any class of mistake, from mere editorial to a serious error that may affect the conformance with the Recommendation by software or content (e.g., content validity).Note: Before a document becomes a Recommendation, an important change is called a substantive change and relates to the impact of the change on earlier review. After a document has been published as Recommendation, an important change is one that relates to the conformance of content or deployed software.

Working Groups MUST track errata on an "errata page." An errata page is a list of enumerated errors, possibly accompanied by corrections. Each Recommendation links to an errata page; see the Team's Publication Rules.

A correction is first "proposed" by the Working Group. A correction becomes normative -- of equal status as the text in the published Recommendation -- through one of the processes described below. An errata page MAY include both proposed and normative corrections. The Working Group MUST clearly identify which corrections are proposed and which are normative.

A Working Group SHOULD keep their errata pages up-to-date, as errors are reported by readers and implementers. A Working GroupMUST report errata page changes to interested parties, notably when corrections are proposed or become normative, according to the Team's requirements. For instance, the Team might set up a mailing list per Recommendation where a Working Group reports changes to an errata page.

7.6.2 Classes of Changes to a Recommendation

This document distinguishes the following classes of changes to a Recommendation.

1. No changes to text content

These changes include fixing broken links or invalid markup.

2. Corrections that do not affect conformance

Editorial changes or clarifications that do not change the technical content of the specification.

3. Corrections that MAY affect conformance, but add no new features

These changes MAY affect conformance to the Recommendation. A change that affects conformance is one that:

  1. turns conforming data, processors, or other conforming agents into non-conforming agents, or
  2. turns non-conforming agents into conforming ones, or
  3. clears up an ambiguity or underspecified part of the specification in such a way that an agent whose conformance was once unclear becomes clearly conforming or non-conforming.

4. New features

For new features, W3C follows the full process of advancing a technical report to Recommendation.

The first two classes of change require no technical review of the proposed changes, although a Working Group MAY call for review. The modified Recommendation is published according to the Team's requirements, including Publication Rules [PUB31].

For the third class of change, W3C requires:

  1. Review by the community to ensure the technical soundness of proposed corrections.
  2. Timely publication of the edited Recommendation, with corrections incorporated.

For the third class of change, the Working Group MUST either:

  1. Request that the Director issue a Call for Review of an Edited Recommendation, or
  2. Issue a Call for Review of Proposed Corrections that have not been incorporated into an edited draft (e.g., those listed on an errata page). After this review, the Director MAY announce that the proposed corrections are normative.

While the second approach is designed so that a Working Group can establish normative corrections quickly, it does not obviate the need to incorporate changes into an edited version of the Recommendation. In particular, when corrections are numerous or complex, integrating them into a single document is important for interoperability; readers might otherwise interpret the corrections differently.

7.6.3 Call for Review of an Edited Recommendation

Document maturity level: Proposed Edited Recommendation.

Announcement: The Director MUST announce the call for review to other W3C groups, the public, and the Advisory Committee.

Purpose: At this step, W3C seeks confirmation of proposed corrections to a Recommendation.

Entrance criteria: The Director calls for review when satisfied that, with respect to changes to the document, the Working Group has fulfilled the same entrance criteria as for a Call for Review of a Proposed Recommendation (e.g., the Working Group can show implementation experience that supports the changes). In the request to advance to this status, the Working Group MUST report any substantive issues about the technical report that have not been resolved.

The announcement MUST fulfill the same requirements as a Last Call announcement and MUST clearly indicate that this is a proposal to edit a Recommendation.

Advisory Committee representatives MAY appeal the decision to advance the technical report.

Duration of the review: The announcement begins a review period that MUST last at least four weeks.

Ongoing work: Same as for a Last Call review.

Possible next steps:

7.6.4 Call for Review of Proposed Corrections

Document maturity level: A Recommendation, plus a list of proposed corrections. The Working Group SHOULD also include a detailed description of how the Working Group plans to change the text of the Recommendation for each proposed correction.

Announcement: The Working Group MUST announce the call for review to other W3C groups, the public, and the Advisory Committee.

Purpose: At this step, W3C seeks confirmation of proposed corrections to a Recommendation.

Entrance criteria: The Working Group calls for review when, with respect to changes to the document, the group has fulfilled the same entrance criteria as for a Call for Review of a Proposed Recommendation.

The announcement MUST fulfill the same requirements as a Last Call announcement and MUST clearly indicate that this is a proposal to make normative corrections to the Recommendation.

Duration of the review: The announcement begins a review period that MUST last at least four weeks.

Ongoing work: Same as for a Last Call review.

If there are no formal objections to the proposed corrections, W3C considers them normative. The Working Group MUST report formal objections to the Director, who assesses whether there is sufficient consensus to declare the proposed corrections to be normative.

Possible next steps:

7.7 Rescinding a W3C Recommendation

At times, W3C MAY rescind an entire Recommendation, for instance when W3C learns of significant errors in the Recommendation, when the Recommendation becomes outdated, or if W3C discovers burdensome patent claims that affect implementers.

To deprecate part of a Recommendation, W3C follows the process formodifying a Recommendation.

Once W3C has published a Rescinded Recommendation, future W3C technical reports MUST NOT include normative references to that technical report.

7.7.1 Proposal to Rescind a Recommendation

Document maturity level: Recommendation, plus separate rationale for the proposal to rescind.

Announcement: The Director MUST announce the Proposal to Rescind a Recommendation to other W3C groups, the public, and theAdvisory Committee.

Purpose: At this step, W3C seeks confirmation of a Proposal to Rescind a Recommendation.

Entrance criteria: The Director proposes that W3C rescind a Recommendation when satisfied that there is sufficient reason.

The announcement MUST fulfill the same requirements as a Last Call announcement and MUST clearly indicate that this is a Proposal to Rescind a Recommendation.

Advisory Committee representatives MAY appeal the proposal to rescind the Recommendation.

Duration of the review: The announcement begins a review period that MUST last at least four weeks.

Ongoing work: Same as for a Last Call review.

Possible next steps:

7.7.2 Publication of a Rescinded Recommendation

Document maturity level: Rescinded Recommendation.

Announcement: The Director MUST announce the Publication of a Rescinded Recommendation to the Advisory Committee.

Purpose: At this step, W3C indicates that it no longer endorses a previously published Recommendation.

Entrance criteria: The Director publishes a Rescinded Recommendation when satisfied that there is significant support from the Advisory Committee, the Team, W3C Working Groups, and the public. The decision to advance a document to Rescinded Recommendation is a W3C decision.

The Team MAY publish one or more documents in order to best communicate what has been rescinded and its relation to previous Recommendations (e.g., the publication can be as simple as a cover sheet that refers to a previously published Recommendation).

If there was any dissent in the Proposed Rescinded Recommendation reviews, Advisory Committee representativesMAY appealthe decision to rescind the Recommendation.

Possible next step:

7.8 General Information about Technical Reports

Every document published as part of the Recommendation Track process MUST be a public document. The list of W3C technical reports [PUB11] is available at the W3C Web site. W3C will make every effort to make archival documents indefinitely available at their original address in their original form.

Every document published as part of the Recommendation Track process MUST clearly indicate its maturity level.

Every technical report published as part of the Recommendation Track process is edited by one or more editors appointed by a Working 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. Editors areNOT REQUIRED to be part of the Team.

The Team is NOT REQUIRED to publish a technical report that does not conform to the Team's Publication Rules (e.g., for naming, style, and copyright requirements). These rules are subject to change. The Team MUSTinform group Chairs and the Advisory Board of any changes.

The Team reserves the right to reformat technical reports at any time so as to conform to changes in W3C practice (e.g., changes to technical report styles or the document status section).

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

7.8.1 Document Status Section

Each technical report MUST include a section about the status of the document. The status section SHOULD explain why W3C has published the technical report, expectations about next steps, who developed it, where to send comments about it, whether implementation experience is being sought, any significant changes from the previous version, why work on the technical report has ceased or been subsumed, and any other relevant information or rationale.

The Team's Publication Rulesinclude status section requirements for each maturity level.