Publication Policies

Resources

Tools

Select your steps :

Note: The first Candidate Recommendation publication after verification of a transition request is also considered a Candidate Recommendation Snapshot.

Not sure what's your next step? Try our step finder and look at milestones calculator.

About This Document

This resource describes the internal W3C Technical Report publication processes. A companion document provides more information about roles involved in these processes and interactions with the W3C Communications Team.

Steps for transition to an update request for a publication of a publication of an LABEL Snapshot (intended to update a Recommendation) Draft (with candidate corrections) (with candidate additions) (with proposed corrections) (with proposed additions) (with editorial changes) (incorporating proposed corrections) (incorporating proposed additions)

Once the Process Document requirements for the transition to LABEL have been satisfied (see section 6.3.5 section 6.3.7 section 6.3.8.1 section 6.3.9 section 6.3.11.5 and section 6.3.4 section 6.3.11.3 section 6.3.11.4 section 6.3.10 or section 6.3.12.4 for restoring a Recommendation section 6.3.12.4 section 6.3.12.4), W3C follows the steps described below to complete the transition. Once the Group determined that the requirements of section 6.3.6 apply, the W3C follows the steps described below to update a STATUS. Once the Group, or the Maintainer Contact, determined that the requirements of section 6.3.11.2 apply, the W3C follows the steps described below to update a STATUS. Once the Group determined that the requirements of section 6.3.8.2 have been satisfied, the Working Group follows the steps described below to publish a STATUS. W3C follows the steps described below for transition to a First Public STATUS. These steps are grouped by theme. They are not strictly ordered; in practice, some steps are completed in parallel. For instance, groups often manage the transition request/meeting steps in parallel with the publication request steps.

Note: If your specification involves (or updates) an Internet Media Type, before the transition to First Public STATUS, see also How to Register an Internet Media Type for a W3C Specification to review the entire Internet Media Type registration process. for information about what you should do several months before advancing to Candidate Recommendation. for information about alerting the W3C liaisons to the IETF so that they may request formal review and approval by the IESG. for information about how the W3C liaisons to the IETF track the registration process.

Note: If your specification defines (or updates) an XPointer Scheme, before the transition to STATUS, please register the scheme in the W3C XPointer Scheme Registry.

Negotiation of Review Schedule
  • The Chair negotiates the wide review schedule with the Chairs of groups with dependencies (on chairs@w3.org) before going to STATUS. The Group MUST show that the specification has received wide review in order to move to Candidate Recommendation. The Group MUST show that all horizontal *-needs-resolution issues have been closed by the relevant horizontal group in the horizontal group's tracker in order to publish the STATUS. The Group MUST show that any horizontal *-needs-resolution issues have been acknowledged in order to publish the STATUS. The Group MUST show that the changes have received wide review in order to publish the STATUS. See the considerations, guidelines and best practices that groups should follow to get early and wide review of a document.
Transition request
Update request
  • If an individual made a request to the relevant Working Group, or the TAG (using w3ctag/obsoletion) if such a group does not exist, to obsolete or to supersederescind a Recommendation, and the request was not answered within 90 days, the individual should send his request to webreq@w3.org, cc'ing plh@w3.org, www-archive@w3.org.
  • At least one week prior to an expected decision from or meeting with the Team, the The Document Contact creates a transition request in w3c/transitions. For the purpose of the automatic publishing system, it's important that the title of the issue ends with the shortname of your specification, thus you will need one single issue for each specification. Note: For the TAG, no First Public Working Draft transition request is required; the request is assumed to be approved by the Team. sends a transition request to the Team: ralph@w3.org, plh@w3.org, cc'ing ylafon@w3.org, w3t-comm@w3.org. An issue is also created in w3c/transitions (for tracking purposes). A public archive of transition requests is available (since October 2019).
  • Following an initial review by the Team, the Document Contact MAY be asked to organize a transition meeting with the Team to discuss the request.
  • The Project Management Industry or Strategy Lead approve the transition request. The Lead MAY ask the CEO (or someone assigned by the CEO) to take responsibility for approving the transition request. The Team verifies the transition request. Approvals are expected to appear as an issue comment "Transition approved." in w3c/transitions and the label 'Awaiting Publication' will need to be set. In most cases the decision to approve the transition is made on Fridays.
Publication Planning
  • The Document Contact ensures that there is a public archived github repository available for comments.
  • The Document Contact prepares the document in accordance with pubrules (use the "Echidna-ready" check).
  • If the publication is the result of stopping work on a specification, the Document Contact alerts the Webmaster at webreq@w3.org, optionally cc'ing w3c-archive@w3.org (which has a Member-visible archive).
  • The Document Contact ensures that there is a public archived place (github or mailing list) available for comments; (for mailing list, the Team Contact uses the mailing list request form).
  • If an individual made a request to the relevant Working Group, or the Maintainer Contact, to update a Recommendation, and the request was not answered within 90 days, the individual should create a transition request in w3c/transitions to draw attention.
  • The Document Contact ensures that there is a public archived github repository available for comments.
  • The Document Contact prepares the document in accordance with pubrules and develops a proposed publication schedule, taking into account possible publishing moratoria. The title page date is chosen based on the anticipated publication schedule.
  • Before sending the publication request, the Team Contact SHOULD install the document in its final location. The Document Contact MAY request publication of a document that is not yet installed at its final location, but in this case MUST provide installation instructions to the Webmaster. If a document to be published consists of more than one HTML file (i.e., there are style sheets, schemas, etc.), all materials MUST be made available to the Webmaster from a single directory (which may include subdirectories).
  • The Document Contact sends a publication request to the Webmaster at webreq@w3.org, optionally cc'ing w3c-archive@w3.org (which has a Member-visible archive). See below for details about scheduling a publication, and specifically requirements about advance notice to the Webmaster. If the publication is the result of stopping work on a specification, the Document Contact alerts the Webmaster as well.
Form and Announcement Preparation
Announcement Preparation
  • The Document Contact sends a draft transition announcement to the Communications Team at w3t-comm@w3.org, which explains why the document was returned for further work.
  • The Team Contact builds a STATUS review form that the Project Manager reviews for correctness. The Team Contact ensures that there is a mailing list with a Team-only archive available for AC Representative comments; this list is cited from the review form. Note: At the current time, WBS review forms are generated from installed documents, but before the Webmaster completes publication.
  • The Document Contact sends a draft transition announcement to the Communications Team at w3t-comm@w3.org. If the publication is the result of returning a document to a Working Group for further work, the announcement explains why the document was returned for further work.
  • The Communications Team approves the draft using an issue comment "Draft transition approved" in w3c/transitions
Publication and Transition Announcement
Publication and Update Announcement
Publication
Transition Announcement
  • The Webmaster completes publication and notifies the Chair and Team Contact of publication, cc'ing webreq@w3.org and w3t-comm@w3.org.
  • The Document Contact publishes the document using the W3C automatic system.
  • After coordination with the Communications Team on the transition announcement timing (especially those accompanied by press releases; see more about interactions with the Communications Team), the Webmaster completes publication and notifies the person who sent the request, cc'ing webreq@w3.org and w3t-comm@w3.org. Publication SHOULD precede the transition announcement by only a small amount of time.
  • The W3C Communications Team makes an announcement on the W3C home page.
  • The W3C Communications Team sends the transition announcement to w3c-ac-members@w3.org and chairs@w3.org.
  • Since September 2015, the Communications Team no longer posts homepage news for regular WDs, unless explicitely requested.
  • The W3C Communications Team sends the transition announcement to w3c-ac-members@w3.org and chairs@w3.org and on the W3C home page. The Advisory Committee review is started. The Call for Exclusions and the Advisory Committee review are started.
  • The W3C Communications Team sends the update announcement to chairs@w3.org and on the W3C home page.
  • The Chair or Team Contact(s) SHOULD forward the announcement to the Working Group's public mailing list taking caution not to send any Member-confidential information to a public list.
  • The Document Contact SHOULD forward the announcement to the Working Group's public mailing list.
  • The Team Contact SHOULD forward the announcement to the appropriate public forum taking caution not to send any Member-confidential information to a public list.

Note: Instructions for publication of an Ordinary STATUS are included for convenience even though this is not a Recommendation Track transition as defined in the W3C Process.

Note: STATUS is not a maturity stage defined in the W3C Process but is described as a proposal before the next step.


Transition Requirements for STATUS

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

The Working GroupW3C:

  • must record the group’sindividual(s) decision to request advancement.

    Provide a link to meeting minutes, github issues, or email announcing the decision.

    For a Recommendation, you may reuse the group's decision to move to Proposed Recommendation.

  • must obtain Team verification.

    Submit a transition request.

  • must publicly document all new features (class 4 changes) to the technical report since the previous publication.

    Include a link to a change log where new features are highlighted, highlight them in the Status of the Document.

  • must not contain new features (class 4 changes) to the technical report since the Recommendation.
  • must publicly document if other substantive changes (class 3 changes) have been made, and should document the details of such changes.
    • For example, include a link to a change log where important changes are highlighted.
    • If this specification is a revision of a previous Recommendation, does the document clearly state the relation of this version to the previous one? For instance, does it obsolete or supersede a previous Recommendation? Where is this stated (e.g., the status section)? Does the specification explain whether authors should create content according to the previous or current version? Does the specification explain whether processors should continue to process content according to the previous Recommendation?
    • If there will be two Recommendations of different major revision numbers, does the newer specification explain the relationship?
  • should publicly document if editorial changes have been made, and may document the details of such changes.
  • must formally address all issues raised about the document since the previous maturity level.
    • Include a link to an issues list, such as GitHub issues, that indicates that the group has been responsive to reviewers who have raised issues since the previous transition. The Team's expectations are that, as a document advances, there will be an increasingly precise record of how it has formally addressed each issue.
    • For changes in the issues list since the previous transition:
      • Highlight issues where the Group has declined to make a change, with rationale. See also Clarification: tables summarizing review, Tim Berners-Lee (Tue, Feb 15 2000).
      • `>
      • Highlight issues where the Group has not satisfied a reviewer and has either not yet responded to the reviewer, or the reviewer has not yet acknowledged the Group's decision.
      • Show, without highlighting:
        • Issues where the Working Group has accepted a proposed change.
        • Issues where the Working Group has clarified the specification to the satisfaction of the reviewer.
  • should formally address all errata raised about the document since the Recommendation.

    Include a link to an issues list, such as GitHub issues, that indicates that errata have been responded.

  • must provide public documentation of any Formal Objections.

    Provide link(s) to the objection, attempts to satisfy the reviewer, and a public record of the decision.

  • should report which, if any, of the Working Group'sindividual(s) requirements for this document have changed since the previous step.
  • should report any changes in dependencies with other groups.
    • In general, documents do not advance to Proposed Recommendation with normative references to other specifications that are considered unstable. See also Normative References Guidelines.
    • Documents must not include normative references to a Rescinded/Obsolete/Superseded Recommendation.
  • should provide information about implementations known to the Working Groupindividual(s).
  • must provide information about implementations known to the individual(s).

    See implementation experience

  • must provide information about implementations known to the Working Groupindividual(s).
    • Unless this information changed since the previous transition, indicate "No change".
    • Include a link to a final implementation report, or, if there is no such report, rationale why the Team should approve the request nonetheless.
    • If you use WPT results, provide a snapshot of those results, e.g wpt.fyi snapshot of webauthn (save a copy of the resulting report)

Requirements for revising a STATUS

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:

  • must record the group’s decision to request publication. Consensus is not required, as this is a procedural step,

    Provide a link to meeting minutes, github issues, or email announcing the decision. The decision may be applicable to one or more revisions.

    This link should be given to the W3C automatic system using the decision parameter.

  • 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,

Requirements for updating a STATUS

WARNING: If your existing Recommendation was not approved for accepting new features, you are not allowed to follow these steps. You MUST follow the First Public Working Draft steps instead.

The decision to incorporate proposed amendments in a Recommendation is a W3C Decision.

The Working Group:

The W3C:

  • must obtain Team verification, or fulfill the criteria for Streamlined Publication Approval.

    Submit an update request.

  • must record the group’s decision to request the update.

    Provide a link to meeting minutes, github issues, or email announcing the decision.

  • must show that the changes proposed amendments have received wide review.
    • Was the public requested to review the changes (such as announcement from a previous publication)?
    • Which are the groups with dependencies, per the Group's charter, and did they review the document?
    • Were the horizontal groups given proper opportunities to review subtantive changes? Are there any *-needs-resolution issue pending?
    • Was there early review from implementers? Are the changes already deployed in implementations?
    • Streamlined Publication Approval requires, for each of the W3C Horizontal Groups, if the Horizontal Review Group has made available a set criteria under which their review is not necessary, the Working Group must document that these criteria have been fulfilled. Otherwise, the Working Group must show that review from that group has been solicited and received.

    Proposed amendments can only be incorporated as-is, per section 6.3.11.5.

  • Streamlined Publication Approval requires the group to formally address:
    • all issues raised against the document that resulted in changes since the previous publication

    • all issues raised against changes since the previous publication

    • all issues raised against the document that were closed since the previous publication with no change to the document

    The response to each of these issues must be to the satisfaction of the person who raised it: their proposal has been accepted, or a compromise has been found, or they accepted the Working Group’s rationale for rejecting it. This implies no pending *-needs-resolution issues, and no pending PAG conclusions.

  • must provide public documentation of any Formal Objections.
    • Provide link(s) to the objection, attempts to satisfy the reviewer, and a public record of the decision.
    • Streamlined Publication Approval requires no formal objection have been registered.
  • must publicly document of all new features (class 4 changes) to the technical report since the previous publication.

    Include a link to a change log where new features are highlighted, highlight them in the Status of the Document.

  • must publicly document if other substantive changes (class 3 changes) have been made, and should document the details of such changes.

    For example, include a link to a change log where important changes are highlighted.

    For Recommendations, other substantive changes must not happen, unless it was a proposed amendment.

  • should publicly document if editorial changes changes have been made, and may document the details of such changes.
  • must show that the revised specification meets all Working Group requirements, or explain why the requirements have changed or been deferred,
    • Where are the requirements defined (e.g,. a charter or requirements document)?
    • Are any requirements previously satisfied no longer satisfied? Are any requirements previously unsatisfied now satisfied?
    • Streamlined Publication Approval requires no changes to Working Group requirements.
  • should report which, if any, of the Working Group's requirements for this document have changed since the previous step.
    • Streamlined Publication Approval requires no changes to Working Group requirements.
  • should report any changes in dependencies with other groups.
  • should provide information about implementations known to the Working Group.
  • must show that the specification has met all Working Groupindividual(s) requirements, or explain why the requirements have changed or been deferred,
    • Where are the requirements defined (e.g,. a charter or requirements document)?
    • Are any requirements previously satisfied no longer satisfied? Are any requirements previously unsatisfied now satisfied?
  • must document changes to dependencies during the development of the specification,
    • Does this specification have any normative references to other specifications that are not yet stable? The Team's expectations are that, as a document advances, there will be an increasingly need for normative referenced materials to be scrutinized. See Normative References Guidelines.
    • Does this specification have any normative references to a Rescinded/Obsolete/Superseded Recommendation? Documents must not include normative references to a Rescinded/Obsolete/Superseded Recommendation.
    • Have other Groups confirmed that dependencies have been satisfied? For example, does the issues list show that these groups are satisfied as a result of their review of the document? Are there dependencies that have not been satisfied?
  • must document how adequate implementation experience will be demonstrated,

    This is also known as "CR exit criteria".

    • Are there tests or test suites available that will allow the WG to demonstrate/evaluate that features have been implemented (e.g., a matrix showing how different pieces or classes of software implement different features)? Is the expectation to show two complete implementations (e.g., there are two software instances, each of which conforms) or to show that each feature is implemented twice in some piece of software?
    • What are the Group's plans for showing implementation of optional features? In general, the Team expects mandatory features and optional features that affect interoperability to be handled similarly. Optional features that are truly optional (i.e., that do not affect interoperability) may require less implementability testing.
    • Does the WG have additional implementation experience that will help demonstrate interoperability (e.g., has there been an interoperability day or workshop? Is one planned?)?
  • may identify features in the document as at risk. These features may be removed before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation.

    If any, the list of features at-risk must appear in the Status of the Document.

  • must specify the deadline for comments, which must be at least 28 days after publication, and should be longer for complex documents, and,

    This deadline must appear in the Status of the Document.

  • must show that the specification has received wide review.
    • Make sure to look at How to do Wide Review
    • Was the public requested to review the document (such as announcement from a previous publication)?
    • Which are the groups with dependencies, per the Group's charter, and did they review the document?
    • Were the horizontal groups given proper opportunities to review subtantive changes? Are there any *-needs-resolution issue pending? How recently were the reviews done?
    • Was there early review from implementers? Are the changes already deployed in implementations?

Requirements for publishing a STATUS

A Working Group should publish an Update 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.

The Working Group:

Updating a STATUS with editorial changes

The Working Group:

If there is no Working Group, the Maintainer Contact should provide the rational/record for requesting the publication.

Updating a STATUS with candidate changes

WARNING: If your existing Recommendation was not approved for accepting new features, you are not allowed to follow these steps. You MUST follow the First Public Working Draft steps instead.

The Working Group:

The status information:


Feedback is to @w3c/transitions and is welcome on GitHub