This is a view that allows readers to compare alternatives; see alternatives highlighted inline and also in comparision tables.
As of 4 August 2016, this document has been superseded by a newer version.
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. A comparison of requirements across all document types is available.
Once the Process Document requirements for the transition to First Public STATUS have been satisfied (see [procdocsection when doc:fpwd-wd-tr] section 7.3.1 [procdocsection when doc:cr-tr] section 7.4 [procdocsection when doc:pr-tr] section 7.5 [procdocsection when doc:per-tr] section 7.7 [procdocsection when doc:rec-tr] section 7.6 [procdocsection when doc:prrescind-tr] section 7.9 [procdocsection when doc:rescind-tr] section 7.9), W3C follows the steps described below to complete the transition. 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.
[internetmediatype when doc:fpwd-wd-tr|cr-tr|pr-tr|per-tr|rec-tr] Note: If your specification involves an Internet Media Type, before the transition to First Public STATUS, see also How to Register an Internet Media Type for a W3C Specification [mediatypespecifics when doc:fpwd-wd-tr] to review the entire Internet Media Type registration process. [mediatypespecifics when doc:ord-wd-tr] for information about what you should do several months before advancing to Candidate Recommendation. [mediatypespecifics when doc:cr-tr] for information about alerting the W3C liaisons to the IETF so that they may request formal review and approval by the IESG. [mediatypespecifics when doc:pr-tr|per-tr|rec-tr] for information about how the W3C liaisons to the IETF track the registration process.
[xpointerregistry when doc:cr-tr] Note: If your specification defines an XPointer Scheme, before the transition to STATUS, please register the scheme in the the W3C XPointer Scheme Registry.
[exclusion-annc when doc:fpwd-wd-tr|cr-tr] Note: After announcement of a First Public Working Draft Candidate Recommendation the W3C Communications Team issues a Call for Exclusions in accordance with the W3C Patent Policy. See also the 2014 Process Transition FAQ.
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.
Please take note of the W3C Process Document provisions regarding when to publish a STATUS:
Here are the W3C Process Document transition requirements for a STATUS:
[revisions when doc:cr-tr] Note: The Working Group MAY publish a revision of a Candidate Recommendation with minor changes before the next transition.
[revisions when doc:cr-tr|pr-tr|per-tr] Note: The Working Group SHOULD NOT publish a (new) revision of a STATUS before the end of the (current) review period.
The message subject line and body SHOULD identify this as a "transition request"; see above for where to send the request. A First Public STATUS transition request MUST include:
Furthermore, the transition request provides evidence that the group has satisfied the transition requirements. The questions and observations in the subsections below provide examples of what SHOULD be in the transition request to help the Domain Lead(s) Director assess whether the group has satisfied the transition requirements. [transreq-as-agenda when doc:cr-tr|pr-tr|per-tr|prrescind-tr|rec-tr|rescind-tr] The transition request SHOULD be organized so that it serves as the basis for the agenda of the meeting with the Director.
[shortname when doc:fpwd-wd-tr|fpig-note-tr|fpcg-note-tr|fpwg-note-tr notehistory:notchartered|first|none] The goal of the transition request is to secure an archived record of the Domain Lead(s)' approval of the title, and shortname. In the past, shortnames have been changed between versions, and documents have been split and merged between versions. A conservative approach is to treat a merged or split document like a first publication.
The Team Contact(s) generally present the new draft for the entire W3C Team as soon as possible after the transition request (and possibly before Domain Lead approval). The length of the presentation varies (from "more than a lightning talk" to a Project Review) depending on the technical or political complexity of the specification.
[per-reqs-just-changes when doc:per-tr] Note: All requirements related to a Proposed Edited Recommendation (PER) are limited to the scope of the changes.
[no-pr-when-open-excl when doc:pr-tr] Note: The Director SHOULD NOT schedule a Proposed Recommendation review period to end less than 10 days after the end of an open "exclusion opportunity" as defined in the W3C Patent Policy (per section 7.5 of the W3C Process), or if there are any Patent Advisory Groups (PAGs) currently discussing the document (per the Patent Policy FAQ, question 29).
For a STATUS transition, the convention is to hold a transition meeting attended by:
The Team Contact is responsible for the execution of the following (under the supervision of the Domain Leader):
Per section 7.1.1 of the Process, "The Director must inform the Advisory Committee and Working Group Chairs when a Working Group's request for a specification to advance in maturity level is declined and the specification is returned to a Working Group for further work."
A publication request is an assertion from the Document Contact that the document satisfies the pubrules requirements. The subject line and body SHOULD identify this as a "publication request"; see above for where to send the request. A publication request MUST include the following information.
[domain-lead-aware when doc:cr-tr] Note: Someone from the W3C management team (usually the relevant Domain Leader) SHOULD be aware of the status of the document.
The Document Contact negotiates a publication date with the Webmaster. Each publication request SHOULD propose a publication date. If the request does not include a proposed publication date, the Webmaster MAY consider the title page date as the proposed publication date.
As of 2 March 2010 (cf. the announcement to chairs) the Webmaster publishes on Tuesdays and Thursdays. Regarding advance notice:
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 1.6. 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.
A First Public STATUS transition announcement MUST include the following information:
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 note that as of Candidate Recommendation, no technical issues should be open, even though the Working Group may request feedback on particular choices they have made.
[fpwd-exclusions when doc:fpwd-wd-tr] Note: The First Public Working Draft is significant with respect to the W3C Patent Policy. As explained in the Patent Policy FAQ, the Communications Team issues a Call for Exclusions (see section 4 of the W3C Patent Policy) approximately ninety days after the publication of this draft.
doc:pr-tr | per-tr | prrescind-tr |
Please use the Team-only transition announcement template as a starting point. |
---|---|
doc:cr-tr |
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 note that as of Candidate Recommendation, no technical issues should be open, even though the Working Group may request feedback on particular choices they have made. |
doc:rec-tr | rescind-tr |
|
doc:fpwd-wd-tr | fpig-note-tr | fpcg-note-tr | fpwg-note-tr notehistory:first | notchartered | none |
Note: The First Public Working Draft is significant with respect to the W3C Patent Policy. As explained in the Patent Policy FAQ, the Communications Team issues a Call for Exclusions (see section 4 of the W3C Patent Policy) approximately ninety days after the publication of this draft. |
doc:ord-wd-tr | fpwd-wd-tr | cr-tr | pr-tr | per-tr | rec-tr | rescind-tr | note-tr |
|
---|
doc:fpwd-wd-tr | cr-tr | Note: After announcement of a First Public Working Draft Candidate Recommendation the W3C Communications Team issues a Call for Exclusions in accordance with the W3C Patent Policy. See also the 2014 Process Transition FAQ. |
---|
doc:fpwd-wd-tr | cr-tr | pr-tr | per-tr | rec-tr | Note: If your specification involves 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. |
---|
doc:pr-tr | per-tr | prrescind-tr | Form and Mailing List Preparation |
---|---|
doc:fpwd-wd-tr | fpig-note-tr | fpcg-note-tr | fpwg-note-tr | cr-tr | rec-tr | rescind-tr notehistory:first | none | Mailing List Preparation |
doc:fpwd-wd-tr | fpig-note-tr | fpcg-note-tr | fpwg-note-tr | cr-tr | pr-tr | per-tr | rec-tr | prrescind-tr | rescind-tr notehistory:first | none | The Team Contact ensures that there is a mailing list with a public archive available for comments; use the mailing list request form. The Team Contact also 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. |
---|
doc:cr-tr |
|
---|
doc:fpwd-wd-tr | section 7.3.1 |
---|---|
doc:cr-tr | section 7.4 |
doc:pr-tr | section 7.5 |
doc:per-tr | section 7.7 |
doc:rec-tr | section 7.6 |
doc:prrescind-tr | section 7.9 |
doc:rescind-tr | section 7.9 |
doc:ord-wd-tr | fpwd-wd-tr | cr-tr | note-tr | The Webmaster completes publication and notifies the Chair and Team Contact of publication, cc'ing webreq@w3.org and w3t-comm@w3.org. Note: If the publication is the result of returning a document to a Working Group for further work, the Webmaster alerts the W3C Communications Team. |
---|---|
doc:cr-tr | pr-tr | per-tr | rec-tr | rescind-tr | 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. |
doc:ord-wd-tr | fpwd-wd-tr | cr-tr | pr-tr | per-tr | rec-tr | rescind-tr | note-tr |
Publication RequestA publication request is an assertion from the Document Contact that the document satisfies the pubrules requirements. The subject line and body SHOULD identify this as a "publication request"; see above for where to send the request. A publication request MUST include the following information.
Note: Someone from the W3C management team (usually the relevant Domain Leader) SHOULD be aware of the status of the document. Scheduling PublicationThe Document Contact negotiates a publication date with the Webmaster. Each publication request SHOULD propose a publication date. If the request does not include a proposed publication date, the Webmaster MAY consider the title page date as the proposed publication date. As of 2 March 2010 (cf. the announcement to chairs) the Webmaster publishes on Tuesdays and Thursdays. Regarding advance notice:
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. PublicationIn 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 1.6. 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. |
---|
doc:pr-tr | per-tr | prrescind-tr | The Communications Team builds a STATUS review form that the Team Contact and Activity Lead (or Domain Lead) review for correctness. Note: At the current time, WBS review forms are generated from installed documents, but before the Webmaster completes publication. |
---|
doc:cr-tr | Note: The Working Group MAY publish a revision of a Candidate Recommendation with minor changes before the next transition. |
---|---|
doc:cr-tr | pr-tr | per-tr | Note: The Working Group SHOULD NOT publish a (new) revision of a STATUS before the end of the (current) review period. |
doc:fpwd-wd-tr | fpig-note-tr | fpcg-note-tr | fpwg-note-tr notehistory:first | none | In order to facilitate peer review, once the document has been published, the Chair sends a transition announcement to chairs@w3.org and the group's public mailing list. |
---|---|
doc:cr-tr | pr-tr | per-tr | prrescind-tr | rec-tr | rescind-tr | The W3C Communications Team sends a transition announcement to w3c-ac-members@w3.org and chairs@w3.org and on the W3C home page. |
doc:cr-tr | pr-tr | per-tr | prrescind-tr | The Chair 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. |
doc:ord-wd-tr | cr-tr | wg-note-tr | If this publication is the result of returning a document to a Working Group for further work, the Communications Team announces that to w3c-ac-members@w3.org and chairs@w3.org. |
doc:cr-tr | per-tr | pr-tr | rec-tr | prrescind-tr | rescind-tr |
Transition Meeting with the DirectorFor a STATUS transition, the convention is to hold a transition meeting attended by:
The Team Contact is responsible for the execution of the following (under the supervision of the Domain Leader):
Sample agenda
Some reasons for declining a transition request
Per section 7.1.1 of the Process, "The Director must inform the Advisory Committee and Working Group Chairs when a Working Group's request for a specification to advance in maturity level is declined and the specification is returned to a Working Group for further work." |
---|
doc:fpwd-wd-tr | fpig-note-tr | fpcg-note-tr | fpwg-note-tr | cr-tr | pr-tr | per-tr | rec-tr | rescind-tr notehistory:first | none | Publication and Transition Announcement |
---|---|
doc:fpig-note-tr | fpcg-note-tr | fpwg-note-tr notehistory:chartered | notchartered | closure | Publication |
doc:ord-wd-tr | wg-note-tr | cg-note-tr | ig-note-tr | Publication |
doc:prrescind-tr | Transition Announcement |
doc:cr-tr | pr-tr | per-tr | prrescind-tr | rec-tr | rescind-tr | The Team Contact organizes a transition meeting with the Director to discuss the request. Note: When Advisory Committee review indicates unambiguous support, the Director may waive the need for a telephone call. |
---|
doc:fpwd-wd-tr | fpwg-note-tr | fpig-note-tr | fpcg-note-tr | cr-tr | pr-tr | per-tr | prrescind-tr | rec-tr | rescind-tr notehistory:notchartered | first | none | At least one week prior to an expected meeting with the Director, the The Chair (or Team Contact) Team Contact sends a transition request to the Domain Lead(s) responsible for the group(s) publishing the document, cc'ing w3t-comm@w3.org and chairs@w3.org. We recommend explicitly addressing the Domain Lead by name in the body of the message. Note: For the TAG, no First Public Working Draft transition request is required; the request is assumed to be approved by the Director, who Chairs the TAG. sends a transition request to the Director (and anyone working with the Director on transitions): timbl@w3.org, ralph@w3.org, plh@w3.org, cc'ing w3t-comm@w3.org and chairs@w3.org and the relevant Domain Lead. We recommend explicitly addressing the expected reviewer(s) by name in the body of the message. |
---|
doc:fpwd-wd-tr | cr-tr | pr-tr | per-tr | prrescind-tr | fpwg-note-tr | fpig-note-tr | fpcg-note-tr | rec-tr | rescind-tr notehistory:notchartered | first | none | The Domain Lead(s) approve the transition request. A Domain Lead MAY ask another Domain Lead (or the Director or someone assigned by the Director) to take responsibility for approving the transition request. The Director approves the transition request. |
---|
doc:fpwd-wd-tr | cr-tr | fpig-note-tr | fpcg-note-tr | fpwg-note-tr | pr-tr | per-tr | rec-tr | prrescind-tr | rescind-tr notehistory:notchartered | first | none |
Transition requestThe message subject line and body SHOULD identify this as a "transition request"; see above for where to send the request. A First Public STATUS transition request MUST include:
Furthermore, the transition request provides evidence that the group has satisfied the transition requirements. The questions and observations in the subsections below provide examples of what SHOULD be in the transition request to help the Domain Lead(s) Director assess whether the group has satisfied the transition requirements. The transition request SHOULD be organized so that it serves as the basis for the agenda of the meeting with the Director. The goal of the transition request is to secure an archived record of the Domain Lead(s)' approval of the title, and shortname. In the past, shortnames have been changed between versions, and documents have been split and merged between versions. A conservative approach is to treat a merged or split document like a first publication. The Team Contact(s) generally present the new draft for the entire W3C Team as soon as possible after the transition request (and possibly before Domain Lead approval). The length of the presentation varies (from "more than a lightning talk" to a Project Review) depending on the technical or political complexity of the specification. Note: All requirements related to a Proposed Edited Recommendation (PER) are limited to the scope of the changes. Note: The Director SHOULD NOT schedule a Proposed Recommendation review period to end less than 10 days after the end of an open "exclusion opportunity" as defined in the W3C Patent Policy (per section 7.5 of the W3C Process), or if there are any Patent Advisory Groups (PAGs) currently discussing the document (per the Patent Policy FAQ, question 29). Decision to request transition
Changes
Requirements satisfied
Dependencies met (or not)
Wide Review
Issues addressed
Formal Objections
Implementation
Patent disclosures
|
---|
doc:cr-tr | Note: If your specification defines an XPointer Scheme, before the transition to STATUS, please register the scheme in the the W3C XPointer Scheme Registry. |
---|