Organize a Technical Report Transition (2023 Process)

About This Document anchor

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 First Public Working Draft anchor

Once the Process Document requirements for the transition to First Public Working Draft have been satisfied (see section 6.3.5 ), W3C follows the steps described below to complete the transition. 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 Working Draft, see also Register an Internet Media Type for a W3C Specification to review the entire Internet Media Type registration process.

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 Working Draft. 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 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.
The Document Contact creates a transition request in w3c/transitions. Note: For the TAG, no First Public Working Draft transition request is required; the request is assumed to be approved by the Team. 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 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 Document Contact issue an update request in w3c/transitions, if there are substantive changes other than to remove features explicitly identified as at risk.
if the only substantive changes are to remove features explicitly identified as at risk, there is no need for Team's approval.
If the update request satisfies the criteria for Streamlined Publication Approval, the Team automatically grants the request without formal review.
If the update request does not satisfy the criteria for Streamlined Publication Approval, the Team may approve the request after review.

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.

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 Working Draft 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.
The Document Contact sends a draft transition announcement to the Communications Team at w3t-comm@w3.org.
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

Transition Requirements for Working Draft anchor

The Working Group:

must record the group’s decision to request advancement.
Provide a link to meeting minutes, github issues, or email announcing the decision.
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 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 Group.
must provide information about implementations known to the individual(s).
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 updating a Working Draft

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.
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?
- Is there evidence that additional dependencies related to implementation have 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?

must show adequate implementation experience except where an exception is approved by the Team,
Were the expectations set at Candidate Recommendation met?
must show that the document has received wide review,
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?
must show that all issues raised during the Candidate Recommendation review period other than by Advisory Committee representatives acting in their formal AC representative role have been formally addressed,
This is similar to the general requirement to formally address all issues.
must identify any substantive issues raised since the close of the Candidate Recommendation review period,
Highlight any substantive issues.
must not have any substantive changes since the most recent Candidate Recommendation Snapshot, other than dropping features identified at risk.
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.
may have removed features identified in the Candidate Recommendation Snapshot document as at risk without republishing the specification as a Candidate Recommendation Snapshot.
The list of features at-risk that have been removed must appear in the Status of the Document, if any.

The status information:

must specify the deadline for Advisory Committee review, which must be at least 28 days after the publication of the Proposed Recommendation and should be at least 10 days after the end of the last Exclusion Opportunity.
The publication requirements will ensure about this. No need to indicate anything beyond providing the Status of the Document.
may identify itself as intending to allow new features (class 4 changes) after its initial publication as a Recommendation, as described in section 6.3.11.4 Revising a Recommendation: New Features. Such an allowance cannot be added to a technical report previously published as a Recommendation that did not allow such changes.
Unless you don't want to allow new features, the status information must identify as intending to allow new features.

Transition requirements to Working Draft

The W3C:

must obtain Team verification.
Submit a transition request.
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.
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.
If there was any dissent in Advisory Committee reviews, the Team 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.
- Typically, the Team consults with the group. For substantive issues, especially substantive or serious technical issues the Team Contact should endeavor to understand the reviewer's issues and try to resolve them before sending the Team a request to advance to Recommendation. The request to advance to Recommendation should document the success or failure of these negotiations.
- Provide link(s) to the Advisory Committee reviews, issues where the dissent was made public, and where the comment was addressed.

Transition request anchor

A First Public Working Draft transition request MUST include:

Document title, URIs, and estimated publication date.
The document Abstract and Status sections, either by reference (e.g., the URL to the document) or direct inclusion.
A statement whether or not the group considers the document to be a delta specification.
Fulfill the requirements for the Advancement on the Recommendation Track.
Fulfill the requesting the Working Draft.
Fulfill the requirements for the update request.
Has anything changed on the patent disclosure page since the previous transition? Have there been any incomplete or problematic disclosures?

To submit a transition request, open a new issue in w3c/transitions.

Transition Meeting with the Team anchor

For a Working Draft transition, the CEO, or its delegates, may request a transition meeting attended by:

The Team contact(s)
The Maintainer Contact
The Project Management Lead (or someone appointed by him), who generally chairs the meeting.
Those delegated by the Team to approve the transition.
The Team should be invited to attend the meeting if the transition involves contentious issues such as IPR, technical or other concerns.
The
Others invited by the Project Management Lead (or whoever is chairing the transition meeting)
In the event that the specification significantly affects the work of another WG, a (non-Team) representative of that Group should be invited to the call.

The Team Contact is responsible for the execution of the following (under the supervision of the Project Management Lead):

Scheduling the meeting. To allow chairs of WGs with dependencies and other commenters time to review the treatment of review comments in the disposition of comments document, the transition request MUST be sent a minimum of seven days prior to the transition meeting.
Reserving a teleconference bridge.
Choosing a scribe prior to the meeting.
Ensuring that the meeting record is distributed to the participants. The meeting record (typically a link to an IRC log) must include the decision, and should highlight all recommendations. The meeting record should be sent to all participants attendees, and MUST be cc'ed to w3t-archive@w3.org.

Sample agenda anchor

Administrative

Is everyone here?
Confirmation of Chair, Scribe
Are any changes required to the agenda?

Review of the transition request

In particular, review those items highlighted as requiring the Team's attention.

Review of the horizontal tracker boards

Ensure that all horizontal *-needs-resolution issues are closed by the relevant horizontal review group.

Decision

The Team assesses whether the W3C Process has been followed and whether there is sufficient consensus to support the transition request. In most cases the decision to make the transition is made during the teleconference. However the decision could take up to two weeks if any difficult issues arise during the meeting. The Team may delegate the W3C decision; see Team processes for TR publications.

Next steps

If the decision is negative: how do we repair the problem? what happens next? who does what? Note: If documents have been copied to /TR space, please remove them.
If the decision is positive: how do we announce this decision? when? what is the plan and schedule for any communications opportunities, including Member testimonials? any action items from this meeting?

Some reasons for declining a transition request

The Team is not satisfied after its verification with how the Working Group fulfilled the requirements for advancement.
The Working Group has issued a transition request despite a Formal Objection and the Council is not satisfied with the Working Group's rationale.
The Team is not satisfied with how the individual(s) has addressed issues.
The Team believes that special entrance criteria have not been satisfied.
There are horizontal *-needs-resolution issues open in one or more of the horizontal tracker boards.

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

Scheduling Publication anchor

The Webmaster publishes on Tuesdays and Thursdays (cf. the announcement to chairs).

Please send advance notice to webreq@w3.org:

3 business days in advance: If you need help from the Webmaster to fix errors, or ask for Pubrules error exception.
2 business days in advance: If the document is perfectly ready.

Upcoming publication moratoria are listed below and also available as a Google calendar:

Limited W3C Staff Availability: No publications from August 22 to September 1
TPAC 2025: No publications from November 7 to 17
End of Year: No publications from December 24 to January 5

Publication Request anchor

A publication request MUST include the following information:
⟶ You may copy the list below and paste into the email sent to webreq@w3.org

Information:
- Document Title: xxx xxx
- Document URL: https://www.w3.org/TR/yyyy/XX-xxx-yyyymmdd/
- Publication Date: (if document not installed) Month Date Year
- Description: Used in TR/xx/all page (only needed if differ from the 'Abstract' of the document)
- Family: Used in the new TR Page to categorize specifications, configured in GitHub w3c/spec-families repo.
- Description Update: Used in TR/xx/all page (only needed if differ from the 'Abstract' of the document)
- Document tags: (see the list of tags here)
- Document tags update: (see the list of tags here)
- Retired: (only needed when 'yes')
  ⟶ Indicate if the publication is the result of stopping work on a specification (aka "retired").
- Requirements for shortlinks redirection: (may apply if there are multi levels)
Approvals:
- Record of approval of the transition request.
- Record of approval of the update request.
- Record of W3M decision to close the group.
- Team's approval state: (approved / not yet / not needed)
- Evidence that publication is in accordance with expectations set by the group charter (e.g., quote the charter).
- Record of approval of the Group.
Skip CfE for CR text delete: (only needed when 'yes')
⟶ If there has been a previous Candidate Recommendation, whether the only change is that text has been deleted; If so, W3C can skip the Patent Policy Exclusion (see the Patent Policy FAQ).
Checks:
- Pass Pubrules' check: (yes / need Team's exception)
  ⟶ Check the document using Pubrules UI.
  ⟶ How to deal with Pubrules' result:
  - error: should not contain any `error`, unless it's an exception approved by the Team. This could likely block publication
  - warning: Please read through each warning and try to reduce the number of them.
- Comment on Pubrules: (describe the help you need if there's any error)
- Pass Link Checker's check: (yes)
  ⟶ Check the document using W3C Link Checker.
  ⟶ How to deal with result of Link Checker:
  - 404 Not Found: should not contain any `404` link. This could likely block publication.
  - 403 Forbidden: Please check manually.
  - Broken Fragments: These kind of error could be false alarm, please check manually.
  - Status: 301: Please consider using the new link.

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.

Publication anchor

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:

The publication request is complete, and
The document satisfies the pubrules requirements verified by the Webmaster.

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.

Call for Exclusions anchor

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

Standards

Groups

Get involved

Resources

News & events

About

Organize a Technical Report Transition (2023 Process)

About This Document anchor

Steps for transition to First Public Working Draft anchor

Transition Requirements for Working Draft anchor

Requirements for revising a Working Draft

Requirements for updating a Working Draft

Requirements for publishing a Working Draft

Updating a Working Draft with editorial changes

Updating a Working Draft with candidate changes

Requirements for requesting a Working Draft

Transition requirements to Working Draft

Transition request anchor

Transition Meeting with the Team anchor

Sample agenda anchor

Some reasons for declining a transition request

Scheduling Publication anchor

Publication Request anchor

Publication anchor

Transition Announcement

Call for Exclusions anchor

Organize a Technical Report Transition (2023 Process)

About This Document §anchor

Transition Requirements for Working Draft §anchor

Requirements for revising a Working Draft

Requirements for updating a Working Draft

Requirements for publishing a Working Draft

Updating a Working Draft with editorial changes

Updating a Working Draft with candidate changes

Requirements for requesting a Working Draft

Transition requirements to Working Draft

Transition requestUpdate Request §anchor

Transition Meeting with the Team §anchor

Sample agenda §anchor

Some reasons for declining a transition request

Scheduling Publication §anchor

Publication Request §anchor

Publication §anchor

Transition Announcement

Call for Exclusions §anchor

Related content

Publication Policies

About This Document anchor

Transition Requirements for Working Draft anchor

Transition request anchor

Transition Meeting with the Team anchor

Sample agenda anchor

Scheduling Publication anchor

Publication Request anchor

Publication anchor

Call for Exclusions anchor