| Guide
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.
- Scope of this Document
- General Information
- Transitions
For information about requirements about documents themselves,
see publication rules.
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.
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:
- Requirements for documents themselves; see pubrules for this information.
- What required information must be public; this is covered in section
7.2 of the Process Document and in the governing patent policy.
- Possible next steps after each transition; see the description of the
Recommendation Track
Process.
- Internal Team processes (e.g., for securing approval to publish), which
are discussed in Team Processes for TR
Publications
- 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).
The following sections present general information about roles,
transition requests, publication requests, and publication itself.
- 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.
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.
- Document title
- Document URI
- Estimated publication date
- 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.
- Document Abstract
- Document Status section
Certain transition requests require additional information to be
complete; see the transitions below.
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.
A publication request MUST include
the following information.
- Document title
- Document URI
- The "this version"
URI MUST have the form
"http://www.w3.org/TR/YYYY/statuscode-shortname-YYYYMMDD"
- The "latest
version" URI MUST have the form
"http://www.w3.org/TR/shortname"
- Title page date
- The title page date MUST NOT be in the
future.
- 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.
Upon receiving publication request, the
Webmaster SHALL make a best effort to
verify that the following conditions have been satisfied:
- The publication request is complete,
- 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.
The following sections present information about specific
transitions: first public Working Draft, Last Call, and other
transitions of the Recommendation track.
Overview of complete process:
- Working Group records decision to publish first
public Working Draft.
- The Document Contact
prepares the document in accordance with
pubrules.
- The Chair sends a transition request for
a first Public Working Draft or Note.
- The Director approves the request and records the approval.
- The Document Contact
sends a publication request for a
First Public Working Draft or Note.
- The Webmaster completes publication.
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.
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.
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.
Overview of complete process:
- The Working Group satisfies the Process Document's
requirements for the transition.
- The Working Group records the decision to advance to Last Call.
- The Document Contact
prepares the document in accordance with
pubrules.
- The Chair negotiates the Last Call
review schedule with the Chairs of groups with dependences.
- The
Document Contact
sends a publication request for a Last
Call Working Draft.
- The Webmaster completes publication.
- The Chair sends a Last Call
announcement (only after the document has
been published).
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.
A publication request for Last Call Working Draft is complete if it
includes the general information for a
publication request.
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:
- Document title
- Document URI
- Review start and end dates
- 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?
- The names of groups with dependencies, explicitly inviting
review from them.
- Report of any objections
- 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.
Overview of complete process:
- The Working Group satisfies the Process Document's
requirements for the transition.
- The Working Group records decision to advance.
- The Document Contact
prepares the document in accordance with
pubrules.
- The Chair sends a transition request
for CR or beyond.
- The Chair organizes a transition meeting with the Director to discuss
the request.
- The Director approves the request and records the approval.
- The Document Contact
sends a publication request for CR or
beyond.
- The Webmaster completes publication.
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:
- 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).
- An empty cell means that the requirement is not necessary for that type
of transition.
- The row header links to more detail about the requirement.
- 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.
- Requirements related to a Proposed Edited Recommendation (PER) are
limited to the scope of the changes.
Summary of Transition Requirements
|
LC-to-CR |
CR-to-PR, LC-to-PR |
PR-to-REC, PER-to-REC |
REC-to-PER |
REC-to-PR-RSCND |
PR-RSCND-to-RSCND |
Decision to advance recorded |
Record of Chair decision |
Record of Chair decision |
|
Record of Chair decision |
Record of Chair decision |
|
Important changes to the document
reported |
Change log |
Change log |
Change log |
Change log |
|
|
Document satisfies group's
requirements |
Changes since LC |
Changes since LC/CR |
Changes since PR/PER |
Changes since REC |
|
|
Dependencies with other groups met (or
not) |
Show evidence of confirmation by other Groups and public |
Show evidence that additional dependencies related to
implementation met |
|
Show reviews by groups, list of requirements met |
|
|
Document has received wide review |
Show evidence of review by Groups and public |
Show evidence of usage by implementers |
Show Advisory Committee review |
|
Show evidence of review by Groups and public |
Show Advisory Committee review |
Issues have been formally
addressed |
Evidence in issues list |
Changes in issues list since LC/CR |
Changes in issues list since PR/PER |
Evidence in issues list |
Evidence in issues list |
Changes in issues list since PR RSCND |
Objections have been reported |
Record of decision, attempt to satisfy, objection |
Record of decision, attempt to satisfy, objection |
Record of decision, attempt to satisfy, objection |
Record of decision, attempt to satisfy, objection |
Record of decision, attempt to satisfy, objection |
Record of decision, attempt to satisfy, objection |
Implementation information |
- Preliminary report
- Any implementation reqs beyond defaults?
- Any features at risk?
|
- Final report
- Implementation reqs beyond defaults satisfied?
- Any features at risk removed?
|
|
- Final report
- Implementation reqs beyond defaults satisfied?
|
|
|
Patent disclosures |
Report of incomplete, problematic disclosures |
Changes since LC/CR |
Changes since PR/PER |
Report of incomplete, problematic disclosures |
Report of incomplete, problematic disclosures |
Changes since PR RSCND |
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:
- be organized so that it may serve as the basis for the agenda of the meeting with the Director, and
- emphasize which issues require the Director's attention
(see example for request
for OWL to CR)
- 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.
- 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.
-
Have the requirements changed since the previous transition?
Are any requirements previously satisfied no longer satisifed?
Are any requirements previously unsatisfied now
satisifed?
- 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?
- 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?
- 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?
- 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?
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):
- 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.
- Reserving a teleconference
bridge
- 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.
- 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.
- Administrative
- Is everyone here?
- Confirmation of Chair, Scribe
- Are any changes required to the agenda?
- Review of the transition request
- 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
- If the decision is negative: how do we repair the problem? what
happens next? who does what?
- 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.
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.
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:
- For an Advisory Committee review, include a Team-only list.
- 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.
- 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:
What to include in the announcement
|
LC-to-CR |
CR-to-PR, LC-to-PR |
PR-to-REC, PER-to-REC |
REC-to-PER |
REC-to-PR-RSCND |
PR-RSCND-to-RSCND |
Transition start date |
X |
X |
|
X |
X |
|
Minimal duration |
X |
|
|
|
|
|
Transition end date |
Estimate |
X |
|
X |
X |
|
Names of groups with dependencies |
Optional |
|
|
X |
X |
|
Features at risk |
Optional list of features at risk |
List of any features at risk removed |
|
|
|
|
Formal Objections |
X |
X |
X |
X |
|
X |
Document abstract/status |
X |
X |
|
X |
|
|
After the Announcement
- The Working Group tracks issues, including issues raised by the
public.
- 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.
Page owned and process managed by Steve Bratt, COO
Ian Jacobs, author
This document has been constructed by merging information from several "How
to" documents created by Dan Connolly, Al Gilman, and others.
Last modified: $Date: 2006/02/14 20:45:26 $ by $Author: ijacobs $