About This Document
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.
Steps for
Transition to
Candidate Recommendation
Once the Process Document requirements for the transition to
Candidate Recommendation have been satisfied
(see
section 7.4.3
under "Entrance Criteria"),
W3C follows the steps described below to complete the transition.
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.
Note: If your specification involves an Internet
Media Type, before the transition to
Candidate Recommendation, see also
How to Register
an Internet Media Type for a W3C Specification
for information about
alerting the W3C liaisons to the
IETF so that they may request formal review and approval by the
IESG.
Note: If your specification defines an XPointer
Scheme, before the transition to Candidate Recommendation, please register the scheme in the the W3C XPointer Scheme
Registry.
- Transition request
-
- The Team Contact reviews the (Team-only) pre-publication steps.
-
At least one week prior to an expected
meeting with the Director, the
Chair (or Team Contact)
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
. We recommend explicitly addressing the expected reviewer(s) by name in the body of the message.
-
The Team Contact organizes a transition meeting
with the Director to discuss the request.
-
The Director approves the transition request.
- Publication and Transition 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.
- Mailing List Preparation
-
- Publication and Transition Announcement
-
-
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.
-
The W3C Communications Team sends a
transition announcement
to w3c-ac-members@w3.org
and on the W3C home page.
- 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.
Note: The Working Group
MAY
publish a revision of a Candidate Recommendation with minor changes
before the next transition.
Transition request
The message subject line and body SHOULD identify this as a "transition request";
see above for where to send the request.
A
Candidate Recommendation transition request MUST include:
- Document title, URIs, and estimated
publication date.
- The document Abstract and Status sections, either
by reference (e.g., the URI to the document) or direct inclusion.
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
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 request SHOULD include a link to the
meeting minutes or email announcing the group's decision
to request the transition.
- 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.
- Have the requirements changed since the previous transition?
Are any requirements previously satisfied no longer satisfied? Are
any requirements previously unsatisfied now satisfied?
- Does this specification have any normative references to W3C
specifications that are not yet
Candidate Recommendations?
Note: In general, documents do not advance to
Recommendation with normative references to W3C
specifications that are not yet Recommendations. See Normative References Guidelines.
- 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?
- Was there wide
review by groups with dependencies?
- Any review from other organizations?
- Include a link to an issues list that indicates that the Group
has been responsive to reviewers who have raised issues since
the previous transition. 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 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?
- For each objection, is there a record of the decision,
the objection, and attempts to satisfy the reviewer?
- 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 are the Group's plans for showing implementation of
optional features? In general, the Director expects mandatory
features and optional features that affect interoperability to be
handled similarly. Optional features that are truly optional (i.e.,
that do not affect interoperability) may require less
implementability testing.
- Is there a preliminary implementation report? The
implementation report should be a detailed matrix showing which
software implements each feature of the specification.
- What are expectations about additional software that is
expected to implement the specification during CR?
- What is the minimal duration of the CR period? Estimate of how
long it will take before requesting PR?
- Are there any
features at risk?
- 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?)?
- 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?
If there are tests or test suites available, are there links
between the tests and the features of the specification they
purport to test?
Patent disclosures
- Has anything changed on the patent disclosure page since the
previous transition?
Have there been any incomplete or problematic disclosures?
- If the group is not using IPP: Does the disclosure page conform to the patent policy
requirements?
For a Candidate Recommendation 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.
- Those assigned by the Director to manage transitions.
- 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):
- 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.
- Reserving a teleconference
bridge.
- Choosing a scribe prior to the meeting.
- 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 attendees, 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
- 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 support the transition
request.
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
-
- 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.
- 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 transition request
- 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 issued a transition request despite a
Formal Objection and the Director is not satisfied with
the Working Group's rationale.
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.
- Document title and URI(s). Document URI requirements are described
in Publication Rules.
-
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.
- A proposed publication schedule.
- Record of approval of the transition request.
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.
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:
- The publication request is complete, and
- 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 Announcement
A
Candidate Recommendation transition announcement MUST include the following information:
- That this is a Candidate Recommendation
transition announcement.
- Document title, URIs.
- Instructions for providing feedback.
- A
reference to the group's transition request.
- Minimal duration before
next transition request.
- Links to evidence that requirements for the transition have been
satisfied (i.e., the same information that was in the transition request).
- Report of any Formal Objections.
- Whether this publication is the result
of returning a document to a working group for further work as a Candidate Recommendation.
- Document abstract and status.
Please use the Team-only transition
announcement template as a starting point.
Page owned and process managed by
Philippe Le Hégaret and Ralph Swick on behalf of the W3C Director.
Coralie Mercier, editor
This document has been constructed by merging information from
several "How to" documents created by Dan Connolly, Al Gilman, and
others. A filter is applied to
the document source to provide
transition-specific views.
Last modified: $Date: 2016/08/04 14:37:59 $ by $Author: ijacobs $