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.
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.
*-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.
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.
The decision to advance a document to Recommendation is a W3C Decision.
The Working GroupW3C:
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.
Submit a transition request.
Include a link to a change log where new features are highlighted, highlight them in the Status of the Document.
Include a link to an issues list, such as GitHub issues, that indicates that errata have been responded.
Provide link(s) to the objection, attempts to satisfy the reviewer, and a public record of the decision.
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:
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.
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:
Submit an update request.
Provide a link to meeting minutes, github issues, or email announcing the decision.
*-needs-resolution
issue pending?Proposed amendments can only be incorporated as-is, per section 6.3.11.5.
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.
Include a link to a change log where new features are highlighted, highlight them in the Status of the Document.
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.
This is also known as "CR exit criteria".
If any, the list of features at-risk must appear in the Status of the Document.
This deadline must appear in the Status of the Document.
*-needs-resolution
issue pending? How recently were the reviews done?This deadline must appear in the Status of the Document.
The list of features at-risk must appear in the Status of the Document, if any.
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:
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.
For example, include a link to a change log where important changes are highlighted.
The Working Group:
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.
If there is no Working Group, the Maintainer Contact should provide the rational/record for requesting the publication.
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:
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.
Your document contain proper marks/annotations to identify the specific candidate changes, or is providing a list of those candidate changes.
Your document can only propose candidate changes but cannot apply those to the normative content at this time. The W3C Team will ensure no substantive changes.
The publication requirements will ensure about this. No need to indicate anything beyond providing the Status of the Document.
Were the expectations set at Candidate Recommendation met?
Any update since the most Candidate Recommendation Snapshot that would affect past wide reviews? How recently were the reviews done and would the current understanding of the Web change those past reviews?
This is similar to the general requirement to formally address all issues.
Highlight any substantive issues.
Include, for example, a link to a change log. If substantive changes were made, the Working Group must republish the document at an earlier status.
The list of features at-risk that have been removed must appear in the Status of the Document, if any.
The status information:
The publication requirements will ensure about this. No need to indicate anything beyond providing the Status of the Document.
Unless you don't want to allow new features, the status information must identify as intending to allow new features.
Errata are tracked through GitHub nowadays. The link to your errata page must appear in the document heading. This will be checked by our publication rules.
Include, for example, a link to a change log where most important changes are highlighted. Otherwise, the Working Group must republish the document at an earlier status.
The request:
Provide a link to meeting minutes, github issues, or email announcing the decision).
The Team must then submit the request to the Advisory Committee for review.
The W3C:
Submit a transition request.
Provide link(s) to the objection, attempts to satisfy the reviewer, and a public record of the decision.
Tip: When updating an existing Candidate Recommendation, focus your new request on what changed since the previous Candidate Recommendation transition. There is no need to repeat information included in the previous transition.
An First Public STATUS transitionupdate request MUST include:
For an STATUS transition, the CEO, or its delegates, may request a transition meeting attended by:
The Team Contact is responsible for the execution of the following (under the supervision of the Project Management Lead):
*-needs-resolution
issues are closed
by the relevant horizontal review group.*-needs-resolution
issues open in one or more
of the horizontal tracker boards.
Per section 6.3.13.4, in some conditions, the Team is required to accept the transition request.
Per section 6.3.3 of the Process, "The Team MUST inform the Advisory Committee and Working Group Chairs when a Working Group's request for a specification to advance in maturity stage is declined and the specification is returned to a Working Group for further work."
Tip: STATUSs published through the W3C automatic system do not need to get scheduled with the Webmaster and are not subjected to publishing moratoria.
7 days for transition: Unless there are exceptional circumstances, the Team requires a minimum of 7 days period between the transition request and the publication. This allows other Groups or outside individuals to review the transition request and may formally object within this period. While the Team strives to address transitions within this 7 days period, delays due to transition issues or competing Team's priorities are not unheard of and may increase the length of the period needed. Group participants are expected to raise objections within the Group prior to the transition request.
The Webmaster publishes on Tuesdays and Thursdays (cf. the announcement to chairs).
Please send advance notice to webreq@w3.org:
Note: Someone from the W3C management team (usually the Project Management Lead) SHOULD be aware of the status of the document.
A publication request MUST include the following information:
⟶ You may copy the list below and paste into the email sent
to webreq@w3.org
It is perfectly appropriate to send a publication while waiting for a Team's approval but does run the risk of not receiving the Team's approval in time. Please coordinate with the Project Management Lead if needed.
If the Webmaster finds errors during the publication process, he will endeavor to publish on the desired date, but he MAY also postpone publication to the next available publication date in order to resolve issues. In general, it will not be necessary to change the title page date of a document that is published a couple of days later than planned. If it becomes apparent that a publication date will be well after a title page date, the Webmaster SHOULD ask the Document Contact to resubmit a revised document with a more current title page date.
When scheduling publication, please note that publishing "blackouts" occur at the end of the calendar year and around certain W3C events such as AC meetings and All-Group meetings. The Communications Team announces these publishing moratoria with approximately six months notice. The announcements are linked from the Chairs' Guidebook.
In order to ensure publication standards, upon receiving a publication request the Webmaster SHALL make a best effort to verify that the document satisfies the pubrules requirements except for the accessibility requirements of section 7. The Webmaster SHALL publish the document (cf. the Webmaster's guide) if the following conditions have been met:
In order to ensure publication standards, upon receiving a publication request the Webmaster SHALL make a best effort to verify that the document satisfies the minimum of the pubrules requirements. The Webmaster SHALL publish the document (cf. the Webmaster's guide) if the following conditions have been met:
Otherwise the Webmaster SHALL NOT publish. In this case, the Webmaster SHALL provide details to the person who sent the request about which requirements have not been satisfied.
The Webmaster SHALL NOT publish the document until the date on the title page or later. The Webmaster publishes the document by updating the appropriate technical report index and updating the latest version link, and then announcing publication as described above.
An First Public STATUS transition announcement MUST include the following information:
The announcement SHOULD provide information about where people can learn about issues raised during the Candidate or Proposed Recommendation review period (e.g., a link to an issues list).
The announcement MAY indicate priority feedback items.
Please use the Team-only transition announcement template as a starting point.
Please use the Team-only transition announcement template as a starting point.
The Candidate Recommendation transition announcement SHOULD provide information about where people can learn about issues raised during the Candidate Recommendation review period (e.g., a link to an issues list).
The Candidate Recommendation transition announcement MAY indicate priority feedback items.
Please use the Team-only transition announcement template as a starting point.
Please use the Team-only transition announcement template as a starting point.
The Patent Policy FAQ clarifies when Call for Exclusions are sent out.
The Team sends a Call for Exclusion to participants. The exclusion opportunity lasts 150 days. At approximately 90 days, The Team sends out a reminder with a pointer to the "Patent Review Draft".
If the document was published within 90 days of the First Public Working Draft, it becomes the new Patent Review Draft for the Call for Exclusions started at the time of the First Public Working Draft publication. Exclusions are with respect to the set of features in this new STATUS.
A Working Group under the W3C Patent Policy publishes a STATUS. The Team sends the second exclusion opportunity. The exclusion opportunity lasts 60 days. Any exclusions are with respect to new features in the STATUS added since the exclusion opportunity of the First Public Working Draft.
The Working Group changes the document substantially after STATUS and published a new STATUS. The Team sends a new exclusion opportunity. It lasts 60 days. Exclusions are with respect to new features in the specification since the previous exclusion opportunity, i.e., the previous LABEL.
The Working Group updates the document substantially since the Recommendation and published a STATUS. The Team sends a exclusion opportunity. It lasts 60 days. Exclusions are with respect to new features in the specification since the previous exclusion opportunity, i.e., the one applying to the previous Recommendation.
The Working Group proposes to update the document substantially since the Recommendation and published a STATUS with proposed changes. The Team sends a exclusion opportunity. It lasts 60 days. Exclusions are with respect to the proposed changes identified in the specification.
Feedback is to @w3c/transitions and is welcome on GitHub