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
Publication of a
First Public
Ordinary
STATUS
If the document contains some substantiveonly editorial changes since the previous publication, NONE of steps below are applicable.
Once the Process Document requirements for the transition to
First Public
STATUS have been satisfied
(see
section 6.3.1
section 6.4
section 6.4.1
section 6.5
section 6.7.2
section 6.6
or section 6.9 for restoring a Recommendation
section 6.9
section 6.9),
W3C follows the steps described below to complete the transition.
Once the Group determined that the requirements of section 6.4.1 do NOT apply, the W3C follows the steps described below to update 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 the W3C XPointer Scheme
Registry.
- Negotiation of Review Schedule
-
-
The Chair negotiates the Candidate Recommendation review
schedule with the Chairs of groups with dependencies (on chairs@w3.org).
Securing review commitments before going to
Candidate Recommendation will help ensure that your document receives
wide review. The suggested way to negotiate a 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 review
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.
- If an individual made a request to the relevant Working Group, or the TAG if such a group does not exist, to obsoleterescind 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 Director, the
The
Chair (or Team Contact)Team Contact
sends a transition request to
plh@w3.org (as Project Management Lead), cc'ing w3t-comm@w3.org and chairs@w3.org.
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, cc'ing plh@w3.org,
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 MAY need to organize a transition meeting
with the Director to discuss the request.
Note: When the transition request indicates
unambiguous support and sufficient wide review for the transition, the Director waives the need for a telephone
call in general.
Note: When Advisory Committee review indicates
unambiguous support, the Director waives the need for a telephone
call in general.
-
The Project Management Lead approve the transition request.
The Project Management Lead MAY ask 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.
Note: Director approval is required for
some namespace URIs; see URIs
for W3C Namespaces for details.
-
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 6.1.1 of the Process) that explains why the document was
returned for further work.
-
- 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 6.1.1 of the Process) that explains why the document was
returned for further work.
- Form and Mailing List Preparation
- Mailing List Preparation
- GitHub Preparation
-
-
The Team Contact ensures that there is a public archived place (github or mailing list)
available for comments; (for mailing list, 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 ensures that there is a public archived github repository
available for comments.
-
The Team Contact builds a
STATUS
review
form that the Project Manager 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.
- 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.
-
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 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.
-
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 Working Draft
Candidate Recommendation the W3C Communications Team issues a Call for Exclusions in accordance with the
W3C Patent Policy. See also the 2017 Process Transition FAQ.
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.
Please take note of the W3C Process Document limitations regarding when to publish an updated STATUS without Director's approval:
Please take note of the W3C Process Document provisions regarding when to publish an update to a STATUS without Director's approval:
- The previous publication must be a Candidate Recommendation.
- The Group must not make substantive changes to the document since its previous publication.
- The Group should update the deadline for further comments.
Please take note of the W3C Process Document provisions regarding when to publish an update to a STATUS with Director's approval:
- The previous publication must be a Candidate Recommendation.
- The Group should update the deadline for further comments.
- The Group should
publish a Working Draft to the W3C Technical Reports page when there have been significant changes to the document that would benefit from review beyond the Working Group.
- The Group may request publication of a Working Draft even if its content is considered unstable and does not meet all Working Group requirements.
Here are the W3C Process Document transition requirements for a STATUS:
- The Group must record the group's decision to request publication.
- The Group must provide public documentation of substantive changes to the technical report since the previous Working Draft.
- The Group should document outstanding issues, and parts of the document on which the Working Group does not have consensus.
- The Group should provide public documentation of significant editorial changes to the technical report since the previous step.
- The Group should report which, if any, of the Working Group's requirements for this document have changed since the previous step.
- The Group should report any changes in dependencies with other groups.
- The Group should provide information about implementations known to the Working Group.
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
Tip: When updating an existing Candidate Recommendation, focus your new transition on what changed since the previous Candidate Recommendation transition. There is no need to repeat information included in the previous transition.
The message subject line and body SHOULD identify this as a "transition request";
see above for where to send the request.
An
First Public
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 of the W3C Recommendation.
- The request must
include rationale for obsoletingrescinding 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
Project Management Lead
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
Project Management Lead'
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 Project Management 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: The Director SHOULD NOT schedule a Proposed Recommendation
review period to end
less than 10 days
after the end of an open "exclusion opportunity" as defined in the W3C Patent
Policy (per section 5.2 of the W3C Process), or
if there are any Patent Advisory Groups
(PAGs) currently discussing the document
(per the Patent Policy FAQ, question 29).
- The request
must
include a link to the previous Candidate Recommendation transition request.
- The request
must
should
record the group's decision (or the individual request or the support of the Advisory Committee)(or the individual request if no Working Group) to request advancement (e.g.,
a link to
meeting minutes or email announcing the group's decision).
- The group
must
provide public documentation of all substantive changes to the technical report since the previous publication or a statement that there is no substantive changes. Include, for example, a link to a change log
where important changes are highlighted.
If there have been substantive changes to the document since the
previous transition (except for the removal of feature at risk),
the Working Group must republish the document at an earlier status.
- The group
should
provide public documentation of changes that are not substantive.
- The group
should
provide public documentation of editorial corrections.
- 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?
- The group should
address all recorded errata.
- The Group must
show that the specification has met 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)?
- The group should
report which, if any, of the Working Group's requirements for this document have changed since the previous step. Are any requirements previously satisfied no longer satisfied? Are any requirements previously unsatisfied now satisfied?
- The group should
report any changes in dependencies with other groups.
- The group must
document changes to dependencies during the development of the specification.
- Does this specification have any normative references to W3C
specifications that are not yet
Proposed Recommendations? See Normative References Guidelines.
Candidate Recommendations?
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?
- The group must
show that the specification has received wide review (unless section 6.6 is applicable)
- The group must
show that the changes to the document have received wide review (defined in
section 6.2.3.1 of the Process).
- The group may
identify features in the document as "at risk".
-
Which are the groups with dependencies? Did they review the document?
-
The group must
show that the request to rescind has received
wide review. If the Director is
proposing to rescind or obsolete the Recommendation, the Director
must show that the request to rescind or obsolete is based on public comment.
-
The group must
show that the request to obsolete has received
wide review. If the Director is
proposing to obsolete the Recommendation, the Director
must show that the request to obsolete is based on public comment.
- Was there review from implementers?
- Was there review from
Advisory Committee representatives?
- The group must
formally address all issues raised about the document since the previous maturity level.
-
The group must
show that all issues raised during the Candidate Recommendation review period other than by Advisory Committee representatives acting in their formal AC representative role have been formally addressed.
-
The group must
identify any substantive issues raised since the close of the Candidate Recommendation review period by parties other than Advisory Committee representatives acting in their formal AC representative role.
- 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 review period.
Typically the Director consults with the group.
Per the
Process Document, section 6.2.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.
Formal Objections
- The group
must
provide public documentation of any Formal Objections. For each Objection, is there a public record of the decision, the objection, and attempts to satisfy the reviewer?
-
The group must
document how adequate implementation experience will be demonstrated.
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?
-
The group must
show adequate implementation experience except where an exception is approved by the Director.
Were the expectations set at Candidate Recommendation met?
- 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 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.
- 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?)?
- The group should
provide information about implementations known to the Working Group.
See the definition
of implementation experience in section 6.2.4 of the Process.
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? The Director SHOULD NOT schedule a Proposed Recommendation
review period to end
less than 10 days
after the end of an open "exclusion opportunity" as defined in the W3C Patent
Policy (per section 5.2.1 of the W3C Process), or
if there are any Patent Advisory Groups
(PAGs) currently discussing the document
(per the Patent Policy FAQ, question 29).
- If the group is not using IPP: Does the disclosure page conform to the patent policy
requirements?
For an STATUS transition,
the Director may need to attend a transition
meeting attended by:
- The Team contact(s)
- The Project Management Lead (or someone appointed by him), 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 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 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
-
There have been substantive changes since the
previous transition. In this case, the document is returned to a lower maturity level.
-
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.
Per section 6.9, in some conditions, the Director is required
to accept the transition request.
Per section 6.1.1 of the Process, "The Director
MUST inform the
Advisory Committee and Working Group Chairs when a Working Group's
request for a specification to advance in maturity level is declined
and the specification is returned to a Working Group for further
work."
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. If there is no change in the description since the previous publication, this can be ommitted.
- A proposed publication schedule.
-
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).
-
Since there has been a previous Candidate Recommendation and the changes are only editorial, W3C can skip the Patent Policy Exclusion (see the Patent Policy FAQ). If not, a proper transition request with the approval of the Director will be needed.
- 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 Project Management Lead) SHOULD be aware of the status of the
document.
Note: STATUSs published through the W3C automatic system do not need to get scheduled with the Webmaster and are not subjected to publishing moratoria.
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.
The Webmaster publishes on Tuesdays and Thursdays (cf. the
announcement to chairs). 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
An
First Public
STATUS transition announcement MUST include the following information:
- 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 wide review
Note: if you created the review form (WBS) at Candidate Recommmendation phase, update the review form as needed, making it clear what the updates are, and update the closing date for the 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.
- 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 wide review
- 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. Please note that as of Candidate Recommendation, no technical issues should
be open, even though the Working Group may request feedback on
particular choices they have made.
- 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.
- 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.