Member → The Art of Consensus →

Organize a Technical Report Transition (2015 Process)

This Guidebook is the collected wisdom of the W3C Group Chairs and other collaborators.

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. A comparison of requirements across all document types is available.

Steps for Publication of an Ordinary Working Draft

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.

Publication Planning

• 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. Note: Director approval is required for some namespace URIs; see URIs for W3C Namespaces for details.
• Before sending the publication request, the Document 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. Note: If the publication is the result of returning a document to a Working Group for further work, the Team Contact alerts the W3C Communications Team by sending to w3t-comm@w3.org a draft announcement for the Membership (required by section 6.1.1 of the Process) that explains why the document was returned for further work.

Publication

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

Note: Instructions for publication of an Ordinary Working Draft 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 Working Draft:

• The Group should publish a Working Draft to the W3C Technical Reports page when there have been significant changes to the document that would benefit from review beyond the Working Group.
• The Group may request publication of a Working Draft even if its content is considered unstable and does not meet all Working Group requirements.

Here are the W3C Process Document transition requirements for a Working Draft:

• The Group must record the group's decision to request publication.
• The Group must provide public documentation of substantive changes to the technical report since the previous Working Draft.
• The Group should document outstanding issues, and parts of the document on which the Working Group does not have consensus.
• The Group should provide public documentation of significant editorial changes to the technical report since the previous step.
• The Group should report which, if any, of the Working Group's requirements for this document have changed since the previous step.
• The Group should report any changes in dependencies with other groups.
• The Group should provide information about implementations known to the Working Group.

Publication Request

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.

1. Document title and URI(s). Document URI requirements are described in Publication Rules.
2. One or two sentences of description of the specification (for communication purposes on the "current status" pages). The sentence may be taken from the abstract. As an example, see status section for specifications related to mobile web authoring. These status pages, as their name suggests, let the community know about relationships among close specifications, what to use and not to use, how things fit together, etc. Contact the Comm Team with questions at w3t-comm@w3.org. Note: The Webmaster may also ask the Document Contact for assistance in categorizing the specification in an existing (or new) group on the TR page.
3. A proposed publication schedule.

Scheduling Publication

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 checker reports issues that are confusing, please send the publication request no later than 3 business days prior to the desired publication date and in the request explicitly state which issues require Webmaster attention.
• otherwise, please send the publication request no later than 1 business day prior to the publication date (and 2 days is even better).

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

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:

1. The publication request is complete, and
2. 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.