How to Organize a Recommendation Track Transition

This version has been superseded. See the latest version.

This document explains the processes W3C uses internally to prepare and carry out a transition of a document on the Recommendation Track.

1. Scope of this Document
2. General Information
   • Roles
   • Transition requests
   • Publication requests
   • Publication
3. Transitions
   • First Public Working Draft or Note
   • Last Call Working Draft
   • Candidate Recommendation and Beyond

For information about requirements about documents themselves, see publication rules.

Status of this document

This document is being prepared as part of the Patent Policy implementation. It is being revised along with pubrules and the Process Document, for review by the Team and Advisory Board.

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in RFC 2119.

1. Scope of this Document

This document discusses the processes for preparing and announcing a document transition. Exceptions to these processes MAY be authorized by the Director or Chief Operating Officer (COO).

This document does not address:

1. Requirements for documents themselves; see pubrules for this information.
2. What required information must be public; this is covered in section 7.2 of the Process Document and in the governing patent policy.
3. Possible next steps after each transition; see the description of the Recommendation Track Process.
4. Internal Team processes (e.g., for securing approval to publish), which are discussed in Team Processes for TR Publications
5. The Comm Team's policy regarding in-place modification of W3C Technical Reports.

In this document, consistent with the Process Document, the following terms are used. A Recommendation Track (Rec Track) document is one of the following: First Public Working Draft (FPWD), Working Draft (WD), Candidate Recommendation (CR), Proposed Recommendation (PR), Recommendation (REC), Proposed Edited Recommendation (PER), Rescinded Recommendation (RSCND), or Working Group (or Interest Group or Coordination Group) Note (NOTE).

2. General Information

The following sections present general information about roles, transition requests, publication requests, and publication itself.

2.1 Roles

• The Webmaster publishes documents; the role is performed by someone on the W3C Communications Team. As of July 2003, Vivien Lacourba generally does this work, and Janet Daly, the W3C Head of Communications, provides management support.
• The Director may assign Director responsibilities to other Team members. Quite often the COO takes on the Director responsibilities for these processes.
• Chair responsibilities may be carried out by either the Chair or Team Contact.
• The Document Contact is either the Team Contact of the group requesting publication, or the document editor. Consult the W3C Head of Communications if you're not sure who is the relevant Team contact.

2.2 Transition Requests

All transition requests are sent to timbl@w3.org, steve@w3.org, cc'ing w3t-comm@w3.org and webreq@w3.org. All transition requests except for PR-to-Rec are sent to timbl@w3.org, steve@w3.org, cc'ing w3t-comm@w3.org and webreq@w3.org.

All transition requests MUST include the following information to be complete.

1. Document title
2. Document URI
3. Estimated publication date
4. Record of the group's decision to advance for all transitions except PR-to-Rec, PER-to-REC, and PR-RSCND-to-REC.
   • For example, include a link to the minutes of the teleconference when the decision was made, or to another announcement from the Chair on the Group's mailing list.
5. Document Abstract
6. Document Status section

Certain transition requests require additional information to be complete; see the transitions below.

2.3 Publication Requests

All publication requests are sent to the Webmaster, cc'ing webreq@w3.org. The Document Contact MAY cc w3c-archive@w3.org for a Member-visible record of the publication request.

Before a 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.

2.3.1 What to Include in the Publication Request

A publication request MUST include the following information.

1. Document title
2. Document URI
   1. The "this version" URI MUST have the form "http://www.w3.org/TR/YYYY/statuscode-shortname-YYYYMMDD"
   2. The "latest version" URI MUST have the form
      "http://www.w3.org/TR/shortname"
3. Title page date
   1. The title page date MUST NOT be in the future.
   2. The title page date SHOULD NOT be too far in the past. If so, the Webmaster SHOULD repond to the person who sent the request, asking for a document with an appropriate title page date.

Certain publication requests require additional information to be complete; see the transitions below.

For those documents that do not require authorization from the Director to publish, someone from the W3C management team (usually the the relevant Domain Leader) SHOULD be aware of the status of the document.

Note to Document Contacts: If you want to synchronize document's title page date with the actual date the document becomes available in the tech reports index (or with anything else), the editor must negotiate the date with the Communications Team to ensure their schedule permits. Five days advance notice is appreciated; more notice is even better, and experience shows that less than five days is risky.

2.4 Publication

Upon receiving publication request, the Webmaster SHALL make a best effort to verify that the following conditions have been satisfied:

1. The publication request is complete,
2. The document satisfies pubrules.

If the conditions have been satisfied, the Webmaster SHALL publish the document by updating the appropriate technical report index, updating the latest version link, and announcing publication to the person who sent the request, cc'ing webreq@w3.org, and w3t-comm@w3.org. If the conditions have not been satisfied, the Webmaster SHALL NOT publish the document and SHALL provide details to the person who sent the request about which requirements have not been satisfied.

After the Webmaster publishes the document, the Comm Team announces the publication on the W3C Home Page and may send additional announcements (e.g., to the AC). The publication should precede announcements by only a small amount of time.

3. Transitions

The following sections present information about specific transitions: first public Working Draft, Last Call, and other transitions of the Recommendation track.

3.1 First Public Working Draft or Note

Overview of complete process:

1. Working Group records decision to publish first public Working Draft.
2. The Document Contact prepares the document in accordance with pubrules.
3. The Chair sends a transition request for a first Public Working Draft or Note.
4. The Director approves the request and records the approval.
5. The Document Contact sends a publication request for a First Public Working Draft or Note.
6. The Webmaster completes publication.

3.1.1 Transition Request for First Public Working Draft or Note

A transition request for a first public Working Draft or Note must include the general information for a transition request. The goal of the transition request is to secure an archived record of the Director's approval of the title, and shortname. Explicit authorization from the Director is required by chapter 7 of the Process Document.

Note: In this document, "first publication" means "the first time a document with this short name appears on the TR page." 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.

3.1.2 Publication Request for First Public Working Draft or Note

A publication request for First Public Working Draft or Note is complete if it includes the general information for a publication request and a reference to the Director's approval to publish the first public draft.

3.1.3 Transition Announcement for First Public Working Draft

The Chair of the Working Group MUST announce the publication of the First Public Working Draft to chairs@w3.org, cc'ing w3t-comm@w3.org. The Communications Team MUST send a Call for Exclusions (see section 4 of the W3C Patent Policy) announcing that Members participating in the Working Group have 150 days from the title page date of the First Public Working Draft to exclude essential claims. The announcement MUST specify the deadline for exclusions.

3.2 Working Draft to Last Call

Overview of complete process:

1. The Working Group satisfies the Process Document's requirements for the transition.
2. The Working Group records the decision to advance to Last Call.
3. The Document Contact prepares the document in accordance with pubrules.
4. The Chair negotiates the Last Call review schedule with the Chairs of groups with dependences.
5. The Document Contact sends a publication request for a Last Call Working Draft.
6. The Webmaster completes publication.
7. The Chair sends a Last Call announcement (only after the document has been published).

3.2.1 Negotiating Last Call Review Schedule

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 dependences, cc'ing chairs@w3.org. The Working Group should negotiate schedules with groups where there are dependencies several weeks in advance of the proposed Last Call start date.

3.2.2 Publication Request for Last Call Working Draft

A publication request for Last Call Working Draft is complete if it includes the general information for a publication request.

3.2.3 Announcement of Last Call

The Chair sends a Last Call announcement to chairs@w3.org and the group's public mailing list. All Last Call announcements MUST include the following information:

1. Document title
2. Document URI
3. Review start and end dates
4. 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?
5. The names of groups with dependencies, explicitly inviting review from them.
6. Report of any objections
7. A link to a patent disclosure page

The last call announcement may also 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 announcement MUST include a reminder that, per the W3C Patent Policy, Working Group participants have 60 days from the publication of the Last Call Working Draft to exclude any claims made essential by the Last Call Working Draft not included in earlier drafts. The announcement MUST specify the deadline for these exclusions.

3.3 Candidate Recommendation and Beyond

Overview of complete process:

1. The Working Group satisfies the Process Document's requirements for the transition.
2. The Working Group records decision to advance.
3. The Document Contact prepares the document in accordance with pubrules.
4. The Chair sends a transition request for CR or beyond.
5. The Chair organizes a transition meeting with the Director to discuss the request.
6. The Director approves the request and records the approval.
7. The Document Contact sends a publication request for CR or beyond.
8. The Webmaster completes publication.

3.3.1 Requirements for the transition

Section 7.2 of the Process Document describes the requirements a Working Group must satisfy before transitions on the Recommendation Track starting with Candidate Recommendation. In the table below, each column represents a type of transition and each row a transition requirement. Each column identifies the type of information that the Working Group is expected to show in order to satisfy that requirement for that transition. Thus, each column represents what the Working Group is expected to complete in order to become eligible for that transition.

The Chair reports on the Working Group's assessment that it has satisfied the requirements for each transition. The Director evaluates this assessment as part of the decision to approve the transition.

The table below summarizes the requirements the Working Group MUST address to the satisfaction of the Director. In the table:

1. Table columns refer to each Recommendation Track transition: Call for Implementations (CR), Proposed Recommendation (PR), Publication of Recommendation (REC), Proposed Edited Recommendation (PER), Proposed Rescinded Recommendation (PR RSCND), and Publication of Rescinded Recommendation (RSCND).
2. An empty cell means that the requirement is not necessary for that type of transition.
3. The row header links to more detail about the requirement.
4. Certain requirements need only be met for changes that have occurred since the previous transition. For instance, at Proposed Recommendation, the Working Group only needs to report about whether dependencies have been satisfied if the dependencies have changed since the previous transition. The key "Changes" means that the requirement only applies to changes that have occurred since the previous transition.
5. Requirements related to a Proposed Edited Recommendation (PER) are limited to the scope of the changes.

3.3.2 Transition Request for CR and Beyond

A transition request for CR or beyond presents evidence to the Director that they have satisfied the transition requirements. The transition request MUST satisfy the general transition request requirements. The request SHOULD also:

1. be organized so that it may serve as the basis for the agenda of the meeting with the Director, and
2. emphasize which issues require the Director's attention (see example for request for OWL to CR)
3. be sent at least one week prior to an expected meeting with the Director

The Director expects the Working Group to be able to answer the following questions. Experience shows that these are often pertinent to the Director's decision; they reflect the transition requirements summarized in the previous table. Unless otherwise indicated, the bullets below apply to all transition types starting with CR.

Report of important changes to the document

• Have there been any important changes to the document since the previous transition? Include, for example, a link to a change log where important changes are highlighted.
• Would these changes invalidate someone's earlier review? If there have been substantial changes to the document since the previous transition (except for the removal of feature at risk), the Working Group must republish the document as a Working Draft.
• For CR-to-PR or LC-to-PR:
  • Were features at risk removed from a Candidate Recommendation?
  • 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 supersede or obsolete the 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?
• For REC-to-PER, were there any changes that would affect conformance of software or documents? Have other groups confirmed this? See section 7.6.2 of the Process Document.

Evidence that the document satisfies group's requirements

• Have the requirements changed since the previous transition? Are any requirements previously satisfied no longer satisifed? Are any requirements previously unsatisfied now satisifed?

Evidence that dependencies with other groups met (or not)

• Does this specification have any normative references to W3C specifications that are not yet Proposed Recommendations?
• For LC-to-CR, 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?
• For CR-to-PR or LC-to-PR, is there evidence that additional dependencies related to implementation have been satisfied?

Evidence that the document has received wide review (e.g., as shown in an issues list)

• Any review from other organizations?
• For LC-to-CR and REC-to-PR-RSCND, review from Chairs of groups with dependencies?
• For CR-to-PR and LC-to-PR, review from implementers?
• For PR-to-REC, PER-to-REC, and PR-RSCND-to-RSCND, review from Advisory Committee representatives?

Evidence that issues have been formally addressed

• Include a link to an issues list that indicates that the Group has been responsive to reviewers. The Director's expectations are that, as a document advances, the Working Group will keep an increasingly precise record of how it has formally addressed each issue. For issues raised during a Recommendation review, the Group must formally address them, but (per the Process Document, section 7.3 MAY respond to the reviewer after the close of the Proposed Recommendation review period; one way to respond is via the Director's decision. However, for substantive issues, especially substantive or serious technical issues the Group should endeavor to understand the reviewer's issues and try to resolve them before sending the request to advance to Recommendation. The request to advance to Recommendation should document the success or failure of these negotiations.
• 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.

Objections

• Have there been any objections since the previous transition? Is there evidence of having tried to satisfy the reviewer?

Implementation information

• Are there test suites? What is the relation between the test suites and conformance to the technical report? Is the QA situation generally clear and satisfactory?
• What are expectations about upcoming implementations?
• For LC-to-CR:
  • Is there a preliminary implementation report? The implementation report should be a detailed matrix showing which software implements each feature of the specification.
  • Are there tests or test suites available that will allow the WG to demonstrate/evaluate that features have been implemented? If not, what metrics will the WG use? If there are special conditions for this specification related to evaluation of implementations, what are they? Are test suites planned at any time? Is the WG coordinating with the QA Activity?
  • If there are tests or test suites available, are there links between the tests and the features of the specification they purport to test?
  • What are expectations about additional software that is expected to implement the specification during CR?
  • Are there any features identified as being at risk?
  • Are there any implementation requirements beyond the defaults of the Process Document? For instance, 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 is the minimal duration of the CR period? Estimate of how long it will take before requesting PR?
  • 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?)?
• For CR-to-PR and LC-to-PR, is there a final implementation report? Have the default requirements of the Process Document been satisfied (e.g., implementation of each feature, preferably two implementations)? If any additional implementation requirements, were they satisfied? Were any features at risk removed?
• For REC-to-PER, is there a final implementation report? Have the default requirements of the Process Document been satisfied (e.g., implementation of each feature, preferably two implementations)? If any additional implementation requirements, were they satisfied?

Patent disclosures

• Has anything changed on the patent disclosure page since the previous transition? Are there any incomplete or problematic disclosures?
• Does the disclosure page conform to the patent policy requirements?

3.3.3 Organizing a transition meeting with the Director

Prior to any 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 COO
• The Director should be invited to attend the meeting if the transition involves contentious issues such as IPR, technical or other concerns.
• A representative of the Comm Team
• A representative of the QA Activity. Note: It is not necessary to have someone represent the QA Activity at a Recommendation transition meeting unless there are particular QA issues that need to be addressed.

The following also attend the Director's meeting for CR, PR, and PER transitions:

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

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 in advance of the transition meeting.
2. Reserving a teleconference bridge
3. Choosing a scribe in advance of the meeting Note: The COO, Director, QA Activity representative, 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 Director's 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

1. Review the items in the transition request identified as requiring the Director's attention.

Director's decision

The Director decides whether to advance the technical report. In most cases the decision 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 this 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?
2. If the decision is positive: how do we announce this decision? When? We had talked about a press release; is that still a go? Schedule? Action items?

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 is requesting to advance despite an outstanding minority opinion, and the Director is not satisfied by the Working Group's rationale.
• The Director believes that special entrance criteria (e.g., at PR) have not been satisfied.

3.3.4 Publication Request for CR Document or Beyond

A publication request for CR or beyond is complete if it includes the general information for a publication request as well as a reference to the Director's approval to publish the document.

3.3.5 Transition Announcement for CR or Beyond

The Comm Team sends the announcement to w3c-ac-members. For other announcements except PR, the Comm Team also sends the announcement to chairs. The Chair SHOULD forward announcements to the Working Group's public mailing list.

Before the Announcement

Before announcing the transition, the Team Contact MUST:

• Ensure that all relevant mailing lists (e.g., for reviews) have been created; use the mailing list request form. In particular, ensure that a public mailing list for comments is available.
• For PR, PER, and PR RSCND, help the Comm Team build a review form.
• Send a draft transition announcement to w3t-comm.

What to Include in the Announcement

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.

All announcements of a transition CR and beyond MUST include the following information:

• The type of announcement (e.g., call for implementation)
• Document title, URI(s), publication date
• Link to public patent disclosure page
• Email address(es) for comments:
  1. For an Advisory Committee review, include a Team-only list.
  2. For an Advisory Committee review, indicate that AC reps may share their review for discussion on w3c-ac-form, or just for Member-visibility on w3c-archive.
  3. For any review, include a list for public comments (e.g., the Working Group's public list).
• Links to evidence that requirements for the transition have been satisfied (i.e., the same information that was in the request to advance).

In addition, an announcement MUST include the following information, according to transition type:

After the Announcement

1. The Working Group tracks issues, including issues raised by the public.
2. The Working Group may publish a revision of a Candidate Recommendation with minor changes before the next transition. The Working Group should not publish a revision of a Working Draft, Proposed Recommendation, or Proposed Edited Recommendation before the end of the review period.