About This Document
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.
Steps for
transition to
an update request for a
publication of a
publication of an
LABEL
Snapshot
(intended to update a Recommendation)
Draft
(with candidate corrections)
(with candidate additions)
(with proposed corrections)
(with proposed additions)
(with editorial changes)
(incorporating proposed corrections)
(incorporating proposed additions)
Once the Process Document requirements for the transition to
LABEL have been satisfied
(see
section 6.3.5
section 6.3.7
section 6.3.8.1
section 6.3.9
section
6.3.11.5 and section 6.3.4
section 6.3.11.3
section 6.3.11.4
section 6.3.10
or section 6.3.12.4 for restoring a
Recommendation
section 6.3.12.4
section 6.3.12.4),
W3C follows the steps described below to complete the transition.
Once the Group determined that the requirements of section 6.3.6 apply, the W3C follows
the steps described below to update a
STATUS.
Once the Group, or the Maintainer Contact, determined that the requirements of section 6.3.11.2 apply, the W3C follows
the steps described below to update a
STATUS.
Once the Group determined that the requirements of section 6.3.8.2 have been
satisfied, the Working Group follows the steps described below to publish a
STATUS.
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 (or updates) an Internet
Media Type, before the transition to
First Public
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 you should do several months before advancing
to Candidate Recommendation.
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 (or updates) an XPointer
Scheme, before the transition to STATUS, please register the scheme in the W3C XPointer Scheme
Registry.
- Negotiation of Review Schedule
-
-
The Chair negotiates the wide review
schedule with the Chairs of groups with dependencies (on chairs@w3.org) before going to
STATUS.
The Group MUST show that the
specification has received
wide review in order to move to Candidate Recommendation.
The Group MUST show that
all horizontal
*-needs-resolution
issues have been closed by the relevant
horizontal group in the horizontal group's tracker
in order to publish the STATUS.
The Group MUST show that any
horizontal *-needs-resolution
issues have been acknowledged in order to publish
the STATUS.
The Group MUST show that the changes
have received wide review in order to publish the STATUS.
See the considerations, guidelines and best practices
that groups should follow to get early and wide review of a document.
- Transition request
- Update request
-
- If an individual
made a request to the relevant Working Group, or the TAG (using w3ctag/obsoletion) if such a group does not exist,
to obsolete or to supersederescind
a Recommendation, and the request was not answered within 90 days, the individual should
send his request to webreq@w3.org, cc'ing plh@w3.org, www-archive@w3.org.
-
At least one week prior to an expected
decision from or meeting with the Team, the
The Document Contact
creates a transition request in w3c/transitions.
For the purpose of the automatic publishing
system, it's important that the title of the issue ends with the shortname of your
specification, thus you will need one single issue for each specification.
Note:
For the TAG, no First Public Working Draft transition request is required; the request is assumed to be
approved by the Team.
sends a transition request to
the Team: ralph@w3.org, plh@w3.org, cc'ing ylafon@w3.org,
w3t-comm@w3.org. An issue is also created in w3c/transitions (for tracking purposes).
A public archive of
transition requests is available (since October 2019).
-
Following an initial review by the Team, the Document Contact
MAY be asked to organize a transition meeting
with the Team to discuss the request.
-
The Project Management
Industry or Strategy Lead approve the transition request.
The Lead MAY ask the
CEO (or someone assigned by the CEO) to take responsibility for approving the transition
request.
The Team verifies the transition request.
Approvals are expected to appear as an issue comment "Transition
approved." in w3c/transitions
and
the label 'Awaiting
Publication' will need to be set.
In most cases the decision to approve the transition is made on Fridays.
-
- Publication Planning
-
-
The Document Contact ensures that
there is a public archived github repository
available for comments.
- The Document Contact prepares the
document in accordance with pubrules (use the "Echidna-ready"
check).
-
If the publication is the result
of stopping work on a specification, the Document Contact
alerts the
Webmaster at webreq@w3.org,
optionally cc'ing w3c-archive@w3.org (which has a Member-visible archive).
-
-
The Document Contact ensures that
there is a public archived place (github or mailing list)
available for comments; (for mailing list, the Team Contact uses the mailing list request
form).
- If an individual made a request to the
relevant Working Group, or the Maintainer Contact, to update a
Recommendation, and the request was not answered within 90 days, the individual should
create a transition request in w3c/transitions to draw attention.
-
The Document Contact ensures that
there is a public archived github repository
available for comments.
- 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.
- Before sending the publication request, the Team 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.
If the publication is the result
of stopping work on a specification, the Document Contact
alerts the
Webmaster as well.
- Form and Announcement Preparation
- Announcement Preparation
-
-
The
Document Contact sends a draft transition announcement
to the Communications Team at w3t-comm@w3.org, which explains why the document was returned for further
work.
-
The Team Contact builds a
STATUS
review
form that the Project Manager reviews for correctness. The Team Contact 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.
Note:
At the current time, WBS review forms are generated from
installed documents, but before the Webmaster completes
publication.
- The
Document Contact sends a draft transition announcement
to the Communications Team at w3t-comm@w3.org.
If the publication is the result
of returning a document to a Working
Group for further work, the announcement
explains why the document was returned for further work.
- The Communications Team
approves the draft using an issue comment
"Draft transition
approved"
in w3c/transitions
- Publication and Transition Announcement
- Publication and Update Announcement
- 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.
- The Document
Contact
publishes the document using the W3C automatic system.
-
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 makes an
announcement on the W3C home page.
-
The W3C Communications Team sends the transition announcement to
w3c-ac-members@w3.org and chairs@w3.org.
-
Since September 2015, the Communications Team no longer posts homepage news for regular WDs, unless
explicitely requested.
-
The W3C Communications Team sends the
transition announcement
to w3c-ac-members@w3.org
and
chairs@w3.org
and on the W3C home page.
The Advisory Committee review is started.
The Call for Exclusions and the Advisory Committee review are started.
-
The W3C Communications Team sends the
update announcement
to chairs@w3.org and on the W3C home page.
- The Chair or Team Contact(s) 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.
- The
Document Contact SHOULD forward the announcement to the Working
Group's public mailing list.
- The Team
Contact SHOULD forward the announcement to the appropriate public forum
taking caution not to
send any Member-confidential information to a public list.
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:
STATUS
is not a maturity stage defined in the W3C Process but is described as a proposal before the next
step.
Transition Requirements for STATUS
The decision to advance a document to Recommendation is a
W3C Decision.
The Working
GroupW3C:
- must record the group’sindividual(s) decision to request advancement.
Provide a link to meeting minutes, github issues, or email announcing the decision.
For a Recommendation, you may reuse the group's decision to move to
Proposed Recommendation.
- must obtain Team
verification.
Submit a transition request.
- must publicly
document all new features
(class 4 changes) to the
technical report
since the previous publication.
Include a link to a change log where new features are highlighted, highlight them in the
Status of the Document.
- must not contain new features
(class 4 changes) to the
technical report
since the Recommendation.
- must publicly document if other substantive changes
(class 3 changes) have been made,
and should document the details of such changes.
- For example, include a link to a change log where important changes are highlighted.
- 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 obsolete or supersede a 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?
- should publicly document if editorial
changes have been made,
and may document the details of such changes.
- must formally address all issues
raised about the document since the previous maturity level.
- Include a link to an issues list, such as GitHub issues, that indicates that the group has been
responsive to reviewers who have raised issues since the previous transition. The Team's
expectations are that, as a document advances, there will be 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.
- should formally
address all errata
raised about the document since the Recommendation.
Include a link to an issues list, such as GitHub issues, that indicates that errata have been
responded.
- must provide public documentation of any Formal Objections.
Provide link(s) to the objection, attempts to satisfy the reviewer, and a public record of the decision.
- should report which, if any, of the Working Group'sindividual(s) requirements
for this document have changed since the previous step.
- should report any changes in
dependencies with other groups.
- In general, documents do not advance to Proposed Recommendation with normative references to other
specifications that are considered unstable. See also Normative References Guidelines.
- Documents must not include normative references to a Rescinded/Obsolete/Superseded Recommendation.
- should
provide information about implementations known to the Working Groupindividual(s).
- must provide information about
implementations known to the individual(s).
See implementation experience
- must provide information about implementations known to the
Working Groupindividual(s).
- Unless this information changed since the previous
transition, indicate "No change".
- Include a link to a final implementation report, or, if there is
no such report, rationale why the Team should approve the request nonetheless.
- If you use WPT results, provide a snapshot of those results, e.g wpt.fyi
snapshot of webauthn (save a copy of the resulting report)
Requirements for revising a STATUS
A Working Group should publish a Working Draft to the W3C Technical Reports page
when there have been significant changes
to the previous published document
that would benefit from review beyond the Working Group.
If 6 months elapse without significant changes to a specification,
a Working Group should publish a revised Working Draft,
whose status section should indicate reasons for the lack of change.
To publish a revision of a Working draft, a Working Group:
- must record the group’s decision to request publication. Consensus is
not required,
as this is a procedural step,
Provide a link to meeting minutes, github issues, or email announcing the decision. The decision may be
applicable to one or more revisions.
This link should be given to the W3C automatic system
using the decision
parameter.
- must provide public documentation
of substantive changes to the technical report
since the previous Working Draft,
- should provide public documentation
of significant editorial changes to the technical report
since the previous step,
- should report which,
if any,
of the Working Group’s requirements for this document
have changed since the previous step,
- should report any changes in dependencies with other groups,
Requirements for updating a STATUS
WARNING: If your existing Recommendation was not
approved for accepting new features,
you are not allowed to follow these steps. You MUST follow the First Public Working
Draft steps instead.
The decision to incorporate proposed amendments in a Recommendation is a
W3C Decision.
The Working Group:
The W3C:
- must obtain Team
verification,
or fulfill the criteria for Streamlined Publication Approval.
Submit an update request.
- must record the group’s decision to request the update.
Provide a link to meeting minutes, github issues, or email announcing the decision.
- must show that the changes
proposed amendments have received wide
review.
- Was the public requested to review the changes (such as announcement from a previous publication)?
- Which are the groups with dependencies, per the Group's charter, and did they review the document?
- Were the horizontal groups given proper opportunities to review subtantive changes? Are there any
*-needs-resolution
issue pending?
- Was there early review from implementers? Are the changes already deployed in implementations?
-
Streamlined Publication Approval requires, for each of the W3C Horizontal Groups,
if the Horizontal Review Group has made available a set criteria under which their review is not
necessary,
the Working Group must document that these criteria have been fulfilled.
Otherwise, the Working Group must show that review from that group has been
solicited and received.
Proposed amendments can only be incorporated as-is, per section 6.3.11.5.
-
Streamlined Publication Approval requires the group to formally address:
-
all issues raised against the document that resulted in changes since the previous publication
-
all issues raised against changes since the previous publication
-
all issues raised against the document that were closed since the previous publication with no change
to the document
The response to each of these issues must be to the satisfaction
of the person who raised it:
their proposal has been accepted,
or a compromise has been found,
or they accepted the Working Group’s rationale for rejecting it. This implies no pending *-needs-resolution
issues,
and no pending PAG conclusions.
- must provide public documentation of any Formal
Objections.
- Provide link(s) to the objection, attempts to satisfy the reviewer, and a public record of the
decision.
-
Streamlined Publication Approval requires no formal objection have been registered.
- must publicly document of all new
features
(class 4 changes) to the technical
report
since the previous publication.
Include a link to a change log where new features are highlighted, highlight them in the
Status of the Document.
- must publicly document if other substantive changes
(class 3 changes) have been made,
and should document the details of such changes.
For example, include a link to a change log where important changes are highlighted.
For Recommendations, other substantive changes
must not happen, unless it was a proposed amendment.
- should publicly document if editorial
changes changes have been made,
and may document the details of such changes.
- must show that the revised specification
meets all Working Group requirements,
or explain why the requirements have changed or been deferred,
- Where are the requirements defined (e.g,. a charter or requirements document)?
- Are any requirements previously satisfied no longer satisfied? Are any requirements previously
unsatisfied now satisfied?
-
Streamlined Publication Approval requires no changes to Working Group requirements.
- should report which, if any, of the Working Group's
requirements
for this document have changed since the previous step.
-
Streamlined Publication Approval requires no changes to Working Group requirements.
- should report any changes in dependencies with other groups.
- should provide information about implementations known to the Working Group.
- must show that the specification
has met all Working
Groupindividual(s)
requirements,
or explain why the requirements have changed or been deferred,
- Where are the requirements defined (e.g,. a charter or requirements document)?
- Are any requirements previously satisfied no longer satisfied? Are any requirements previously
unsatisfied now satisfied?
- must document changes to dependencies during the development of the specification,
- Does this specification have any normative references to other
specifications that are not yet stable?
The Team's expectations are that, as a document advances, there will be an increasingly need
for normative referenced materials to be scrutinized. See Normative References Guidelines.
- Does this specification have any normative references to a Rescinded/Obsolete/Superseded
Recommendation? Documents must not include normative references to a
Rescinded/Obsolete/Superseded Recommendation.
- 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?
- must document
how adequate implementation experience will be demonstrated,
This is also known as "CR exit criteria".
- Are there tests or test suites available that will allow the WG to demonstrate/evaluate that features
have been implemented (e.g., a matrix showing how different pieces or classes of software implement
different features)? 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 Team
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.
- 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?)?
- may identify features in the document as at risk.
These features may be removed
before advancement to Proposed Recommendation without a requirement to publish a new Candidate
Recommendation.
If any, the list of features at-risk must appear in the
Status of the Document.
- must specify the deadline for comments,
which must be at least 28 days after publication,
and should be longer for complex documents, and,
This deadline must appear in the Status of the Document.
- must show that the specification has received wide
review.
- Make sure to look at How to do Wide
Review
- Was the public requested to review the document (such as announcement from a previous publication)?
- Which are the groups with dependencies, per the Group's charter, and did they review the document?
- Were the horizontal groups given proper opportunities to review subtantive changes? Are there any
*-needs-resolution
issue pending? How recently were the reviews done?
- Was there early review from implementers? Are the changes already deployed in implementations?
- must specify the deadline for further comments,
which must be at least 28 days after publication,
and should be longer for complex documents,
This deadline must appear in the Status of the Document.
- may identify features in the document as at risk.
These features may be removed
before advancement to Proposed Recommendation without a requirement to publish a new Candidate
Recommendation.
The list of features at-risk must appear in the Status of the
Document, if any.
Requirements for publishing a STATUS
A Working Group should publish an Update Draft to the W3C
Technical Reports page
when there have been significant changes
to the previous published document
that would benefit from review beyond the Working Group.
The Working Group:
Updating a STATUS with editorial changes
The Working Group:
- must record the group’s decision to request publication,
Provide a link to meeting minutes, github issues, or email announcing the decision. The decision may be
applicable to one or more revisions.
This link should be given to the W3C automatic system
using the decision
parameter.
If there is no Working Group, the Maintainer Contact should provide the rational/record
for requesting the publication.
Updating a STATUS with candidate changes
WARNING: If your existing Recommendation was
not approved for accepting new
features, you are not allowed to follow these steps. You MUST follow the First
Public Working Draft steps instead.
The Working Group:
- must record the group’s decision to request publication,
Provide a link to meeting minutes, github issues, or email announcing the decision. The decision may be
applicable to one or more revisions.
This link should be given to the W3C automatic system
using the decision
parameter.
- must identify the specific candidate changes under review as
proposed changes, and
Your document contain proper marks/annotations to identify the specific candidate changes, or is providing a
list of those candidate changes.
- must not make substantive changes since the previous Recommendation.
Your document can only propose candidate changes but cannot apply
those to the normative content at this time. The W3C Team will ensure
no substantive changes.
- must specify the deadline for comments,
which must not be any sooner than 60 days
after the publication of the Recommendation, and should be at least 10 days
after the end of the Exclusion
Opportunity started by the publication of the Recommendation.
The publication requirements
will ensure about this. No need to indicate anything beyond providing the Status of the Document.
- must only incorporate as is candidate changes proposed in the most
recent Recommendation,
- If incorporation of a candidate change is postponed, it may need to be proposed again in subsequent
Recommendation updates.
- If incorporation of a candidate change is rejected as is, the revised candidate change must be proposed
again in subsequent Recommendation updates before being incorporated.
- must identify where errata are tracked,
Errata are tracked through GitHub nowadays. The link to your errata page must appear in the document heading. This will be checked by our publication rules.
- must not include any substantive changes from the Proposed Recommendation on which it is based.
Include, for example, a link to a change log where most important changes are highlighted.
Otherwise, the Working Group must republish the document at an earlier status.
- If there was any dissent in Advisory
Committee reviews,
the Team must publish the substantive content of the dissent
to W3C and the general public,
and must formally address the comment
at least 14 days before publication as a W3C
Recommendation.
- Typically, the Team consults with the group. 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 Team a request to advance to Recommendation. The request to advance to
Recommendation should document the success or failure of these negotiations.
- Provide link(s) to the Advisory Committee reviews, issues where the dissent was made public, and where
the comment was addressed.
Requirements for requesting a STATUS
The request:
The Team must then submit the request to the Advisory Committee for review.
Transition requirements to STATUS
The W3C:
- must obtain Team
verification.
Submit a transition request.
- must formally
address all issues
raised about the document since the previous maturity level.
- Include a link to an issues list, such as GitHub issues, that indicates that the group has been
responsive to reviewers who have raised issues since the previous transition. The Team's expectations
are that, as a document advances, there will be 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.
- must provide public documentation of any Formal Objections.
Provide link(s) to the objection, attempts to satisfy the reviewer, and a public record of the decision.
- If there was any dissent in Advisory
Committee reviews,
the Team must publish the substantive content of the dissent
to W3C and the general public,
and must formally address the comment
at least 14 days before publication as a W3C
Recommendation.
- Typically, the Team consults with the group. 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 Team a request to advance to Recommendation. The request to advance to Recommendation
should document the success or failure of these negotiations.
- Provide link(s) to the Advisory Committee reviews, issues where the dissent was made public, and where the
comment was addressed.
Transition requestUpdate Request
Tip: When updating an existing Candidate Recommendation, focus your new request on what
changed since the previous Candidate Recommendation transition. There is no need to repeat information included
in the previous transition.
Transition
Meeting with the Team
For an STATUS transition,
the CEO, or its delegates, may request a transition
meeting attended by:
- The Team contact(s)
- The Maintainer Contact
- The Project Management Lead (or someone appointed by him), who generally
chairs the meeting.
- Those delegated by the Team to approve the transition.
- The Team 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)individual(s)
- Others invited by the Project Management Lead (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 Project Management Lead):
- Scheduling the meeting. To allow chairs of WGs with
dependencies and other commenters time to review the treatment of
review 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 Team's attention.
- Review of the horizontal tracker boards
- Ensure that all horizontal
*-needs-resolution
issues are closed
by the relevant horizontal review group.
- Decision
- The Team 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 Team 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 Team is not satisfied after its verification with how the Working Group fulfilled
the requirements for advancement.
-
The Working Group has issued a transition request despite a
Formal Objection and the Council is not
satisfied with
the Working Group's rationale.
-
The Team is not satisfied with how the individual(s) has
addressed issues.
-
There are horizontal
*-needs-resolution
issues open in one or more
of the horizontal tracker boards.
Per section 6.3.13.4, in some conditions, the
Team is required
to accept the transition request.
Per section 6.3.3 of the Process, "The
Team
MUST inform the
Advisory Committee and Working Group Chairs when a Working Group's
request for a specification to advance in maturity stage is declined
and the specification is returned to a Working Group for further
work."
Tip: STATUSs published through the W3C automatic system do not need to get scheduled with the
Webmaster and are not subjected to publishing moratoria.
7 days for transition: Unless there are exceptional
circumstances, the Team requires a minimum of 7 days period between the transition request and the publication.
This allows other Groups or outside individuals to review the transition request and may formally object within this period.
While the Team strives to address transitions within this 7 days period, delays due to transition issues or
competing Team's priorities are not unheard of and may increase the length of the period needed. Group
participants are expected to raise objections within the Group prior to the transition request.
The Webmaster publishes on Tuesdays and Thursdays (cf. the
announcement to chairs).
Please send advance notice to webreq@w3.org:
- 3 business days in advance: If you need help from the Webmaster to fix errors, or ask for
Pubrules error exception.
- 2 business days in advance: If the document is perfectly ready.
Publication Request
Note:
Someone from the W3C
management team (usually the Project Management Lead) SHOULD be aware of the status
of the
document.
A publication request MUST include the following information:
⟶ You may copy the list below and paste into the email sent
to webreq@w3.org
- Information:
- Document Title: xxx xxx
- Document URL: https://www.w3.org/TR/yyyy/XX-xxx-yyyymmdd/
- *Publication Date: (if document not installed) Month Date Year
-
*Description: Used in TR/xx/all page (only needed if differ
from the 'Abstract' of the document)
-
Family: Used in the new TR Page to categorize specifications,
configured in GitHub w3c/spec-families repo.
-
*Description Update: Used in TR/xx/all page (only needed if
differ from the 'Abstract' of the document)
-
Document tags: (see the list of tags here)
-
*Document tags update: (see the list of tags
here)
- *Retired: (only needed when 'yes')
⟶ Indicate if the publication is the result of stopping work on a specification
(aka "retired").
- *Requirements for shortlinks redirection: (may apply if there are multi levels)
- Approvals:
- Record of
approval of the transition request.
- Record of approval of the
update request.
- Record of W3M
decision to close the group.
- Team's approval state:
(approved / not yet / not needed)
- Evidence that
publication is in accordance with expectations set by the group charter (e.g., quote the charter).
- Record of
approval of the Group.
- *Skip CfE for CR text
delete: (only needed when 'yes')
⟶ If there has been a previous Candidate Recommendation, whether the only change is
that text has been deleted; If so, W3C can skip the Patent Policy Exclusion (see the Patent Policy FAQ).
- Checks:
- Pass Pubrules' check: (yes / need Team's exception)
⟶ Check the document using Pubrules
UI.
⟶ How to deal with Pubrules' result:
- error: should not contain any `error`, unless it's an
exception approved by the Team. This could likely block publication
- warning: Please read through each warning and try to reduce the number of them.
- *Comment on Pubrules: (describe the help you need if there's any error)
- Pass Link Checker's check: (yes)
⟶ Check the document using W3C
Link Checker.
⟶ How to deal with result of Link Checker:
- 404 Not Found: should not contain any `404` link.
This could likely block publication.
- 403 Forbidden: Please check manually.
- Broken Fragments: These kind of error could be false alarm, please check manually.
- Status: 301: Please consider using the new link.
It is perfectly appropriate to send a publication while waiting for a Team's approval but does run the risk
of not receiving
the Team's approval in time. Please coordinate with the Project Management Lead if needed.
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 7. 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.
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 minimum of the pubrules
requirements. 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 indicates clearly its new status verified by
the Webmaster. The updated version may remove the main body of the
document.
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
An
First Public
STATUS transition announcement MUST include the
following information:
- That this is a document returning to Working Draft announcement.
- Document title, URIs.
- Instructions for providing feedback.
- Explanation for the document returning to
Working Draft for further work.
- Document abstract and status.
The announcement SHOULD provide information about where people
can learn about issues raised during the Candidate or Proposed Recommendation review period
(e.g., a link to an issues list).
The announcement
MAY indicate priority feedback
items.
- That this is a
STATUS
transition announcement.
- Document title, URIs of the W3C Recommendation.
- Instructions for providing feedback.
- Review end date.
- Link to information about the review; this is the link
to an online review form (WBS) 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 obsoleting or superseding previous Recommendations, if applicable.
This avoids sending an additional WBS survey just for the purpose of obsoleting/superseding a
Recommendation.
- information about wide review
- 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 link to the group's transition request.
- Review end date.
- The names of groups with dependencies, explicitly inviting
review from them.
- Information about 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.
The Candidate Recommendation transition announcement SHOULD provide information
about where people
can learn about issues raised during the Candidate Recommendation review period
(e.g., a link to an issues list).
The Candidate Recommendation transition announcement
MAY indicate priority feedback
items.
- That this is an 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.
- Information about any Formal Objections.
- Any additional information for companion document(s).
Please use the Team-only
transition announcement template as a starting point.
Please use the Team-only
transition announcement template as a starting point.
- That this is a
First Public
STATUS
transition announcement.
- Document title, URIs.
- Instructions for providing feedback.
- A reference to the
group's transition request.
Call for Exclusions
The Patent Policy FAQ clarifies
when Call for Exclusions are sent
out.
The Team sends a Call for Exclusion to
participants. The exclusion opportunity lasts 150 days. At approximately 90 days, The Team sends out a
reminder with a pointer to the "Patent
Review Draft".
If the document was published within 90 days of the First Public
Working Draft, it becomes the new Patent
Review Draft
for the Call for Exclusions started at the time of the First Public Working Draft publication.
Exclusions are with respect to the set of features in this new STATUS.
A Working Group under the W3C Patent Policy publishes a STATUS.
The Team sends the second exclusion
opportunity.
The exclusion opportunity lasts 60 days. Any exclusions are with respect
to new features in the STATUS added since the exclusion
opportunity of the First Public Working Draft.
The Working Group changes the document substantially after STATUS and published a
new STATUS. The Team sends a new exclusion opportunity. It lasts 60
days. Exclusions are with respect to new features in the specification since the previous exclusion
opportunity, i.e., the previous LABEL.
The Working Group updates the document substantially since the Recommendation and published a
STATUS. The Team sends a exclusion opportunity. It lasts 60
days. Exclusions are with respect to new features in the specification since the previous exclusion
opportunity, i.e., the one applying to the previous Recommendation.
The Working Group proposes to update the document substantially since the Recommendation and published a
STATUS with proposed changes. The Team sends a exclusion opportunity. It lasts 60
days. Exclusions are with respect to the proposed changes identified in the
specification.
Feedback is to @w3c/transitions
and is welcome on GitHub