Editor's draft proposed new W3C Process Document

7 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 [PUB33].

Table of Contents

7.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 http://www.w3.org/TR.

This chapter describes the formal requirements for publishing and maintaining a W3C 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, 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 should become 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.

Groups may 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 may adopt additional processes for developing publications, so long as they do not conflict with the requirements in this chapter.

7.1.1 Recommendations and Notes

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 Public 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 Recommendation

First WD WD CR PR REC

W3C may end work on a technical report at any time.

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.

7.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 Working Group's technical requirements, and has already received wide review. W3C publishes a Candidate Recommendation to
Note: Candidate Recommendations are expected to be acceptable as Recommendations. 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 establishes a deadline for the Advisory Committee review which begins with Candidate Recommendation. 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 Patent Policy apply to W3C Recommendations.
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.
Rescinded Recommendation
A Rescinded Recommendation is an entire Recommendation that W3C no longer endorses. See also clause 10 of the licensing requirements for W3C Recommendations in section 5 of the W3C Patent Policy [PUB33].

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.

7.2 General requirements and definitions

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 http://www.w3.org/TR.

7.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 [PUB11] 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, as a Member representative, Team representative, or Invited Expert 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 [PUB18] is available at the W3C Web site.

7.2.2 Advancement on the Recommendation Track

For all requests to advance a specification to a new maturity level other than Note 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 generally a formal review meeting to ensure the requirements have been met before Director's approval is given.

7.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.
7.2.3.1 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 and thereby an opportunity to comment on the specification. 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 groups identified as dependencies in the charter, and seek evidence of clear communication to the general public about appropriate times and which content to review.

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 four weeks). 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 may only represent comment from a small segment of the relevant stakeholder community.

7.2.4 Implementation Experience

Implementation experience is required to show that a specification is sufficiently clear, complete, and relevant to market needs, to ensure that independent interoperable implementations of each feature of the specification will be realized. While no exhaustive list of requirements is provided here, when assessing that there is adequate implementation experience the Director will consider (though not be limited to):

Planning and accomplishing a demonstration of (interoperable) implementations can be very time consuming. Groups are often able to work more effectively if they plan how they will demonstrate interoperable implementations early in the development process; for example, they may wish to develop tests in concert with implementation efforts.

7.2.5 Classes of Changes

This document distinguishes the following 4 classes of changes to a specification. The first two classes of change are considered editorial changes, the latter two substantive changes.

1. No changes to text content
These changes include fixing broken links, style sheets 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 do not add new features
These changes may affect conformance to the specification. A change that affects conformance is one that:
4. New features

7.3 Working Draft

A Public Working Draft is published on the W3C's Technical Reports page [TR] for review, and for simple historical reference. For all Public Working Drafts a Working Group

7.3.1 First Public Working Draft

To publish the First Public Working Draft of a document, a Working Group must meet the applicable general requirements for advancement.

The Director must announce the publication of a First Public Working Draft publication to other W3C groups and to the public.

Publishing the First Public Working Draft triggers a Call for Exclusions, per section 4 of the W3C Patent Policy [PUB33].

7.3.2 Revising Public Working Drafts

A Working Group should publish a Working 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 Working Draft, whose status section should indicate reasons for the lack of change.

To publish a revision of a Working draft, a Working Group

Possible next steps for any Working Draft:

7.3.3 Stopping Work on a specification

Work on a technical report may cease at any time. Work should cease if W3C or a Working Group determines that it cannot productively carry the work any further. If the Director closes a Working Group W3C must publish any unfinished specifications on the Recommendation track as Working Group Notes. If a Working group decides, or the Director requires, the Working Group to discontinue work on a technical report before completion, the Working Group should publish the document as a Working Group Note.

7.4 Candidate Recommendation

To publish a Candidate recommendation, in addition to meeting the general requirements for advancement a Working Group:

The Director must announce the publication of a Candidate Recommendation to other W3C groups and to the public, and must begin an Advisory Committee Review on the question of whether W3C should publish the specification as a W3C Recommendation.

A Candidate Recommendation corresponds to a "Last Call Working Draft" as used in the W3C Patent Policy [PUB33]. Publishing a Candidate Recommendation triggers a Call for Exclusions, per section 4 of the W3C Patent Policy [PUB33].

Possible next steps:

If there was any dissent to the Working Group decision to request advancement Advisory Committee representatives may appeal the decision to advance the technical report.

7.4.1 Revising a Candidate Recommendation

If there are any substantive changes made to a Candidate Recommendation other than to remove features explicitly identified as "at risk", the Working Group must obtain the Director's approval to publish a revision of a Candidate Recommendation. This is because substantive changes will generally require a new Exclusion Opportunity per section 4 of the W3C Patent Policy [PUB33]. Note that approval is expected to be fairly simple compared to getting approval for a transition from Working Draft to Candidate Recommendation.

In addition the Working Group:

The Director must announce the publication of a revised Candidate Recommendation to other W3C groups and the Public.

7.5 Proposed Recommendation

In addition to meeting the general requirements for advancement,

A Working Group:

The Director:

Since a W3C Recommendation must not include any substantive changes from the Proposed Recommendation it is based on, to make any substantive change to a Proposed Recommendation the Working Group must return the specification to Candidate Recommendation or Working Draft.

Possible Next Steps:

7.6 W3C Recommendation

The decision to advance a document to Recommendation is a W3C Decision.

In addition to meeting the general requirements for advancement,

Possible next steps:

A W3C Recommendation normally retains its status indefinitely. However it

7.7 Modifying a W3C Recommendation

This section details the management of errors in, and the process for making changes to a Recommendation. Please see also the Requirements for modification of W3C Technical Reports [PUB35].

WD CR PR REC Changes to text Substantivechanges? No Yes NewFeatures? No First WD Yes

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

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 part of the Recommendation by the process for Revising a Recommendation described in the next section.

A Working Group should keep their errata pages up-to-date, as errors are reported by readers and implementers. A Working Group must report errata page changes to interested parties, notably when corrections are proposed or incorporated into an Edited Recommendation, according to the Team's requirements.

7.7.2 Revising a Recommendation

A Working group may request republication of a Recommendation, or W3C may republish a Recommendation, to make corrections that do not result in any changes to the text of the specification.

Editorial changes to a Recommendation require no technical review of the proposed changes. A Working Group may request publication of a Proposed Recommendation  or W3C may publish a Proposed Recommendation to make this class of change without passing through earlier maturity levels. Such publications are may be called a Proposed Edited Recommendation.

To make corrections to a Recommendation that produce substantive changes but do not add new features, a Working Group may request publication of a Candidate Recommendation, without passing through earlier maturity levels.

In the latter two cases, the resulting Recommendation may be called an Edited Recommendation.

When requesting the publication of an edited Recommendation as described in this section, in addition to meeting the requirements for the relevant maturity level, a Working Group

For changes which introduces a new feature or features, W3C must follow the full process of advancing a technical report to Recommendation beginning with a new First Public Working Draft.

7.8 Publishing a Working Group or Interest Group Note

Working Groups and Interest Groups publish material that is not a formal specification as Notes. This includes supporting documentation for a specification such as explanations of design principles or use cases and requirements, non-normative guides to good practices, as well as specifications where work has been stopped and there is no longer consensus for making them a new standard.

In order to publish a Note, a Working Group or Interest Group:

Possible next steps:

The W3C Patent Policy [PUB33] does not specify any licensing requirements or commitments for Working Group Notes.

7.9 Rescinding a W3C Recommendation

W3C may rescind a Recommendation, for example if the Recommendation contains many errors that conflict with a later version or if W3C discovers burdensome patent claims that affect implementers and cannot be resolved; see the W3C Patent Policy [PUB33] and in particular section 5 (bullet 10) and section 7.5. A Working Group may request the Director to rescind a Recommendation which was a deliverable, or the Director may directly propose to rescind a Recommendation.

W3C only rescinds entire specifications. To rescind some part of a Recommendation, W3C follows the process for modifying a Recommendation.

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

To propose rescinding a W3C Recommendation, a Working Group or the Director

In addition a Working Group requesting to rescind a Recommendation

In addition the Director, if proposing to rescind a Recommendation

The Director must announce the proposal to rescind a W3C Recommendation to other W3C groups, the public, and the Advisory Committee. The announcement must:

If there was any dissent in Advisory Committee reviews, the Director must publish the substantive content of the dissent to W3C and the public, and must formally address the comment at least 14 days before publication as a Rescinded Recommendation. In this case the Advisory Committee may appeal the decision.

A Rescinded Recommendation must be published with up to date status. The updated version may remove the rescinded content (i.e. the main body of the document).

Note: the original Recommendation document will continue to be available at its version-specific URL.

Further reading

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, and tips on getting to Recommendation faster [PUB27].