--- a/cover.html Sun Jan 11 18:50:43 2015 +0100
+++ b/cover.html Wed Jan 21 01:38:29 2015 +0100
@@ -1,9 +1,9 @@
-<!DOCTYPE html>
<html lang="en">
<head>
<meta content="text/html; charset=utf-8" http-equiv="content-type">
<meta name="keywords" content="W3C, World Wide Web, Web, WWW, Consortium, process, Team, Recommendation, Advisory Committee, Advisory Board, Working Group, Coordination Group, Interest Group, W3C Activity, Workshop, Symposium, charter, Activity Proposal, Working Draft, Process Document, Candidate Recommendation, Director, Proposed Recommendation, Last Call, Submission request">
<link rel="stylesheet" type="text/css" href="https://www.w3.org/StyleSheets/TR/base.css">
<title>World Wide Web Consortium Process Document</title>
<style type="text/css">
.about { margin-left: 3em; margin-right: 3em; font-size: .83em}
table { margin-left: auto; margin-right: auto }
.diagram { text-align: center; margin: 2.5em 0 }
.issue:before {content: "Issue: "}
.issue {border: 2px dashed red; background-color: #ffa;}
.issue .issue {background-color: #fcc;}
.rfc2119 {font-variant:small-caps}
</style> <!--[if lt IE 9]><script src='undefined://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]-->
</head>
<body>
<div class="head"><a href="http://www.w3.org/"><img alt="W3C" src="https://www.w3.org/Icons/w3c_home"
height="48"
width="72"></a>
<h1>W3C Draft Process Document</h1>
<h2 class="notoc">11 January 2015 Editor's Draft</h2>
<dl>
<dt>Latest Editor's version:</dt>
<dd> <a href="https://dvcs.w3.org/hg/AB/raw-file/default/cover.html">https://dvcs.w3.org/hg/AB/raw-file/default/cover.html</a></dd>
<dt>Latest operative version:</dt>
<dd><a href="http://www.w3.org/Consortium/Process/">http://www.w3.org/Consortium/Process/</a></dd>
<dt>Editor:</dt>
<dd>Charles McCathie Nevile, <a style="color:black" href="http://yandex.com"><span
style="color: red;">Y</span>andex</a>—<a
style="color:black"
href="http://yandex.ru"><span
style="color: red;">Я</span>ндекс</a></dd>
<dt>Previous editor:</dt>
<dd>Ian Jacobs, <a href="http://www.w3.org/">W3C</a></dd>
</dl>
<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
© 1996-2014 <a href="/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
(<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
<a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
<a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>),
+<!DOCTYPE html>
<html lang="en">
<head>
<meta content="text/html; charset=utf-8" http-equiv="content-type">
<meta name="keywords" content="W3C, World Wide Web, Web, WWW, Consortium, process, Team, Recommendation, Advisory Committee, Advisory Board, Working Group, Coordination Group, Interest Group, W3C Activity, Workshop, Symposium, charter, Activity Proposal, Working Draft, Process Document, Candidate Recommendation, Director, Proposed Recommendation, Last Call, Submission request">
<link rel="stylesheet" type="text/css" href="https://www.w3.org/StyleSheets/TR/base.css">
<title>World Wide Web Consortium Process Document</title>
<style type="text/css">
.about { margin-left: 3em; margin-right: 3em; font-size: .83em}
table { margin-left: auto; margin-right: auto }
.diagram { text-align: center; margin: 2.5em 0 }
.issue:before {content: "Issue: "}
.issue {border: 2px dashed red; background-color: #ffa;}
.issue .issue {background-color: #fcc;}
.rfc2119 {font-variant:small-caps}
</style> <!--[if lt IE 9]><script src='undefined://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]-->
</head>
<body>
<div class="head"><a href="http://www.w3.org/"><img alt="W3C" src="https://www.w3.org/Icons/w3c_home"
height="48"
width="72"></a>
<h1>W3C Draft Process Document</h1>
<h2 class="notoc">21 January 2015 Editor's Draft</h2>
<dl>
<dt>Latest Editor's version:</dt>
<dd> <a href="https://dvcs.w3.org/hg/AB/raw-file/default/cover.html">https://dvcs.w3.org/hg/AB/raw-file/default/cover.html</a></dd>
<dt>Latest operative version:</dt>
<dd><a href="http://www.w3.org/Consortium/Process/">http://www.w3.org/Consortium/Process/</a></dd>
<dt>Editor:</dt>
<dd>Charles McCathie Nevile, <a style="color:black" href="http://yandex.com"><span
style="color: red;">Y</span>andex</a>—<a
style="color:black"
href="http://yandex.ru"><span
style="color: red;">Я</span>ндекс</a></dd>
<dt>Previous editor:</dt>
<dd>Ian Jacobs, <a href="http://www.w3.org/">W3C</a></dd>
</dl>
<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
© 1996-2015 <a href="/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
(<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
<a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
<a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>),
All Rights Reserved. W3C <a href="/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
<a href="/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>, <a
rel="Copyright"
href="/Consortium/Legal/copyright-documents">document
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 11 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> various small editorial cleanups have been made.
A <a href="#changes">change history</a> (compared to the 2014 Process
Document) forms part of the draft.</p>
<p>During the rest of 2014 the document will be developed in preparation for
adopting a revised process in 2015.</p>
<p>Public 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
+ 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
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
@@ -37,8 +37,8 @@
Committee
meetings</a> [<a href="#ref-ac-meetings">MEM5</a>] is available at the
Member Web site.</p>
<h3 id="Team">2.2 The W3C Team</h3>
<p>The Team consists of the Director, CEO, W3C paid staff, unpaid interns,
and W3C Fellows. <dfn id="fellows">W3C Fellows</dfn> are Member
employees working as part of the Team; see the <a href="http://www.w3.org/Consortium/Recruitment/Fellows">W3C
Fellows Program</a> [<a href="#ref-fellows">PUB32</a>]. The Team
provides technical leadership about Web technologies, organizes and
manages W3C activities to reach goals within practical constraints (such
as resources available), and communicates with the Members and the
public about the Web and W3C technologies.</p>
<p>The Director and CEO <span class="rfc2119">MAY</span> delegate
responsibility (generally to other individuals in the Team) for any of
their roles described in this document.</p>
<p>The <dfn id="def-Director">Director</dfn> is the lead technical
architect at W3C. His responsibilities are identified throughout this
document in relevant places Some key ones include: assessing <a href="#def-Consensus"
id="DirectorDecision">consensus</a>
within W3C for architectural choices, publication of <a href="#Reports">technical
- reports</a>, and new activities; appointing group <a href="#GeneralChairs">Chairs</a>;
"tie-breaker" for <a href="#WGAppeals">appeal of a Working Group
decision</a>; the Director is generally Chair of the <a href="#TAG">TAG</a>.</p>
<p>Team administrative information such as Team salaries, detailed
budgeting, and other business decisions are <a href="#Team-only">Team-only</a>,
subject to oversight by the Host institutions.</p>
<p><strong>Note:</strong> W3C is not currently incorporated. For legal
contracts, W3C is represented by four <dfn id="hosts">"Host"
institutions</dfn>: Beihang University, the European Research
Consortium for Informatics and Mathematics (<abbr>ERCIM</abbr>), Keio
University, and the Massachusetts Institute of Technology (<abbr>MIT</abbr>).
- Within W3C, the Host institutions are governed by joint sponsorship
contracts; the Hosts themselves are not W3C Members.</p>
<h4 id="TeamSubmission">2.2.1 Team Submissions</h4>
<p>Team members <span class="rfc2119">MAY</span> request that the
Director publish information at the W3C Web site. At the Director's
discretion, these documents are published as "Team Submissions". These
documents are analogous to <a href="#Submission">Member Submissions</a>
(e.g., in <a href="#SubmissionScope">expected scope</a>). However,
there is no additional Team comment. The <a href="#DocumentStatus">document
+ reports</a>, and new activities; appointing group <a href="#GeneralChairs">Chairs</a>;
"tie-breaker" for <a href="#WGAppeals">appeal of a Working Group
decision</a> and deciding on the outcome of formal objections; the
Director is generally Chair of the <a href="#TAG">TAG</a>.</p>
<p>Team administrative information such as Team salaries, detailed
budgeting, and other business decisions are <a href="#Team-only">Team-only</a>,
subject to oversight by the Host institutions.</p>
<p><strong>Note:</strong> W3C is not currently incorporated. For legal
contracts, W3C is represented by four <dfn id="hosts">"Host"
institutions</dfn>: Beihang University, the European Research
Consortium for Informatics and Mathematics (<abbr>ERCIM</abbr>), Keio
University, and the Massachusetts Institute of Technology (<abbr>MIT</abbr>).
+ Within W3C, the Host institutions are governed by hosting agreements;
the Hosts themselves are not W3C Members.</p>
<h4 id="TeamSubmission">2.2.1 Team Submissions</h4>
<p>Team members <span class="rfc2119">MAY</span> request that the
Director publish information at the W3C Web site. At the Director's
discretion, these documents are published as "Team Submissions". These
documents are analogous to <a href="#Submission">Member Submissions</a>
(e.g., in <a href="#SubmissionScope">expected scope</a>). However,
there is no additional Team comment. The <a href="#DocumentStatus">document
status section</a> of a Team Submission indicates the level of Team
consensus about the published material.</p>
<p>Team Submissions are <strong>not</strong> part of the <a href="#Reports">technical
report development process</a>.</p>
<p>The list of <a href="http://www.w3.org/TeamSubmission/">published Team
Submissions</a> [<a href="#ref-team-submission-list">PUB16</a>] is
available at the W3C Web site.</p>
<h3 id="AB">2.3 Advisory Board (AB)</h3>
<p>Created in March 1998, the Advisory Board provides ongoing guidance to
the Team on issues of strategy, management, legal matters, process, and
conflict resolution. The Advisory Board also serves the Members by
tracking issues raised between Advisory Committee meetings, soliciting
Member comments on such issues, and proposing actions to resolve these
issues. The Advisory Board manages the <a href="#GAProcess">evolution
of the Process Document</a>. The Advisory Board hears appeals of <a href="#SubmissionNo">Member
Submission requests</a> that are rejected for reasons unrelated to Web
architecture; see also the <a href="#TAG">TAG</a>.</p>
<p>The Advisory Board is <strong>not</strong> a board of directors and
has no decision-making authority within W3C; its role is strictly
advisory.</p>
<p>The Team <span class="rfc2119">MUST</span> make available a mailing
list for the Advisory Board to use for its communication, confidential
to the Advisory Board and Team.</p>
<p>The Advisory Board <span class="rfc2119">SHOULD</span> send a summary
of each of its meetings to the Advisory Committee and other group
Chairs. The Advisory Board <span class="rfc2119">SHOULD</span> also
report on its activities at each <a href="#ACMeetings">Advisory
Committee meeting</a>.</p>
<p>Details about the Advisory Board (e.g., the list of Advisory Board
participants, mailing list information, and summaries of Advisory Board
meetings) are available at the <a href="http://www.w3.org/2002/ab/">Advisory
@@ -132,7 +132,7 @@
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. 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,
and seek evidence of clear communication to the general public about
appropriate times and which content to review. </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 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</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
@@ -152,7 +152,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 any class of mistake, from mere editorial to a
serious error that may affect the conformance with the Recommendation by
software or content (e.g., content validity).</p>
<p>Working Groups <em class="rfc2119">must</em> track errata on an
"errata page." An errata page is a list of enumerated errors, possibly
accompanied by corrections. Each Recommendation links to an errata page;
see the Team's <a href="http://www.w3.org/Guide/pubrules">Publication
Rules</a>.</p>
<p>A correction is first "proposed" by the Working Group. A correction
becomes part of the Recommendation by the process for Revising a
Recommendation described in the next section.</p>
<p>A Working Group <em class="rfc2119">should</em> keep their errata
pages up-to-date, as errors are reported by readers and implementers. A
Working Group <em class="rfc2119">must</em> report errata page changes
to interested parties, notably when corrections are proposed or
incorporated into an Edited Recommendation, according to the Team's
requirements.</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 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>
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
@@ -215,4 +215,4 @@
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
- change logs</a> are available.</p>
<p>The notable changes include:</p>
<h3>Current Editor's draft</h3>
<ul>
<li>Editorial cleanups</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
+ 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