Recommendation Track Process, "Last Call" draft proposal

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

• support multiple specification development methodologies
• maximize consensus about the content of stable technical reports
• ensure high technical and editorial quality
• promote consistency among specifications
• facilitate royalty-free, interoperable implementations of Web Standards, and
• earn endorsement by W3C and the broader community.

See also the licensing goals for W3C Recommendations in section 2 of the W3C Patent Policy [PUB33].

Table of Contents

• General requirements for Technical Reports
• 7.1 Maturity Levels
• 7.2 General Requirements for Advancement on the Recommendation Track
  • 7.2.1 Substantive Change
  • 7.2.2 Wide Review
  • 7.2.3 Implementation Experience
• 7.3 Reviews and Review Responsibilities
• 7.4 Advancing a Technical Report to Recommendation
  • 7.4.1 Working Draft
    • 7.4.1.a First Public Working Draft
    • 7.4.1.b Revised Public Working Drafts
  • 7.4.2 Last Call Candidate Recommendation
  • 7.4.3 Publication of a W3C Recommendation
    • 7.4.3.a Publishing a Last Call Candidate Recommendation as a W3C Recommendation
    • 7.4.3.b Publishing an Edited Recommendation
    • 7.4.3.c For all W3C Recommendations
• 7.5 Publishing a Working Group or Interest Group Note
• 7.6 Modifying a W3C Recommendation
  • 7.6.1 Errata Management
  • 7.6.2 Classes of Changes to a Recommendation
• 7.7 Rescinding a W3C Recommendation
• Good practices

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 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 technical report development process must (was in 7.8) clearly indicate its maturity level, and must include a section about the status of the document. The status section

• must be unique each time a specification is published,
  
• must state who developed the specification,
• must state how to send comments or file bugs, and where these are recorded,
• should explain how the technology relates to existing international standards and related work inside or outside W3C,
• should include expectations about next steps, and
• should explain or link to an explanation of significant changes from the previous version.

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, 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 Board 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.1 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.

Last Call Candidate Recommendation (LC/CR)

A Last Call Candidate Recommendation is a document that Satisfies the Working Group's technical requirements, and has already received wide review. W3C publishes a Last Call Candidate Recommendation to

• signal to the wider community that a final review should be done
• gather implementation experience
• begin 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.

Note: Last Call Candidate Recommendation is the state referred to in the W3C Patent Policy [PUB33] as "Last Call Working Draft"

Note: Last Call Candidate Recommendations will normally be accepted as Recommendations. Announcement of a different next step should include the reasons why the change in expectations comes at so late a stage.

W3C Recommendation (REC)

A W3C Recommendation is a specification or set of normative guidelines 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.

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 some document that is not intended to be a normative specification, but is nevertheless useful. For example, supporting documents such as Use case and Requirements documents, or Design Principles, that explain what the Working Group was trying to achieve with a specification, or non-normative 'Good Practices" documents. A Working Group may also publish a specification as a Note if they stop work without producing a Recommendation. A Working Group or Interest Group may publish a Note with or without its prior publication as a Working Draft.

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 publish "Editor's drafts". Editor's drafts have no official standing whatsoever, and do not imply consensus of a Working Group or Interest Group, nor are their contents endorsed in any way by W3C or its members, except to the extent that such contents happen to be consistent with some other document which carries a higher level of endorsement.

7.2 General Requirements for Advancement on the Recommendation Track

For all requests to advance a specification to a new maturity level other than Note the Working Group:

• must record the group's decision to request advancement.
• must obtain Director approval.
• must provide public documentation of all substantive changes to the technical report since the previous publication. The community also appreciates public documentation of minor changes.
• must formally address all issues raised about the document since the previous maturity level.
• must provide public documentation of any Formal Objections.
• should report which, if any, of the Working Group's requirements for this document have changed since the previous step.
• should report any changes in dependencies with other groups.
• should document known implementation.

Because the requirements for First Public Working Drafts are fairly mechanical approval is normally fairly automatic, whereas for later stages there is generally a formal review meeting to ensure the requirements have been met before Director's approval is given.

7.2.1 Substantive Change

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.

7.2.2 Wide Review

The requirements for wide review are not precisely defined by the 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 actually reviewed the document and 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. A recommended practice is making a specific announcement to other W3C Working Groups as well as the general public that a group proposes to enter Last Call Candidate Recommendation in e.g. 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.3 Implementation Experience

Implementation experience is required to show that a specification is sufficiently clear, complete, and relevant to market needs 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):

• is each feature implemented, and how is this demonstrated; (for example, is there a test suite)?
• are there independent interoperable implementations?
• are there implementations created by other than the authors of the specification?
• are implementations publicly deployed?
• is there implementation experience at all levels of the specification's ecosystem (creation, consuming, publishing…)?

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

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. Publication of zero or more revised Public Working Drafts.
3. Publication of a Last Call Candidate Recommendation.
4. Publication as a Recommendation.
5. Possibly, Publication as an Edited Recommendation

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 and the specification is returned to a Working Group for further work.

7.4.1 Working Draft

7.4.1.a First Public Working Draft

To publish the First Public Working Draft of a document, in addition to meeting the general requirements for advancement a Working Group

• should document outstanding issues, and parts of the document on which the Working Group does not have consensus, and
• may request publication of a Working Draft even if it is unstable and does not meet all Working Group requirements.

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.4.1.b Revised 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 document that would benefit from review from 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 revised Working draft, a Working Group

• must record the group's decision to request publication. Consensus is not required, as this is a procedural step,
• must provide public documentation of substantive changes to the technical report since the previous Working Draft,
• should provide public documentation of significant editorial changes to the technical report since the previous step,
• should report which, if any, of the Working Group's requirements for this document have changed since the previous step,
• should report any changes in dependencies with other groups,
• should document outstanding issues and parts of the document on which the Working Group does not have consensus, and
• may request publication of a Working Draft even if it is unstable and does not meet all Working Group requirements.

Possible next steps:

• Revised Public Working Draft
• Last Call Candidate recommendation.
• Working Group Note

7.4.2 Last Call Candidate Recommendation

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

• must show that the specification has met all Working Group requirements, or explain why the requirements have changed or been deferred,
• must document changes to dependencies during the development of the specification,
• must document how adequate implementation experience will be demonstrated,
• must specify the deadline for comments, which must be at least four weeks after publication, and should be longer for complex documents,
• If the document has previously been published as a Last Call Candidate Recommendation, must document the changes since the previous Last Call Candidate Recommendation,
• must show that the specification has received wide review, and
• may identify features in the document that are considered "at risk". These features may be removed before advancement to Recommendation without a requirement to publish a new Last Call Candidate Recommendation.

The Director must announce the publication of a Last Call Candidate Recommendation to other W3C groups and to the public.

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

Possible next steps:

• Return to Working Draft
• Return to Last Call Candidate Recommendation
• Request Recommendation status (The expected next step)
• Working Group Note

If there are any substantive changes made to a Last Call Candidate Recommendation other than to remove features explicitly identified as "at risk", the Working Group must repeat the full process of publication as a Last Call Candidate Recommendation before the Working Group can request Recommendation status.

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

7.4.3 Publication of a W3C Recommendation

Publishing a Last Call Candidate Recommendation as a W3C Recommendation

To publish a Last Call Candidate Recommendation as a W3C Recommendation, a Working Group

• must republish the document, identifying it as the basis of a Request for Recommendation,
• must show adequate implementation experience,
• must show that the document has received wide review,
• must show that all issues raised during the Last Call Candidate Recommendation review period have been formally addressed,
• must identify any substantive issues raised since the close of the review period by parties other than Advisory Committee representatives,
• must document how the testing and implementation requirements identified as part of the transition to Last Call Candidate Recommendation have been met,
• must identify where errata are tracked, and
• may remove features identified in the Last Call Candidate Recommendation document as "at risk" without repeating the transition to Last Call Candidate Recommendation.

The Director

• should not provisionally approve a Request for publication of a W3C Recommendation less than 35 days after the publication of the Last Call Candidate Recommendation on which is it based [editor's note - this is to allow for the patent policy exclusion period to expire], and
  
• may provisionally approve a Recommendation with minimal implementation experience where there is a compelling reason to do so. In such a case, the Director should explain the reasons for that decision.

Publishing an Edited Recommendation (See also Modifying a Recommendation below)

To publish an Edited Recommendation as a W3C Recommendation, a Working Group

• must republish the document, identifying it as the basis of a Request for Recommendation,
• must show that the document has received wide review, and
  
• should address all errata.

For all W3C Recommendations, in addition to meeting the general requirements for advancement,

• The Director must announce the provisional approval of a Request for publication of a W3C Recommendation to the Advisory Committee,
• The Advisory Committee review of the technical report must continue at least 28 days after the announcement of provisional approval to publish the Edited Recommendation as a W3C Recommendation,
• If there was any dissent in Advisory Committee reviews, the Director must publish the substantive content of the dissent to W3C and the general public, and must formally address the comment >at least 14 days before publication as a W3C Recommendation. In this case the Advisory Committee may appeal the decision,
• The Director must announce the publication of a W3C Recommendation to other W3C groups and to the public, and
• The "Status of the Document" must reflect whether it is provisionally approved, or published as a W3C Recommendation.

Possible next steps:

• A W3C Recommendation normally retains its status indefinitely. However it
• may be republished as an Edited Recommendation, or
• may be rescinded.

7.5 Publishing a Working Group or Interest Group Note

Working Groups and Interest Groups publish material that is not a formal specification as Notes. This may include supporting documentation for a specification, such as requirements, use cases, non-normative good practices and the like.

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.

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

• must record the group's decision to request advancement, and
• should public documentation of significant changes to the technical report since the previous publication.

Possible next steps:

• End state: A technical report may remain a Working Group Note indefinitely
• A Working Group may resume work on the technical report at any time, at the maturity level the specification had before publication as a Note

The W3C Patent Policy does not specify any licensing requirements or commitments for Working Group Notes, only for W3C Recommendations. See also the W3C Patent Policy [PUB33].

7.6 Modifying a W3C Recommendation

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, the W3C Process focuses on substantive changes (those related to prior reviews). After a document has been published as Recommendation, the W3C Process focuses on those changes to a technical report that might affect 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 by the process described below.

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 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, 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 Recommendation. A change that affects conformance is one that:

• turns conforming data, processors, or other conforming agents into non-conforming agents, or
• turns non-conforming agents into conforming ones, or
• clears up an ambiguity or under-specified 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

The first two classes of change require no technical review of the proposed changes. A Working Group may request republication of a Recommendation for these classes of change, or W3C may republish a Recommendation with this class of change. The modified Recommendation is published according to the Team's requirements, including Publication Rules [PUB31] and the Requirements for modification of W3C Technical Reports [PUB@@].

For the third class of change, a Working Group must request publication of an Edited Recommendation.

For the fourth class of change, which introduces a new feature or features, W3C must follow the full process of advancing a technical report to Recommendation.

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

To deprecate 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

• must publish rationale for rescinding the Recommendation.
• should document known implementation.

In addition a Working Group proposing to rescind

• must show that the request to rescind has received wide review
• should show that the request to rescind is based on public comment

In addition the Director, if proposing to rescind

• must show that the request to rescind is based on public comment

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

• indicate that this is a Proposal to Rescind a Recommendation
• specify the deadline for review comments, which must be at least four weeks after publication
• identify known dependencies and solicit review from all dependent Working Groups;
• solicit public review.

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.

Good practices

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