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
Publication of an
First Public
and
Last Call
Ordinary
STATUS
Once the Process Document requirements for the transition to
First Public
and
Last Call
STATUS have been satisfied
(see
section 7.4.1
section 7.4.2
sections
section 7.4.1 and
section 7.4.2
section 7.4.3
section 7.4.4
section 7.6.3
section 7.4.5
section 7.7.1
section 7.7.2 under "Entrance Criteria"),
W3C follows the steps described below to complete the transition.
W3C follows the steps described below for transition to a
First Public
STATUS.
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
First Public
and
Last Call
STATUS, see also How to Register
an Internet Media Type for a W3C Specification
to review the entire Internet Media Type
registration process.
for information about
what must be included in
the section of your Last Call Working Draft and how to request review
within the
IETF.
for information about
alerting the W3C liaisons to the
IETF so that they may request formal review and approval by the
IESG.
for information about
how the W3C liaisons to the IETF track the registration process.
Note: If your specification defines an XPointer
Scheme, before the transition to STATUS, please register the scheme in the the W3C XPointer Scheme
Registry.
- Negotiation of Review Schedule
-
-
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.
- 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
The
Chair (or Team Contact)
Team Contact
sends a transition request to
the Domain Lead(s) responsible for the group(s) publishing the
document, cc'ing w3t-comm@w3.org and chairs@w3.org. We recommend explicitly addressing the Domain Lead by name in the body of the message.
Note:
For the TAG, no First Public Working Draft transition request is required; the request is assumed to be approved by the Director, who Chairs the TAG.
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
and
the relevant Domain Lead. 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.
Note: When Advisory Committee review indicates
unambiguous support, the Director may waive the need for a telephone
call.
-
The Domain Lead(s) approve the transition request.
A Domain Lead MAY ask another Domain Lead (or the
Director or someone assigned by the Director) to take responsibility for approving the transition request.
The Director approves the transition request.
- Publication and Transition Planning
- Publication Planning
- 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 7.4.6 of the Process) that explains why the document was
returned for further work.
- Form and Mailing List Preparation
- Mailing List Preparation
-
-
The Team Contact ensures that there is a mailing list with
a public archive
available for comments; use the mailing list request
form.
The Team Contact also ensures that there is a mailing list with
a Team-only archive available for AC Representative comments; this list
is cited from the review form.
-
The Team Contact builds a
STATUS
review
form that the Activity Lead (or Domain
Lead) reviews for correctness.
Note:
At the current time, WBS review forms are generated from
installed documents, but before the Webmaster completes
publication.
- The
Team Contact sends a draft transition announcement
to the Communications Team at w3t-comm@w3.org.
- Publication and Transition Announcement
- Publication
- Publication
- Transition Announcement
-
- 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.
-
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.
-
In order to facilitate peer review, once the document has been
published, the Chair sends a
transition announcement
to chairs@w3.org and the group's public mailing list.
-
The W3C Communications Team sends a
transition announcement
to w3c-ac-members@w3.org
and chairs@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.
-
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: After announcement of a
First Public or Last Call Working Draft, the W3C Communications Team issues a Call for Exclusions in accordance with the
W3C Patent Policy.
Note: Instructions for publication of
an Ordinary
STATUS
are included for convenience even though
this is not a Recommendation
Track transition as defined in the W3C Process.
Note: The Working Group
MAY
publish a revision of a Candidate Recommendation with minor changes
before the next transition.
Note: The
Working Group SHOULD NOT publish a
(new) revision of a STATUS before the end
of the (current) review period.
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:
- 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.
-
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.
- Document title and URIs.
- Rationale for why it is appropriate to rescind the Recommendation.
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
Domain Lead(s)
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 goal of the
transition request is to secure an archived record of the
Director's
Domain Lead(s)'
approval of the title, and shortname.
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.
The Team Contact(s) generally present the new draft for the entire W3C
Team as soon as possible after the transition request (and possibly
before Domain Lead approval). The length of the presentation varies
(from "more than a lightning talk" to a Project Review) depending on
the technical or political complexity of the specification.
Note:
All requirements related to a Proposed Edited
Recommendation (PER) are limited to the scope of the changes.
Note:
When a Working Group "skips CR", then
for the transition to Proposed Recommendation, the Working Group must
satisfy both the requirements to advance to CR and to advance
to PR.
Note: In general, the Director will
not approve a request to advance to Proposed Recommendation status if
there are any open "exclusion opportunities" under the W3C Patent
Policy (per the Patent
Policy FAQ, question 24) or any Patent Advisory Groups
(PAGs) currently discussing the document
(per the Patent Policy FAQ, question 29).
- 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.
- Were features at risk removed?
- 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?
- 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 satisfied? Are
any requirements previously unsatisfied now satisfied?
- Does this specification have any normative references to W3C
specifications that are not yet
Proposed Recommendations? See Normative References Guidelines.
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?
- Is there evidence that additional dependencies
related to implementation have been satisfied?
- Was there wide
review by groups with dependencies?
- Was there review from implementers?
- Was there review from
Advisory Committee representatives?
- 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.
The Director is responsible for addressing
those issues raised by the Advisory Committee
during a Proposed Recommendation and
Proposed Edited Recommendation review period.
Typically the Director consults with the group.
Per the
Process Document, section 7.3, the Director
MAY
respond to the reviewer after the close of the Proposed Recommendation
review period (e.g., in the announcement of the transition
to Recommendation).
For substantive issues, especially substantive or
serious technical issues the Team Contact should endeavor to understand the
reviewer's issues and try to resolve them before sending the Director
a 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?
- For each objection, is there a record of the decision,
the objection, and attempts to satisfy the reviewer?
- Have the
default requirements of the Process Document been satisfied (e.g.,
implementation of each feature, preferably two implementations)?
- 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.
- The request MUST
Include a link to a
final implementation report, or, if there is no such report,
rationale why the Director should approve the request nonetheless.
- 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?
- Are there any open exclusion opportunities? See Patent Policy FAQ question 24:
The W3C Team will not, however, start a Proposed Recommendation review period until all current exclusion opportunities for a given specification have ended.
- If the group is not using IPP: Does the disclosure page conform to the patent policy
requirements?
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.
- 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.
-
Whether the only change since the previous Last Call (if any) is that text has been deleted; If so, W3C can skip the Patent Policy Exclusion (see the Patent Policy FAQ).
- Record of approval of the transition request.
- Record of W3M decision to close the group.
- 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.
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
First Public
and
Last Call
STATUS transition announcement MUST include the following information:
- That this is a
STATUS
transition announcement.
- Document title, URIs.
- Instructions for providing feedback.
- Review end date.
- Link to information about the review; generally this is a link
to an online form (created by the Team Contact). 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)
- Information about any Formal Objections.
- Link to a public (home) page for the group that produced the document.
Please use the Team-only transition
announcement template as a starting point.
- That this is a STATUS
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.
- That this is a STATUS
transition announcement.
- Document title, URIs.
- A paragraph introducing the work, usually the Abstract.
- 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.
- Report of any Formal Objections.
- Any additional information for companion document(s).
- That this is a
First Public
STATUS
transition announcement.
- Document title, URIs.
- Instructions for providing feedback.
- 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.
- That this is a
First Public and
Last Call
STATUS
transition announcement.
- Document title, URIs.
- Instructions for providing feedback.
- Review end date.
- A reference to the group's decision to make this transition.
- 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 Formal Objections.
- 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.