Organize a Recommendation Track Transition (Comparison view)

1. That this is a STATUS transition announcement.
2. Document title, URIs.
3. Instructions for providing feedback.
4. Review end date.
5. Link to information about the review; generally this is a link to an online form (created by the Communications Team). The following information from the transition request MUST be available (generally in the form):
   • title, abstract, and status. Note: It is useful to draw the reviewer's attention in the review form to important information, even if some of that information is duplicated in the status section due to pubrules requirements.
   • implementation information
   • information about changes
   • information about wide review (link to an issues list)
6. Information about any Formal Objections.
7. Link to a public (home) page for the group that produced the document.

1. That this is a STATUS transition announcement.
2. Document title, URIs.
3. Instructions for providing feedback.
4. A reference to the group's transition request.
5. Minimal duration before request to advance to next step.
6. Links to evidence that requirements for the transition have been satisfied (i.e., the same information that was in the request to advance).
7. Report of any Formal Objections.
8. Whether this publication is the result of returning a document to a working group for further work as a Candidate Recommendation.
9. Document abstract and status.

1. That this is a STATUS transition announcement.
2. Document title, URIs.
3. Indication, in general terms, of level of support of Membership. Note: As a policy, the Team does not announce detailed results (i.e., numbers of reviews) of a Proposed Recommendation review to the Membership or Public, except for information regarding formal objections.
4. Report of any Formal Objections.
5. Document Abstract and Status section

1. That this is a First Public STATUS transition announcement.
2. Document title, URIs.
3. Instructions for providing feedback.
4. A reference to the group's transition request.

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.

1. That this is a First Public and Last Call STATUS transition announcement.
2. Document title, URIs.
3. Instructions for providing feedback.
4. Review end date.
5. A reference to the group's decision to make this transition.
6. Evidence that the document satisfies group's requirements. Include a link to requirements (e.g., in the charter or requirements documents). Does the requirements document indicate where in the specification the requirements are met?
7. The names of groups with dependencies, explicitly inviting review from them.
8. Report of any Formal Objections.
9. A link to a patent disclosure page.

The Last Call transition announcement SHOULD provide information about where people can learn about issues raised during the Last Call review period (e.g., a link to an issues list).

The Last Call transition announcement MAY indicate priority feedback items. Please note that as of Last Call, no technical issues should be open, even though the Working Group may request feedback on particular choices they have made.

• The Document Contact prepares the document in accordance with pubrules and develops a proposed publication schedule. 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.
• Note: We instituted a temporary publication policy change beginning 31 March 2009. Publications will take place Tuesdays and Thursdays; only one day's notice is required. To ensure that Webmaster and Communications Team resources are available for publication, at least one day (temporarily, instead of five days in general) prior to the anticipated publication date 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). 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 7.4.6 of the Process) that explains why the document was returned for further work.
• The Team Contact sends a draft transition announcement to the Communications Team at w3t-comm@w3.org.

• The Chair negotiates the Last Call review schedule with the Chairs of groups with dependencies (on chairs@w3.org). Securing review commitments before going to Last Call will help ensure that your document receives wide review. The suggested way to negotiate a last call review schedule is to send a heads-up to the Chairs of groups with dependencies, cc'ing chairs@w3.org. Several weeks prior to the estimated Last Call start date, the Working Group should negotiate schedules with groups where there are dependencies.

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. A single sentence description of the specification (for communication purposes on the "current status" pages). The sentence may be taken from the abstract.
3. A proposed publication schedule.
4. Record of approval of the transition request.
5. Record of W3M decision to close the group.
6. Evidence that publication is in accordance with expectations set by the group charter (e.g., quote the charter).

Note: Someone from the W3C management team (usually the relevant Domain Leader) SHOULD be aware of the status of the document.

Scheduling Publication

The Document Contact negotiates a publication date with the Webmaster. Each publication request SHOULD propose a publication date, which SHOULD be at least five days later. The title page date SHOULD be the same as, or shortly before, the proposed 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.

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.

Transition Meeting with the Director

For a STATUS transition, the convention is to hold a transition meeting attended by:

• The Team contact(s)
• The Domain Leader (or someone appointed by them), who generally chairs the meeting.
• The CEO
• The Director should be invited to attend the meeting if the transition involves contentious issues such as IPR, technical or other concerns.
• The Working Group Chair(s)
• Others invited by the Domain Leader (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.

Note: Per announcement to the Chairs, beginning in February 2007, the Comm Team and QA do not generally attend transition meetings.

The Team Contact is responsible for the execution of the following (under the supervision of the Domain Leader):

1. Scheduling the meeting. To allow chairs of WGs with dependencies and other commenters time to review the treatment of last call comments in the disposition of comments document, the transition request MUST be sent a minimum of seven days prior to the transition meeting.
2. Reserving a teleconference bridge
3. Choosing a scribe prior to the meeting. Note: The CEO, Director, and Comm Team representative do not generally scribe these meetings.
4. 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 (Team and Member), and MUST be cc'ed to w3t-archive@w3.org.

Sample agenda

Administrative

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

Review of the transition request

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

Decision

The Director assesses whether the W3C Process has been followed and whether there is sufficient consensus to advance the technical report. 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 Director may delegate the W3C decision; see Team processes for TR publications.

Next steps

1. 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.
2. 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 request to advance

• The technical report has been substantively modified since the previous transition. In this case, the document is returned to the Working Group for further work.
• The Director is not satisfied with how the Working Group has addressed issues.
• The Working Group has requested to advance despite a Formal Objection and the Director is not satisfied with the Working Group's rationale.
• The Director believes that special entrance criteria have not been satisfied.

Transition request

The message subject line and body SHOULD identify this as a "transition request"; see above for where to send the request. A First Public and Last Call STATUS transition request MUST include:

1. Document title, URIs, estimated publication date
2. The document Abstract and Status sections, either by reference (e.g., the URI to the document) or direct inclusion.
3. A statement whether or not the group considers the document to be a delta specification. This statement is only required for documents expected to become normative Recommendations under the W3C Patent Policy.