--- a/cover.html Wed Jan 21 01:38:29 2015 +0100
+++ b/cover.html Wed Jan 21 16:43:05 2015 +0100
@@ -3,7 +3,9 @@
use</a> and <a rel="Copyright" href="/Consortium/Legal/copyright-software">software
licensing</a> rules apply. Your interactions with this site are in
accordance with our <a href="/Consortium/Legal/privacy-statement#Public">public</a>
and <a href="/Consortium/Legal/privacy-statement#Members">Member</a>
privacy statements.</p>
<hr></div>
<h2 class="notoc"><a id="abstract">Abstract</a></h2>
<p>The mission of the World Wide Web Consortium (<abbr>W3C</abbr>) is to
lead the World Wide Web to its full potential by developing common
protocols that promote its evolution and ensure its interoperability. The
W3C Process Document describes the organizational structure of the W3C and
the processes related to the responsibilities and functions they exercise
to enable W3C to accomplish its mission. This document does not describe
the internal workings of the Team or W3C's public communication
mechanisms.</p>
<p>For more information about the W3C mission and the history of W3C, please
refer to <a href="http://www.w3.org/Consortium/">About W3C</a> [<a href="#ref-mission">PUB15</a>].</p>
<h2 class="notoc" id="status">Status of this Document</h2>
<p>W3C, including all existing chartered groups, follows the <a href="http://www.w3.org/Consortium/Process/">most
recent operative Process Document</a> announced to the Membership.</p>
<p>This is the 21 January 2015 Editor's draft for the proposed next version
of the W3C Process Document. This document is based on the 30 September
review draft, itself based on the 1 August 2014 Process, developed between
the <a href="/2002/ab/">W3C Advisory Board</a> and the <a href="http://www.w3.org/community/w3process/">Revising
- W3C Process Community Group</a> and adopted as the currently operative
Process. </p>
<p>In <em>this draft</em> changes have been made to sections <a href="#wide-review">7.2.3.1
Wide Review</a> and <a href="#errata">7.7.1 Errata Management</a>. A <a
href="#changes">change
history</a> (compared to the 2014 Process Document) forms part of the
draft.</p>
<p>The document will continue to be developed in preparation for adopting a
revised process in 2015. A further revision is anticipated, to be adopted
in 2016.</p>
<p>Comment is invited on the draft. Please send comments about this document
to the <a href="http://www.w3.org/community/w3process/">Revising W3C
Process Community Group</a> (<a href="http://lists.w3.org/Archives/Public/public-w3process/">Mailing
+ W3C Process Community Group</a> and adopted as the currently operative
Process. </p>
<p>In <em>this draft</em> changes have been made to sections <a href="#wide-review">7.2.3.1
+ Wide Review</a> and <a href="#errata">7.7.1 Errata Management</a>. A <a
href="#changes">change
+ history</a> (compared to the 2014 Process Document) forms part of the
draft.</p>
<p>The document will continue to be developed in preparation for adopting a
revised process in 2015. A further revision is anticipated, to be adopted
in 2016.</p>
<p>Comment is invited on the draft. Please send comments about this document
to the <a href="http://www.w3.org/community/w3process/">Revising W3C
Process Community Group</a> (<a href="http://lists.w3.org/Archives/Public/public-w3process/">Mailing
list archive</a>, publicly available) or to process-issues@w3.org (<a href="http://lists.w3.org/Archives/Member/process-issues">Member-only
archive</a>). A <a href="https://www.w3.org/community/w3process/track/">Public
Issue Tracker</a> and <a href="https://dvcs.w3.org/hg/AB/">detailed
changelogs</a> are available online. </p>
<h2 class="notoc" id="pp">Relation of Process Document to Patent Policy</h2>
<p>W3C Members' attention is called to the fact that provisions of the
Process Document are binding on Members per the <a href="http://www.w3.org/Consortium/Agreement/Member-Agreement">Membership
@@ -124,18 +126,18 @@
WD</text></a>
<path d="M66,40h33"></path>
<polygon points="98,36 108,40 98,44"></polygon> </g>
<g id="nodeWD">
<ellipse ry="18" rx="38" cy="40" cx="147" stroke="black" fill="none"></ellipse>
<a xlink:href="#RecsWD"><text font-size="14" font-family="Times,serif"
y="44"
x="147"
text-anchor="middle">WD</text></a>
</g>
<g id="repeatWD" stroke="black">
<path d="M128,24C123,14 129,4 147,4 158,4 165,8 167,14" fill="none"
stroke-dasharray="6 1"></path>
<polygon points="170,14 166,24 164,13"></polygon> </g>
<g class="edge" id="toCR" stroke="black" fill="black">
<path d="M185,40h31"></path>
<polygon points="211,36 221,40 211,44"></polygon> </g>
<g id="nodeCR">
<ellipse ry="18" rx="38" cy="40" cx="260" stroke="black" fill="none"></ellipse>
<a xlink:href="#RecsCR"><text font-size="14" font-family="Times,serif"
y="44"
x="260"
text-anchor="middle">CR</text></a>
</g>
<g class="edge" id="repeatCR" stroke="black" fill="black">
<path d="M242,24C238,14 244,4 260,4 271,4 277,8 279,14" stroke-dasharray="5 3"
fill="none"></path>
<polygon points="282,14 277,24 275,13"></polygon> </g>
<g id="backToWD" stroke="#666" fill="#666">
<path d="M190,47h34" stroke-dasharray="4 4"></path>
<polygon points="190,45 183,47 190,49"></polygon> </g>
<g class="edge" id="ToPR" stroke="black" fill="black">
<path d="M298,40h27"></path>
<polygon points="324,36 334,40 324,44"></polygon> </g>
<g id="nodePR">
<ellipse ry="18" rx="28" cy="40" cx="363" stroke="black" fill="none"></ellipse>
<a xlink:href="#RecsPR"><text font-size="14" font-family="Times,serif"
y="44"
x="363"
text-anchor="middle">PR</text></a>
</g>
<g id="BackToCR" stroke="#aaa" fill="#aaa">
<path d="M301,47h38" stroke-dasharray="2 5"></path>
<polygon points="301,45 296,47 301,49"></polygon> </g>
<g id="ToRec" stroke="black" fill="black">
<path d="M391,40h20"></path>
<polygon points="404,36 414,40 404,44"></polygon> </g>
<g id="nodeRec">
<ellipse ry="18" rx="28" cy="40" cx="443" stroke="black" fill="none"></ellipse>
<a xlink:href="#RecsW3C"><text font-size="14" font-family="Times,serif"
y="44"
x="443"
text-anchor="middle">REC</text></a>
</g> </svg> </p>
<p>W3C <em class="rfc2119">may</em> <a href="#tr-end">end work on a
technical report</a> at any time.</p>
<p>The Director <em class="rfc2119">may</em> decline a request to advance
in maturity level, requiring a Working Group to conduct further work,
and <em class="rfc2119">may</em> require the specification to return to
a lower <a href="#maturity-levels">maturity level</a>. The Director <em
class="rfc2119">must</em>
inform the <a href="#AC">Advisory Committee</a> 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.</p>
<h4 id="maturity-levels">7.1.2 Maturity Levels</h4>
<dl>
<dt id="RecsWD">Working Draft (WD)</dt>
<dd>A Working Draft is a document that W3C has published for review by
the community, including W3C Members, the public, and other technical
organizations. Some, but not all, Working Drafts are meant to advance
to Recommendation; see the <a href="#DocumentStatus">document status
section</a> of a Working Draft for the group's expectations. Any
Working Draft not, or no longer, intended to advance to Recommendation
<em class="rfc2119">should</em> be published as a Working Group Note.
Working Drafts do not necessarily represent a consensus of the Working
Group, and do not imply any endorsement by W3C or its members beyond
agreement to work on a general area of technology.</dd>
<dt id="RecsCR">Candidate Recommendation (CR)</dt>
<dd class="changed">A Candidate Recommendation is a document that
satisfies the Working Group's technical requirements, and has already
received wide review. W3C publishes a Candidate Recommendation to
<ul>
<li>signal to the wider community that a final review should be done</li>
<li>gather <a href="#implementation-experience">implementation
experience</a></li>
<li>begin formal review by the Advisory Committee, who <em class="rfc2119">may</em>
recommend that the document be published as a W3C Recommendation,
returned to the Working Group for further work, or abandoned.</li>
<li>Provide an exclusion opportunity as per the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C
Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>]. A
Candidate Recommendation under this process corresponds to the
"Last Call Working Draft" discussed in the Patent Policy.</li>
</ul>
</dd>
<dd><strong>Note:</strong> Candidate Recommendations are expected to be
acceptable as Recommendations. Announcement of a different next step <em
class="rfc2119">should</em>
include the reasons why the change in expectations comes at so late a
stage.</dd>
<dt id="RecsPR">Proposed Recommendation</dt>
<dd>A Proposed Recommendation is a document that has been accepted by
the W3C Director as of sufficient quality to become a W3C
Recommendation. This phase establishes a deadline for the Advisory
Committee review which begins with Candidate Recommendation.
Substantive changes <span class="rfc2119">must</span> not be made to
a Proposed Recommendation except by publishing a new Working Draft or
Candidate Recommendation.</dd>
<dt id="RecsW3C">W3C Recommendation (REC)</dt>
<dd>A W3C Recommendation is a specification or set of guidelines or
requirements that, after extensive consensus-building, has received
the endorsement of W3C Members and the Director. W3C recommends the
wide deployment of its Recommendations as standards for the Web. The
W3C Royalty-Free IPR licenses granted under the Patent Policy apply to
W3C Recommendations.</dd>
<dt id="WGNote">Working Group Note, Interest Group Note (NOTE) </dt>
<dd>A Working Group Note or Interest Group Note is published by a
chartered Working Group or Interest Group to provide a stable
reference for a useful document that is not intended to be a formal
standard, or to document work that was abandoned without producing a
Recommendation.</dd>
<dt id="RescindedRec">Rescinded Recommendation</dt>
<dd>A Rescinded Recommendation is an entire Recommendation that W3C no
longer endorses. See also clause 10 of the licensing requirements for
W3C Recommendations in <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Requirements">section
5</a> of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C
- Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</dd>
</dl>
<p>Working Groups and Interest Groups <em class="rfc2119">may</em> make
available "Editor's drafts". Editor's drafts have no official standing
whatsoever, and do not necessarily imply consensus of a Working Group or
Interest Group, nor are their contents endorsed in any way by W3C.</p>
<h3 id="requirements-and-definitions">7.2 General requirements and
definitions</h3>
<p>Please note that <dfn>publishing</dfn> as used in this document refers
to producing a version which is listed as a W3C Technical Report on its
<a href="http://www.w3.org/TR/">Technical Reports page
http://www.w3.org/TR</a>.</p>
<h4 id="general-requirements">7.2.1 General requirements for Technical
Reports</h4>
<p>Every document published as part of the technical report development
process <em class="rfc2119 old">must</em> be a public document. The <a
href="http://www.w3.org/TR/">index
+ Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</dd>
</dl>
<p>Working Groups and Interest Groups <em class="rfc2119">may</em> make
available "Editor's drafts". Editor's drafts have no official standing
whatsoever, and do not necessarily imply consensus of a Working Group or
Interest Group, nor are their contents endorsed in any way by W3C.</p>
<h3 id="requirements-and-definitions">7.2 General requirements and
definitions</h3>
<p>Please note that <dfn>publishing</dfn> as used in this document refers
to producing a version which is listed as a W3C Technical Report on its
<a href="http://www.w3.org/TR/">Technical Reports page
http://www.w3.org/TR</a> [<a href="#rdf-doc-list">PUB11</a>].</p>
<h4 id="general-requirements">7.2.1 General requirements for Technical
Reports</h4>
<p>Every document published as part of the technical report development
process <em class="rfc2119 old">must</em> be a public document. The <a
href="http://www.w3.org/TR/">index
of W3C technical reports</a> [<a href="#ref-doc-list">PUB11</a>] is
available at the W3C Web site. W3C strives to make archival documents
indefinitely available at their original address in their original form.</p>
<p>Every document published as part of the technical report development
process <em class="rfc2119 old">must</em> clearly indicate its <a href="#maturity-levels">maturity
level</a>, and <em id="DocumentStatus" class="rfc2119">must</em>
include information about the status of the document. This status
information</p>
<ul>
<li><em class="rfc2119">must</em> be unique each time a specification is
published,</li>
<li><em class="rfc2119">must</em> state which Working Group developed
the specification, </li>
<li><em class="rfc2119">must</em> state how to send comments or file
bugs, and where these are recorded, </li>
<li><em class="rfc2119">must</em> include expectations about next steps,</li>
<li><em class="rfc2119">should</em> explain how the technology relates
to existing international standards and related work inside or outside
W3C, and</li>
<li><em class="rfc2119">should</em> explain or link to an explanation of
significant changes from the previous version.</li>
</ul>
<p>Every Technical Report published as part of the Technical Report
development process is edited by one or more editors appointed by a
Group Chair. It is the responsibility of these editors to ensure that
the decisions of the Group are correctly reflected in subsequent drafts
of the technical report. An editor <em class="rfc2119">must</em> be a
participant, as a Member representative, Team representative, or Invited
Expert in the Group responsible for the document(s) they are editing. </p>
<p>The Team is <em class="rfc2119">not required</em> to publish a
Technical Report that does not conform to the Team's <a href="http://www.w3.org/Guide/pubrules">Publication
- Rules</a> (e.g., for <span id="DocumentName">naming</span>, status
information, style, and <span id="document-copyright">copyright
requirements</span>). These rules are subject to change by the Team
from time to time. The Team <em class="rfc2119">must</em> inform group
Chairs and the Advisory Committee of any changes to these rules.</p>
<p>The primary language for W3C Technical Reports is English. W3C
encourages the translation of its Technical Reports. <a href="http://www.w3.org/Consortium/Translation/">Information
+ Rules</a> [<a href="#rdf-pubrules">PUB31</a>](e.g., for <span id="DocumentName">naming</span>,
status information, style, and <span id="document-copyright">copyright
requirements</span>). These rules are subject to change by the Team
from time to time. The Team <em class="rfc2119">must</em> inform group
Chairs and the Advisory Committee of any changes to these rules.</p>
<p>The primary language for W3C Technical Reports is English. W3C
encourages the translation of its Technical Reports. <a href="http://www.w3.org/Consortium/Translation/">Information
about translations of W3C technical reports</a> [<a href="#ref-translations">PUB18</a>]
is available at the W3C Web site.</p>
<h4 id="transition-reqs">7.2.2 Advancement on the Recommendation Track</h4>
<p>For <em>all</em> requests to advance a specification to a new maturity
level other than Note the Working Group:</p>
<ul>
<li><em class="rfc2119">must</em> record the group's decision to request
advancement.</li>
<li><em class="rfc2119">must </em> obtain Director approval.</li>
<li><em class="rfc2119 ">must</em> provide public documentation of all <a
href="#substantive-change">substantive
changes</a> to the technical report since the previous publication.</li>
<li><em class="rfc2119">must</em> <a href="#formal-address">formally
address</a> all issues raised about the document since the previous
maturity level.</li>
<li><em class="rfc2119">must</em> provide public documentation of any <a
href="#FormalObjection">Formal
Objections</a>.</li>
<li><span class="rfc2119">should</span> provide public documentation of
changes that are not substantive.</li>
<li><em class="rfc2119">should</em> report which, if any, of the Working
Group's requirements for this document have changed since the previous
step.</li>
<li><em class="rfc2119">should</em> report any changes in dependencies
with other groups.</li>
<li><em class="rfc2119">should</em> provide information about
implementations known to the Working Group.</li>
</ul>
<p>For a First Public Working Draft there is no "previous maturity level",
so many requirements do not apply, and approval is normally fairly
automatic. For later stages, especially transition to Candidate or
Proposed Recommendation, there is generally a formal review meeting to
ensure the requirements have been met before Director's approval is
given.</p>
<h4 id="doc-reviews">7.2.3 Reviews and Review Responsibilities</h4>
<p>A document is available for review from the moment it is first
published. Working Groups <em class="rfc2119">should</em> <a href="#formal-address">formally
address</a> <em>any</em> substantive review comment about a technical
report in a timely manner. </p>
Reviewers <em class="rfc2119">should</em> send substantive technical
reviews as early as possible. Working Groups are often reluctant to make <a
href="#substantive-change">substantive
- changes</a> to a mature document, particularly if this would cause
significant compatibility problems due to existing implementation. Working
Groups <em class="rfc2119">should</em> record substantive or interesting
proposals raised by reviews but not incorporated into a current
specification.
<h5 id="wide-review">7.2.3.1 Wide Review</h5>
<p>The requirements for wide review are not precisely defined by the W3C
Process. The objective is to ensure that the entire set of stakeholders
of the Web community, including the general public, have had adequate
notice of the progress of the Working Group (for example through notices
posted to <a href="mailto:public-review-announce@w3.org">public-review-announce@w3.org</a>)
and thereby an opportunity to comment on the specification.
<meta charset="utf-8">
<span style="color: rgb(0, 0, 0); font-family: Arial, sans-serif; font-size: 15px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 21.503999710083px; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none; background-color: rgb(255, 255, 255);">A
second objective is to encourage groups to request reviews early
enough that comments and suggested changes may still be reasonably
incorporated in response to the review. </span>Before approving
transitions, the Director will consider who has been explicitly offered
a reasonable opportunity to review the document, who has provided
comments, the record of requests to and responses from reviewers,
especially groups identified as dependencies in the charter or
identified as <a href="http://www.w3.org/2001/11/StdLiaison.html">liaisons</a>,
and seek evidence of clear communication to the general public about
appropriate times and which content to review and whether such reviews
actually occurred. </p>
<p>For example, inviting review of new or significantly revised sections
published in Working Drafts, and tracking those comments and the Working
Group's responses, is generally a good practice which would often be
considered positive evidence of wide review. Working Groups <span class="rfc2119">should</span>
announce to other W3C Working Groups as well as the general public,
especially those affected by this specification, a proposal to enter
Candidate Recommendation (for example in approximately four weeks). By
contrast a generic statement in a document requesting review at any time
is likely not to be considered as sufficient evidence that the group has
solicited wide review. </p>
<p>A Working Group could present evidence that wide review has been
received, irrespective of solicitation. But it is important to note that
receiving many detailed reviews is not necessarily the same as wide
review, since they may only represent comment from a small segment of
the relevant stakeholder community.</p>
<h4 id="implementation-experience">7.2.4 Implementation Experience</h4>
<p>Implementation experience is required to show that a specification is
sufficiently clear, complete, and relevant to market needs, to ensure
that independent interoperable implementations of each feature of the
specification will be realized. While no exhaustive list of requirements
is provided here, when assessing that there is <dfn>adequate
implementation experience</dfn> the Director will consider (though not
be limited to):</p>
<ul>
<li>is each feature of the current specification implemented, and how is
this demonstrated?</li>
<li>are there independent interoperable implementations of the current
specification?</li>
<li>are there implementations created by people other than the authors
of the specification?</li>
<li>are implementations publicly deployed?</li>
<li>is there implementation experience at all levels of the
specification's ecosystem (authoring, consuming, publishing…)?</li>
<li>are there reports of difficulties or problems with implementation?</li>
</ul>
<p>Planning and accomplishing a demonstration of (interoperable)
implementations can be very time consuming. Groups are often able to
work more effectively if they plan how they will demonstrate
interoperable implementations early in the development process; for
example, they may wish to develop tests in concert with implementation
efforts.</p>
<h4 id="correction-classes">7.2.5 Classes of Changes</h4>
<p>This document distinguishes the following 4 classes of changes to a
specification. The first two classes of change are considered <dfn id="editorial-change">editorial
+ changes</a> to a mature document, particularly if this would cause
significant compatibility problems due to existing implementation. Working
Groups <em class="rfc2119">should</em> record substantive or interesting
proposals raised by reviews but not incorporated into a current
specification.
<h5 id="wide-review">7.2.3.1 Wide Review</h5>
<p>The requirements for wide review are not precisely defined by the W3C
Process. The objective is to ensure that the entire set of stakeholders
of the Web community, including the general public, have had adequate
notice of the progress of the Working Group (for example through notices
posted to <a href="mailto:public-review-announce@w3.org">public-review-announce@w3.org</a>)
and
<meta charset="utf-8">
were able to actually perform reviews of and provide comments on the
specification.
<meta charset="utf-8">
A second objective is to encourage groups to request reviews early
enough that comments and suggested changes may still be reasonably
incorporated in response to the review. Before approving transitions,
the Director will consider who has been explicitly offered a reasonable
opportunity to review the document, who has provided comments, the
record of requests to and responses from reviewers, especially groups
identified as dependencies in the charter or identified as <a href="http://www.w3.org/2001/11/StdLiaison.html">liaisons</a>
[<a href="#rdf-liaison-list">PUB29</a>], and seek evidence of clear
communication to the general public about appropriate times and which
content to review and whether such reviews actually occurred. </p>
<p>For example, inviting review of new or significantly revised sections
published in Working Drafts, and tracking those comments and the Working
Group's responses, is generally a good practice which would often be
considered positive evidence of wide review. Working Groups <span class="rfc2119">should</span>
announce to other W3C Working Groups as well as the general public,
especially those affected by this specification, a proposal to enter
Candidate Recommendation (for example in approximately four weeks). By
contrast a generic statement in a document requesting review at any time
is likely not to be considered as sufficient evidence that the group has
solicited wide review. </p>
<p>A Working Group could present evidence that wide review has been
received, irrespective of solicitation. But it is important to note that
receiving many detailed reviews is not necessarily the same as wide
review, since they may only represent comment from a small segment of
the relevant stakeholder community.</p>
<h4 id="implementation-experience">7.2.4 Implementation Experience</h4>
<p>Implementation experience is required to show that a specification is
sufficiently clear, complete, and relevant to market needs, to ensure
that independent interoperable implementations of each feature of the
specification will be realized. While no exhaustive list of requirements
is provided here, when assessing that there is <dfn>adequate
implementation experience</dfn> the Director will consider (though not
be limited to):</p>
<ul>
<li>is each feature of the current specification implemented, and how is
this demonstrated?</li>
<li>are there independent interoperable implementations of the current
specification?</li>
<li>are there implementations created by people other than the authors
of the specification?</li>
<li>are implementations publicly deployed?</li>
<li>is there implementation experience at all levels of the
specification's ecosystem (authoring, consuming, publishing…)?</li>
<li>are there reports of difficulties or problems with implementation?</li>
</ul>
<p>Planning and accomplishing a demonstration of (interoperable)
implementations can be very time consuming. Groups are often able to
work more effectively if they plan how they will demonstrate
interoperable implementations early in the development process; for
example, they may wish to develop tests in concert with implementation
efforts.</p>
<h4 id="correction-classes">7.2.5 Classes of Changes</h4>
<p>This document distinguishes the following 4 classes of changes to a
specification. The first two classes of change are considered <dfn id="editorial-change">editorial
changes</dfn>, the latter two <dfn id="substantive-change">substantive
changes</dfn>.</p>
<dl>
<dt>1. No changes to text content</dt>
<dd>These changes include fixing broken links, style sheets or invalid
markup.</dd>
<dt>2. Corrections that do not affect conformance</dt>
<dd>Editorial changes or clarifications that do not change the technical
content of the specification.</dd>
<dt>3. Corrections that do not add new features</dt>
<dd>These changes <span class="rfc2119">may</span> affect conformance
to the specification. A change that affects conformance is one that:
<ul>
<li>makes conforming data, processors, or other conforming agents
become non-conforming according to the new version, or</li>
<li>makes non-conforming data, processors, or other agents become
conforming, or</li>
<li>clears up an ambiguity or under-specified part of the
specification in such a way that data, a processor, or an agent
whose conformance was once unclear becomes clearly either
conforming or non-conforming.</li>
</ul>
</dd>
<dt>4. New features</dt>
<dd>Changes that add a new functionality, element, etc.</dd>
</dl>
<h3 id="working-draft">7.3 Working Draft</h3>
<p>A Public Working Draft is published on the <a href="http://www.w3.org/TR/">W3C's
- Technical Reports page</a> [TR] for review, and for simple historical
reference. For all Public Working Drafts a Working Group</p>
<ul>
<li> <em class="rfc2119">should</em> document outstanding issues, and
parts of the document on which the Working Group does not have
consensus, and</li>
<li> <em class="rfc2119">may</em> request publication of a Working
Draft even if its content is considered unstable and does not meet all
Working Group requirements.</li>
</ul>
<h4 id="first-wd">7.3.1 First Public Working Draft</h4>
<p>To publish the First Public Working Draft of a document, a Working
Group must meet the applicable <a href="#transition-reqs">general
requirements for advancement</a>.</p>
<p>The Director <em class="rfc2119">must</em> announce the publication of
a First Public Working Draft publication to other W3C groups and to the
public. </p>
<p>Publishing the First Public Working Draft triggers a Call for
Exclusions, per <a href="http://www.w3.org/Consortium/Patent-Policy/#sec-Exclusion">section
+ Technical Reports page</a> [<a href="#rdf-doc-list">PUB11</a>] for
review, and for simple historical reference. For all Public Working
Drafts a Working Group</p>
<ul>
<li> <em class="rfc2119">should</em> document outstanding issues, and
parts of the document on which the Working Group does not have
consensus, and</li>
<li> <em class="rfc2119">may</em> request publication of a Working
Draft even if its content is considered unstable and does not meet all
Working Group requirements.</li>
</ul>
<h4 id="first-wd">7.3.1 First Public Working Draft</h4>
<p>To publish the First Public Working Draft of a document, a Working
Group must meet the applicable <a href="#transition-reqs">general
requirements for advancement</a>.</p>
<p>The Director <em class="rfc2119">must</em> announce the publication of
a First Public Working Draft publication to other W3C groups and to the
public. </p>
<p>Publishing the First Public Working Draft triggers a Call for
Exclusions, per <a href="http://www.w3.org/Consortium/Patent-Policy/#sec-Exclusion">section
4</a> of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C
Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
<h4 id="revised-wd">7.3.2 Revising Public Working Drafts</h4>
<p>A Working Group <em class="rfc2119">should</em> 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. </p>
<p>If 6 months elapse without significant changes to a specification a
Working Group <em class="rfc2119">should</em> publish a revised Working
Draft, whose status section <em class="rfc2119">should</em> indicate
reasons for the lack of change. </p>
<p>To publish a revision of a Working draft, a Working Group </p>
<ul>
<li><em class="rfc2119">must</em> record the group's decision to request
publication. Consensus is not required, as this is a procedural step,</li>
<li><em class="rfc2119">must</em> provide public documentation of <a href="#substantive-change">substantive
changes</a> to the technical report since the previous Working
Draft,</li>
<li><em class="rfc2119">should</em> provide public documentation of
significant <a href="#editorial-change">editorial changes</a> to the
technical report since the previous step,</li>
<li><em class="rfc2119">should</em> report which, if any, of the Working
Group's requirements for this document have changed since the previous
step,</li>
<li><em class="rfc2119">should</em> report any changes in dependencies
with other groups,</li>
</ul>
<p>Possible next steps for any Working Draft:</p>
<ul>
<li>Revised <a href="#revised-wd">Public Working Draft</a></li>
<li><a href="#last-call">Candidate recommendation</a>.</li>
<li><a href="#Note">Working Group Note</a></li>
</ul>
<h4 id="tr-end">7.3.3 Stopping Work on a specification</h4>
<p>Work on a technical report <em class="rfc2119">may</em> cease at any
time. Work <em class="rfc2119 new">should</em> cease if W3C or a
Working Group determines that it cannot productively carry the work any
further. If the Director <a href="#GeneralTermination">closes a Working
Group</a> W3C <em class="rfc2119">must </em> publish any unfinished
specifications on the Recommendation track as <a href="#Note">Working
Group Notes</a>. If a Working group decides, or the Director requires,
the Working Group to discontinue work on a technical report before
completion, the Working Group <em class="rfc2119">should</em> publish
the document as a <a href="#Note">Working Group Note</a>. </p>
<h3 id="candidate-rec"><a id="last-call">7.4 Candidate Recommendation </a></h3>
<p>To publish a Candidate recommendation, in addition to meeting the <a href="#transition-reqs">general
requirements for advancement</a> a Working Group:</p>
<ul>
<li><em class="rfc2119">must</em> show that the specification has met
all Working Group requirements, or explain why the requirements have
changed or been deferred,</li>
<li><em class="rfc2119">must</em> document changes to dependencies
during the development of the specification,</li>
<li><em class="rfc2119">must</em> document how adequate <a href="#implementation-experience">
implementation experience</a> will be demonstrated,</li>
<li><em class="rfc2119">must</em> specify the deadline for comments,
which <em class="rfc2119">must</em> be <strong>at least</strong>
four weeks after publication, and <em class="rfc2119">should</em> be
longer for complex documents,</li>
<li><em class="rfc2119">must</em> show that the specification has
received <a href="#wide-review">wide review</a>, and</li>
<li><em class="rfc2119">may</em> identify features in the document as
"at risk". These features <em class="rfc2119">may</em> be removed
before advancement to Proposed Recommendation without a requirement to
publish a new Candidate Recommendation.</li>
</ul>
<p>The Director <em class="rfc2119">must</em> announce the publication of
a Candidate Recommendation to other W3C groups and to the public, and <em
class="rfc2119">must</em>
begin an Advisory Committee Review on the question of whether W3C should
publish the specification as a W3C Recommendation.</p>
<p> A Candidate Recommendation corresponds to a "Last Call Working Draft"
as used in the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C
Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>]. Publishing
a Candidate Recommendation triggers a Call for Exclusions, per <a href="http://www.w3.org/Consortium/Patent-Policy/#sec-Exclusion">section
@@ -152,7 +154,7 @@
Recommendation</a>, or</li>
<li><em class="rfc2119">may</em> be <a href="#rec-rescind">rescinded</a>.</li>
</ul>
<h3 id="rec-modify">7.7 Modifying a W3C Recommendation</h3>
<p>This section details the management of errors in, and the process for
making changes to a Recommendation. Please see also the <a href="http://www.w3.org/2003/01/republishing/">Requirements
for modification of W3C Technical Reports</a> [<a href="#in-place-tr-mod">PUB35</a>].</p>
<p>
<svg xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg"
viewBox="0 0 500 160"
height="12em"
width="50em">
<g id="basicProcess" opacity=".6">
<g id="Modif-nodeWD">
<ellipse ry="18" rx="38" cy="40" cx="147" stroke="black" fill="none"></ellipse>
<a xlink:href="#RecsWD"><text font-size="14" font-family="Times,serif"
y="44"
x="147"
text-anchor="middle">WD</text></a>
</g>
<g id="Modif-repeatWD" stroke="black">
<path d="M128,24C123,14 129,4 147,4 158,4 165,8 167,14" fill="none"
stroke-dasharray="6 1"></path>
<polygon points="170,14 166,24 164,13"></polygon> </g>
<g class="edge" id="Modif-toCR" stroke="black" fill="black">
<path d="M185,40h31"></path>
<polygon points="211,36 221,40 211,44"></polygon> </g>
<g id="Modif-nodeCR">
<ellipse ry="18" rx="38" cy="40" cx="260" stroke="black" fill="none"></ellipse>
<a xlink:href="#RecsCR"><text font-size="14" font-family="Times,serif"
y="44"
x="260"
text-anchor="middle">CR</text></a>
</g>
<g class="edge" id="Modif-repeatCR" stroke="black" fill="black">
<path d="M242,24C238,14 244,4 260,4 271,4 277,8 279,14" stroke-dasharray="5 3"
fill="none"></path>
<polygon points="282,14 277,24 275,13"></polygon> </g>
<g id="Modif-backToWD" stroke="#666" fill="#666">
<path d="M190,47h34" stroke-dasharray="4 4"></path>
<polygon points="190,45 183,47 190,49"></polygon> </g>
<g class="edge" id="Modif-ToPR" stroke="black" fill="black">
<path d="M298,40h27"></path>
<polygon points="324,36 334,40 324,44"></polygon> </g>
<g id="Modif-nodePR">
<ellipse ry="18" rx="28" cy="40" cx="363" stroke="black" fill="none"></ellipse>
<a xlink:href="#RecsPR"><text font-size="14" font-family="Times,serif"
y="44"
x="363"
text-anchor="middle">PR</text></a>
</g>
<g id="Modif-BackToCR" stroke="#aaa" fill="#aaa">
<path d="M301,47h38" stroke-dasharray="2 5"></path>
<polygon points="301,45 296,47 301,49"></polygon> </g>
<g id="Modif-ToRec" stroke="black" fill="black">
<path d="M391,40h20"></path>
<polygon points="404,36 414,40 404,44"></polygon> </g> </g>
<g id="Modif-nodeRec" stroke="black">
<ellipse ry="18" rx="28" cy="40" cx="443" fill="none" stroke-width="2"></ellipse>
<a xlink:href="#RecsW3C"><text font-size="16" font-family="Times,serif"
y="44"
x="443"
text-anchor="middle"
stroke-width=".3">REC</text></a></g>
<g id="changeARec" stroke="black">
<path d="M443,58 v20"></path><polygon points="443,78 441,71 445,71"></polygon>
<polygon points="443,78 486,103 443,128 400,103" fill="none"></polygon>
<text x="445" y="68" font-size="10" stroke="none">Changes to text</text>
<text x="443" y="103" text-anchor="middle" font-size="10" stroke-width="0.2"><tspan>Substantive</tspan><tspan
x="443"
y="113"
text-anchor="middle">changes?</tspan></text></g>
<g id="RecToPR">
<text x="370" y="100" font-size="10" stroke="none">No</text>
<path d="M400,103h-37v-45" stroke="black" fill="none"></path><polygon
stroke="black"
points="363,58 361,65 365,65"></polygon></g>
<g id="Modif-RecSubstantiveChanges" stroke="black">
<text x="488" y="100" font-size="10" stroke-width="0.2">Yes</text>
<path d="M486,103h20v40h-246v-15" fill="none"></path>
<polygon points="260,128 262,133 258,133"></polygon>
<polygon points="260,128 300,103 260,78 220,103" fill="none"></polygon>
<text font-size="10" stroke-width="0.2" x="260" y="98" text-anchor="middle">New<tspan
x="260"
y="108"
text-anchor="middle">Features?</tspan></text></g>
<g id="Modif-NoNewFeatures">
<path d="M260,78v-20" stroke="black"></path>
<text x="262" y="75" font-size="10">No</text>
<polygon points="260,58 262,63 258,63" stroke="black"></polygon> </g>
<g id="Modif-BackToFPWD" stroke="black">
<a xlink:href="#first-wd"><text font-size="8" font-family="Times,serif"
y="38"
x="66"
stroke="none">First
- WD</text></a>
<path d="M220,103h-160v-63h43" fill="none"></path>
<text x="200" y="100" stroke-width="0.2" fill="black" font-size="10">Yes</text>
<polygon points="103,38 108,40 103,42"></polygon> </g> </svg></p>
<h4 id="errata">7.7.1 Errata Management</h4>
<p>Tracking errors is an important part of a Working Group's ongoing care
of a Recommendation; for this reason, the scope of a Working Group
charter generally allows time for work after publication of a
Recommendation. In this Process Document, the term "erratum" (plural
"errata") refers to
<meta charset="utf-8">
any error that can be resolved by one or more changes in classes 1-3 of
section <a href="#correction-classes">7.2.5 Classes of Changes</a>.</p>
<p>Working Groups <em class="rfc2119">must</em> keep a
<meta charset="utf-8">
record as errors are reported by readers and implementers. Such error
reports <em class="rfc2119">should</em> be processed no less frequently
than quarterly. Readers of the Recommendation <em class="rfc2119">should</em>
be able easily to find and see the errata that apply to that specific
Recommendation.</p>
<p>
<meta charset="utf-8">
Working groups may decide how to document errata. The best practice is a
document that identifies itself as based on the Recommendation text and
clearly identifies the errata and any proposed corrections; other
approaches include various forms of an errata page, possibly
auto-generated from a database.</p>
<p>An correction is resolved by an informative, "proposed" correction
generated by the Working Group. A correction becomes part of the
Recommendation by the process for Revising a Recommendation described in
the next section.</p>
<h4 id="revised-rec">7.7.2 Revising a Recommendation</h4>
<p>A Working group <em class="rfc2119">may</em> request republication of
a Recommendation, or W3C <em class="rfc2119">may</em> republish a
Recommendation, to make corrections that do not result in any changes to
the text of the specification.</p>
<p><a href="#editorial-change">Editorial changes</a> to a Recommendation
require no technical review of the proposed changes. A Working Group <span
class="rfc2119">may</span>
request publication of a <a href="#rec-pr">Proposed Recommendation</a>
+ WD</text></a>
<path d="M220,103h-160v-63h43" fill="none"></path>
<text x="200" y="100" stroke-width="0.2" fill="black" font-size="10">Yes</text>
<polygon points="103,38 108,40 103,42"></polygon> </g> </svg></p>
<h4 id="errata">7.7.1 Errata Management</h4>
<p>Tracking errors is an important part of a Working Group's ongoing care
of a Recommendation; for this reason, the scope of a Working Group
charter generally allows time for work after publication of a
Recommendation. In this Process Document, the term "erratum" (plural
"errata") refers to
<meta charset="utf-8">
any error that can be resolved by one or more changes in classes 1-3 of
section <a href="#correction-classes">7.2.5 Classes of Changes</a>.</p>
<p>Working Groups <em class="rfc2119">must</em> keep a
<meta charset="utf-8">
record as errors are reported by readers and implementers. Such error
reports <em class="rfc2119">should</em> be processed no less frequently
than quarterly. Readers of the Recommendation <em class="rfc2119">should</em>
be able easily to find and see the errata that apply to that specific
Recommendation.</p>
<p>
<meta charset="utf-8">
Working groups may decide how to document errata. The best practice is a
document that identifies itself as based on the Recommendation text and
clearly identifies the errata and any proposed corrections; other
approaches include various forms of an errata page, possibly
auto-generated from a database.</p>
<p>An erratum is resolved by an informative, "proposed" correction
generated by the Working Group. A correction becomes part of the
Recommendation by the process for Revising a Recommendation described in
the next section.</p>
<h4 id="revised-rec">7.7.2 Revising a Recommendation</h4>
<p>A Working group <em class="rfc2119">may</em> request republication of
a Recommendation, or W3C <em class="rfc2119">may</em> republish a
Recommendation, to make corrections that do not result in any changes to
the text of the specification.</p>
<p><a href="#editorial-change">Editorial changes</a> to a Recommendation
require no technical review of the proposed changes. A Working Group <span
class="rfc2119">may</span>
request publication of a <a href="#rec-pr">Proposed Recommendation</a>
or W3C <span class="rfc2119">may</span> publish a <a href="#rec-pr">Proposed
Recommendation</a> to make this class of change without passing
through earlier maturity levels. Such publications are <em class="rfc2119">may</em>
be called a <dfn>Proposed Edited Recommendation</dfn>.</p>
<p>To make corrections to a Recommendation that produce <a href="#substantive-change">substantive
changes</a> but do not add new features, a Working Group <span class="rfc2119">may</span>
request publication of a <a href="#last-call">Candidate Recommendation</a>,
without passing through earlier maturity levels.</p>
<p>In the latter two cases, the resulting Recommendation <em class="rfc2119">may</em>
be called an <dfn id="rec-edited">Edited Recommendation</dfn>.</p>
<p>When requesting the publication of an edited Recommendation as
described in this section, in addition to meeting the requirements for
the relevant maturity level, a Working Group</p>
<ul>
<li><em class="rfc2119">must</em> show that the changes to the document
have received <a href="#wide-review">wide review</a>, and </li>
<li><em class="rfc2119">should</em> address all recorded errata.</li>
</ul>
<p>For changes which introduces a new feature or features, W3C <span class="rfc2119">must</span>
follow the full process of <a href="#rec-advance">advancing a technical
report to Recommendation</a> beginning with a new First Public Working
Draft.</p>
<h3 id="Note">7.8 Publishing a Working Group or Interest Group Note</h3>
<p>Working Groups and Interest Groups publish material that is not a
formal specification as Notes. This includes supporting documentation
for a specification such as explanations of design principles or use
cases and requirements, non-normative guides to good practices, as well
as specifications where work has been stopped and there is no longer
consensus for making them a new standard.</p>
<p>In order to publish a Note, a Working Group or Interest Group: </p>
<ul>
<li> <em class="rfc2119">may</em> publish a Note with or without its
prior publication as a Working Draft.</li>
<li><em class="rfc2119">must</em> record the group's decision to request
publication as a Note, and</li>
<li><em class="rfc2119">should</em> publish documentation of significant
changes to the technical report since any previous publication.</li>
</ul>
<p>Possible next steps:</p>
<ul>
<li>End state: A technical report <em class="rfc2119">may</em> remain a
Working Group Note indefinitely</li>
<li>A Working Group <em class="rfc2119">may</em> resume work on
technical report within the scope of its charter at any time, at the
maturity level the specification had before publication as a Note</li>
</ul>
<p>The <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent
Policy</a> [<a href="#ref-patentpolicy">PUB33</a>] does not specify
any licensing requirements or commitments for Working Group Notes.</p>
<h3 id="rec-rescind">7.9 Rescinding a W3C Recommendation</h3>
<p>W3C <em class="rfc2119">may</em> rescind a Recommendation, for example
if the Recommendation contains many errors that conflict with a later
version or if W3C discovers burdensome patent claims that affect
implementers and cannot be resolved; see the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C
@@ -177,7 +179,7 @@
confidentiality level</a>. This <a href="#def-w3c-decision">W3C
decision</a> is generally one of the following:</p>
<ol>
<li>The proposal is approved, possibly with minor changes integrated.</li>
<li>The proposal is approved, possibly with <a href="#substantive-change">substantive
changes</a> integrated. In this case the Director's announcement <span
class="rfc2119">MUST</span>
include rationale for the decision to advance the document despite the
proposal for a substantive change.</li>
<li>The proposal is returned for additional work, with a request to the
initiator to <a href="#formal-address">formally address</a> certain
issues.</li>
<li>The proposal is rejected.</li>
</ol>
<p>This document does not specify time intervals between the end of an
Advisory Committee review period and the <a href="#def-w3c-decision">W3C
decision</a>. This is to ensure that the Members and Team have
sufficient time to consider comments gathered during the review. The
Advisory Committee <span class="rfc2119">SHOULD NOT</span> expect an
announcement sooner than <span class="time-interval">two weeks</span>
after the end of a Proposed Recommendation review period. If, after <span
class="time-interval">three
- weeks</span>, the Director has not announced the outcome, the Director
<span class="rfc2119">SHOULD</span> provide the Advisory Committee with
an update.</p>
<h3 id="ACAppeal">8.2Appeal by Advisory Committee Representatives</h3>
<p>Advisory Committee representatives <span class="rfc2119">MAY</span>
appeal certain decisions, though appeals are only expected to occur in
extraordinary circumstances.</p>
<p>When Advisory Committee review immediately precedes a decision,
Advisory Committee representatives <span class="rfc2119">MAY</span>
only appeal when there is <a href="#def-Dissent">dissent</a>. These
decisions are:</p>
<ul>
<li><a href="#rec-publication">Publication of a Recommendation</a> or <a
href="#proposed-rescinded-rec">Publication
+ weeks</span>, the Director has not announced the outcome, the Director
<span class="rfc2119">SHOULD</span> provide the Advisory Committee with
an update.</p>
<h3 id="ACAppeal">8.2 Appeal by Advisory Committee Representatives</h3>
<p>Advisory Committee representatives <span class="rfc2119">MAY</span>
appeal certain decisions, though appeals are only expected to occur in
extraordinary circumstances.</p>
<p>When Advisory Committee review immediately precedes a decision,
Advisory Committee representatives <span class="rfc2119">MAY</span>
only appeal when there is <a href="#def-Dissent">dissent</a>. These
decisions are:</p>
<ul>
<li><a href="#rec-publication">Publication of a Recommendation</a> or <a
href="#proposed-rescinded-rec">Publication
of a Rescinded Recommendation</a>,</li>
<li><a href="#cfp">Working or Interest Group creation</a>, substantive <a
href="#CharterReview">modification</a>
or <a href="#charter-extension">extension</a>,</li>
<li>Changes to the <a href="#GAProcess">W3C process</a>.</li>
</ul>
<p>Advisory Committee representatives <span class="rfc2119">MAY</span>
always appeal the following decisions:</p>
<ul>
<li><a href="#charter-extension">Working or Interest Group extension</a>
or <a href="#GeneralTermination">closure</a>,</li>
<li><a href="#candidate-rec">Call for Implementations</a>, <a href="#cfr">Call
for Review of a Proposed Recommendation</a>, <a href="#cfr-edited">Call
for Review of an Edited Recommendation</a>, or <a href="#proposed-rescinded-rec">Proposal
@@ -214,5 +216,5 @@
Software
Notice and License</a></cite></dd>
<dt id="rdf-translations">[PUB20]</dt>
<dd><cite><a href="http://www.w3.org/Consortium/Translation/">Translations
of W3C technical reports</a></cite></dd>
<dt id="rdf-pub-mailing-lists">[PUB21]</dt>
<dd><cite><a href="http://www.w3.org/Mail/">Public W3C mailing lists</a></cite></dd>
<dt id="rdf-coi">[PUB23]</dt>
<dd><cite><a href="http://www.w3.org/2000/09/06-conflictpolicy">Conflict
of Interest Policy for W3C Team Members Engaged in Outside
Professional Activities</a></cite></dd>
<dt id="rdf-tag-charter">[PUB25]</dt>
<dd><cite><a href="http://www.w3.org/2001/07/19-tag">Technical
Architecture Group (TAG) Charter</a></cite></dd>
<dt id="rdf-tag-home">[PUB26]</dt>
<dd><cite><a href="http://www.w3.org/2001/tag/">The TAG home page</a></cite></dd>
<dt id="rdf-rec-tips">[PUB27]</dt>
<dd><cite><a href="http://www.w3.org/2002/05/rec-tips">Tips for Getting
to Recommendation Faster</a></cite></dd>
<dt id="rdf-liaison-list">[PUB28]</dt>
<dd><cite><a href="http://www.w3.org/2001/11/StdLiaison">W3C liaisons
with other organizations</a></cite></dd>
<dt id="rdf-ab-home">[PUB30]</dt>
<dd><cite><a href="http://www.w3.org/2002/ab/">The Advisory Board home
page</a></cite></dd>
<dt id="rdf-pubrules">[PUB31]</dt>
<dd><cite><a href="http://www.w3.org/Guide/pubrules">Publication Rules</a></cite></dd>
<dt id="rdf-fellows">[PUB32]</dt>
<dd><cite><a href="http://www.w3.org/Consortium/Recruitment/Fellows">W3C
Fellows Program</a></cite></dd>
<dt id="rdf-patentpolicy">[PUB33]</dt>
<dd><cite><a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5
Feb 2004 version of the W3C Patent Policy</a></cite>. The <a href="http://www.w3.org/Consortium/Patent-Policy/">latest
- version of the W3C Patent Policy</a> is available at
http://www.w3.org/Consortium/Patent-Policy/.</dd>
<dt id="in-place-tr-mod">[PUB35]</dt>
<dd><cite><a href="http://www.w3.org/2003/01/republishing/">In-place
modification of W3C Technical Reports</a></cite></dd>
</dl>
<h3>13.2 <a id="member-refs">Member-only Resources</a></h3>
<p>The following <a href="#Member-only">Member-only</a> information is
available at the <a href="http://www.w3.org/">W3C Web site</a>.</p>
<dl>
<dt id="rdf-current-ac">[MEM1]</dt>
<dd><cite><a href="http://www.w3.org/Member/ACList">Current Advisory
Committee representatives</a></cite></dd>
<dt id="rdf-mailing-lists">[MEM2]</dt>
<dd><cite><a href="http://www.w3.org/Member/Mail/">Group mailing lists</a></cite></dd>
<dt id="rdf-calendar">[MEM3]</dt>
<dd>The <cite><a href="http://www.w3.org/Member/Eventscal">calendar of
all scheduled official W3C events</a></cite></dd>
<dt id="rdf-new-member">[MEM4]</dt>
<dd>The <cite><a href="http://www.w3.org/Member/Intro">New Member
Orientation</a></cite>, which includes an introduction to W3C
processes from a practical standpoint, including relevant email
addresses.</dd>
<dt id="rdf-ac-meetings">[MEM5]</dt>
<dd><cite><a href="http://www.w3.org/Member/Meeting/">Advisory Committee
meetings</a></cite></dd>
<dt id="rdf-member-web">[MEM6]</dt>
<dd><cite><a href="http://www.w3.org/Member/">Member Web site</a></cite></dd>
<dt id="rdf-member-sub">[MEM8]</dt>
<dd><cite><a href="http://www.w3.org/2000/09/submission">How to send a
Submission request</a></cite></dd>
<dt id="rdf-guide">[MEM9]</dt>
<dd><cite><a href="http://www.w3.org/Guide/">The Art of Consensus</a></cite>,
a guidebook for W3C Working Group Chairs and other collaborators</dd>
<dt id="rdf-discipline-gl">[MEM14]</dt>
<dd><cite><a href="http://www.w3.org/2002/09/discipline">Guidelines for
Disciplinary Action</a></cite></dd>
<dt id="rdf-election-howto">[MEM15]</dt>
<dd><cite><a href="http://www.w3.org/2002/10/election-howto">How to
Organize an Advisory Board or TAG election</a></cite></dd>
</dl>
<h3> id="other-refs">13.3 Other References</h3>
<dl>
<dt id="rdf-RFC2119">[RFC2119]</dt>
<dd><cite><a href="http://www.ietf.org/rfc/rfc2119.txt">"Key words for
use in RFCs to Indicate Requirement Levels"</a></cite>, S.
Bradner, March 1997.</dd>
<dt id="ref-RFC2777">[RFC2777]</dt>
<dd><cite><a href="http://www.ietf.org/rfc/rfc2777.txt">"Publicly
Verifiable Nomcom Random Selection"</a></cite>, D. Eastlake 3rd,
February 2000.</dd>
</dl>
<h2 id="acks">14 Acknowledgments</h2>
<p>The following individuals have contributed to this proposal for a
revised Process: Daniel Appelquist (Telefonica), Art Barstow (Nokia),
Robin Berjon (W3C), Judy Brewer (W3C), Marcos Cáceres (Mozilla), Wayne
Carr (Intel), Michael Champion (W3C), Mark Crawford (SAP), Karl Dubost
(Mozilla), Fantasai (unaffiliated), Virginie Galindo (Gemalto), Daniel
Glazman (Disruptive Innovations), Eduardo Gutentag (unaffiiliated), Brad
Hill (Facebook), Cullen Jennings (Cisco), Jeff Jaffe (W3C), Brain
Kardell (JQuery), Peter Linss (HP), Nigel Megitt (BBC), Olle Olsson
(SICS), Natasha Rooney (GSMA), Sam Ruby (IBM), David Singer (Apple),
Henri Sivonen (Mozilla), Josh Soref (BlackBerry), Anne van Kesteren
(Mozilla), Léonie Watson (The Paciello Group), Mike West (Google), Chris
Wilson (Google), Steve Zilles (Adobe).</p>
<p>The following individuals contributed to the development of earlier
versions of the Process: Jean-François Abramatic (IBM, and previously
ILOG and W3C), Dan Appelquist (Telefonica), Art Barstow (Nokia), Ann
Bassetti (The Boeing Company), Jim Bell (HP), Robin Berjon (W3C), Tim
Berners-Lee (W3C), Klaus Birkenbihl (Fraunhofer Gesellschaft), Don
Brutzman (Web3D), Carl Cargill (Netscape, Sun Microsystems), Wayne Carr
(Intel), Marcos Cáceres (Mozilla), Michael Champion (Microsoft), Paul
Cotton (Microsoft), Mark Crawford (SAP), Tantek Çelik (Mozilla), Don
Deutsch (Oracle), David Fallside (IBM), Fantasai (Mozilla), Wendy Fong
(Hewlett-Packard), Virginie Galindo (Gemalto), Daniel Glazman
(Disruptive Innovations), Paul Grosso (Arbortext), Eduardo Gutentag (Sun
Microsystems), Joe Hall (CDT), Ivan Herman (W3C), Ian Hickson (Google),
Steve Holbrook (IBM), Renato Iannella (IPR Systems), Ian Jacobs (W3C),
Jeff Jaffe (W3C), Cullen Jennings (Cisco), Sally Khudairi (W3C), John
Klensin (MCI), Tim Krauskopf (Spyglass), Kari Laihonen (Ericsson), Ken
Laskey (MITRE), Ora Lassila (Nokia), Håkon Wium Lie (Opera Software),
Chris Lilley (W3C), Bede McCall (MITRE), Giri Mandyam (Qualcomm), Larry
Masinter (Adobe Systems), Qiuling Pan (Huawei), TV Raman (Google),
Thomas Reardon (Microsoft), Claus von Riegen (SAP AG), David Singer
(Apple), David Singer (IBM), Ralph Swick (W3C), Anne van Kesteren,
Jean-Charles Verdié (MStar), Chris Wilson (Google), Lauren Wood
(unaffiliated), and Steve Zilles (Adobe Systems).</p>
<h2 id="changes">15 Changes</h2>
<p>This document is based on 1 August 2014 Process. <a href="https://dvcs.w3.org/hg/AB/">Detailed
+ version of the W3C Patent Policy</a> is available at
http://www.w3.org/Consortium/Patent-Policy/.</dd>
<dt id="in-place-tr-mod">[PUB35]</dt>
<dd><cite><a href="http://www.w3.org/2003/01/republishing/">In-place
modification of W3C Technical Reports</a></cite></dd>
</dl>
<h3>13.2 <a id="member-refs">Member-only Resources</a></h3>
<p>The following <a href="#Member-only">Member-only</a> information is
available at the <a href="http://www.w3.org/">W3C Web site</a>.</p>
<dl>
<dt id="rdf-current-ac">[MEM1]</dt>
<dd><cite><a href="http://www.w3.org/Member/ACList">Current Advisory
Committee representatives</a></cite></dd>
<dt id="rdf-mailing-lists">[MEM2]</dt>
<dd><cite><a href="http://www.w3.org/Member/Mail/">Group mailing lists</a></cite></dd>
<dt id="rdf-calendar">[MEM3]</dt>
<dd>The <cite><a href="http://www.w3.org/Member/Eventscal">calendar of
all scheduled official W3C events</a></cite></dd>
<dt id="rdf-new-member">[MEM4]</dt>
<dd>The <cite><a href="http://www.w3.org/Member/Intro">New Member
Orientation</a></cite>, which includes an introduction to W3C
processes from a practical standpoint, including relevant email
addresses.</dd>
<dt id="rdf-ac-meetings">[MEM5]</dt>
<dd><cite><a href="http://www.w3.org/Member/Meeting/">Advisory Committee
meetings</a></cite></dd>
<dt id="rdf-member-web">[MEM6]</dt>
<dd><cite><a href="http://www.w3.org/Member/">Member Web site</a></cite></dd>
<dt id="rdf-member-sub">[MEM8]</dt>
<dd><cite><a href="http://www.w3.org/2000/09/submission">How to send a
Submission request</a></cite></dd>
<dt id="rdf-guide">[MEM9]</dt>
<dd><cite><a href="http://www.w3.org/Guide/">The Art of Consensus</a></cite>,
a guidebook for W3C Working Group Chairs and other collaborators</dd>
<dt id="rdf-discipline-gl">[MEM14]</dt>
<dd><cite><a href="http://www.w3.org/2002/09/discipline">Guidelines for
Disciplinary Action</a></cite></dd>
<dt id="rdf-election-howto">[MEM15]</dt>
<dd><cite><a href="http://www.w3.org/2002/10/election-howto">How to
Organize an Advisory Board or TAG election</a></cite></dd>
</dl>
<h3 id="other-refs">13.3 Other References</h3>
<dl>
<dt id="rdf-RFC2119">[RFC2119]</dt>
<dd><cite><a href="http://www.ietf.org/rfc/rfc2119.txt">"Key words for
use in RFCs to Indicate Requirement Levels"</a></cite>, S.
Bradner, March 1997.</dd>
<dt id="ref-RFC2777">[RFC2777]</dt>
<dd><cite><a href="http://www.ietf.org/rfc/rfc2777.txt">"Publicly
Verifiable Nomcom Random Selection"</a></cite>, D. Eastlake 3rd,
February 2000.</dd>
</dl>
<h2 id="acks">14 Acknowledgments</h2>
<p>The following individuals have contributed to this proposal for a
revised Process: Daniel Appelquist (Telefonica), Art Barstow (Nokia),
Robin Berjon (W3C), Judy Brewer (W3C), Marcos Cáceres (Mozilla), Wayne
Carr (Intel), Michael Champion (W3C), Mark Crawford (SAP), Karl Dubost
(Mozilla), Fantasai (unaffiliated), Virginie Galindo (Gemalto), Daniel
Glazman (Disruptive Innovations), Eduardo Gutentag (unaffiiliated), Brad
Hill (Facebook), Cullen Jennings (Cisco), Jeff Jaffe (W3C), Brain
Kardell (JQuery), Peter Linss (HP), Nigel Megitt (BBC), Olle Olsson
(SICS), Natasha Rooney (GSMA), Sam Ruby (IBM), David Singer (Apple),
Henri Sivonen (Mozilla), Josh Soref (BlackBerry), Anne van Kesteren
(Mozilla), Léonie Watson (The Paciello Group), Mike West (Google), Chris
Wilson (Google), Steve Zilles (Adobe).</p>
<p>The following individuals contributed to the development of earlier
versions of the Process: Jean-François Abramatic (IBM, and previously
ILOG and W3C), Dan Appelquist (Telefonica), Art Barstow (Nokia), Ann
Bassetti (The Boeing Company), Jim Bell (HP), Robin Berjon (W3C), Tim
Berners-Lee (W3C), Klaus Birkenbihl (Fraunhofer Gesellschaft), Don
Brutzman (Web3D), Carl Cargill (Netscape, Sun Microsystems), Wayne Carr
(Intel), Marcos Cáceres (Mozilla), Michael Champion (Microsoft), Paul
Cotton (Microsoft), Mark Crawford (SAP), Tantek Çelik (Mozilla), Don
Deutsch (Oracle), David Fallside (IBM), Fantasai (Mozilla), Wendy Fong
(Hewlett-Packard), Virginie Galindo (Gemalto), Daniel Glazman
(Disruptive Innovations), Paul Grosso (Arbortext), Eduardo Gutentag (Sun
Microsystems), Joe Hall (CDT), Ivan Herman (W3C), Ian Hickson (Google),
Steve Holbrook (IBM), Renato Iannella (IPR Systems), Ian Jacobs (W3C),
Jeff Jaffe (W3C), Cullen Jennings (Cisco), Sally Khudairi (W3C), John
Klensin (MCI), Tim Krauskopf (Spyglass), Kari Laihonen (Ericsson), Ken
Laskey (MITRE), Ora Lassila (Nokia), Håkon Wium Lie (Opera Software),
Chris Lilley (W3C), Bede McCall (MITRE), Giri Mandyam (Qualcomm), Larry
Masinter (Adobe Systems), Qiuling Pan (Huawei), TV Raman (Google),
Thomas Reardon (Microsoft), Claus von Riegen (SAP AG), David Singer
(Apple), David Singer (IBM), Ralph Swick (W3C), Anne van Kesteren,
Jean-Charles Verdié (MStar), Chris Wilson (Google), Lauren Wood
(unaffiliated), and Steve Zilles (Adobe Systems).</p>
<h2 id="changes">15 Changes</h2>
<p>This document is based on 1 August 2014 Process. <a href="https://dvcs.w3.org/hg/AB/">Detailed
change logs</a> are available.</p>
<p>The notable changes include:</p>
<h3>Current Editor's draft</h3>
<ul>
<li>Editorial cleanups to <a href="#wide-review">7.2.3.1 Wide Review</a></li>
<li>Editorial Changes to <a href="#errata">7.7.1 Errata Management</a>
- <a href="https://www.w3.org/community/w3process/track/issues/141">ISSUE-141</a></li>
</ul>
<h3>Previous Editor's drafts</h3>
<ul>
<li>Remove <a id="GCGCreation" name="CGCreation"></a><a id="GroupsCG" name="GroupsCG"></a>
<a id="CGParticipation" name="CGParticipation"></a><a id="cgparticipant"
name="cgparticipant"></a>
<a id="CGCharter" name="CGCharter"></a>Coordination groups - <a href="https://www.w3.org/community/w3process/track/issues/129">ISSUE-129</a></li>
<li>Remove vestigial traces of Good Standing</li>
<li>Loosen requirement on multiple employees of one member on TAG -
section 2.5.1</li>
<li>Replace "W3C Chair" with "CEO"</li>
<li>Editorial tweaks to what is requested for review</li>
<li>Remove section <span id="three-month-rule">6.2.7 "Heartbeat"
publishing requirement</span></li>
</ul>
<h3>30 September "AC intermediate review" draft</h3>
<p>Provided to the Advisory Committee to review the following changes made
compared to the 1 August 2014 Operative Process document</p>
<ul>
<li>Remove <a id="ActivityProposal">Activities</a> from the Process (as
resolved multiple times since 2007)</li>
<li>Remove <a id="good-standing">6.2.1.7</a> Good Standing in a Working
Group</li>
</ul>
</main>
</body>
</html>
\ No newline at end of file