--- a/cover.html Tue Aug 02 16:44:17 2016 +0200
+++ b/cover.html Wed Aug 03 04:52:47 2016 +0200
@@ -107,9 +107,9 @@
[<a href="#ref-member-agreement">PUB6</a>]. The Patent Policy
<a href="https://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>]
is incorporated by normative reference as a part of the Process Document, and is thus equally binding.</p>
- <p>The Patent Policy places additional obligations on Members, Team, and other participants in W3C. The Process Document does not
- restate those requirements but includes references to them. The Process Document and Patent Policy have been designed so that they may
- evolve independently.</p>
+ <p>The Patent Policy places additional obligations on Members, Team, and other participants in W3C.
+ The Process Document does not restate those requirements but includes references to them.
+ The Process Document and Patent Policy have been designed so that they may evolve independently.</p>
<p>In the Process Document, the term "participant" refers to an individual, not an organization.</p>
<h2 class=".notoc">Conformance and specialized terms</h2>
<p>The terms <em class="rfc2119">must</em>, <em class="rfc2119">must not</em>, <em class="rfc2119">should</em>,
@@ -117,9 +117,9 @@
in accordance with <a href="http://www.ietf.org/rfc/rfc2119.txt">RFC 2119</a> [<a href="#ref-RFC2119">RFC2119</a>].
The term <dfn><em class="rfc2119">not required</em></dfn> is equivalent to the term
<em class="rfc2119">may</em> as defined in [<a href="#ref-RFC2119">RFC2119</a>].</p>
- <p>Some terms have been capitalized in this document (and in other W3C materials) to indicate that they are entities with special
- relevance to the W3C Process. These terms are defined herein, and readers should be aware that the ordinary (English) definitions are
- incomplete for purposes of understanding this document.</p>
+ <p>Some terms have been capitalized in this document (and in other W3C materials) to indicate that they are entities
+ with special relevance to the W3C Process. These terms are defined herein, and readers should be aware that the
+ ordinary (English) definitions are incomplete for purposes of understanding this document.</p>
<div class="toc" role="navigation">
<h2 class="notoc" id="toc">Table of Contents</h2>
<div class="noprint">
@@ -325,9 +325,8 @@
<p>Most W3C work revolves around the standardization of Web technologies. To accomplish this work, W3C follows processes that
promote the development of high-quality standards based on the <a href="#Consensus">consensus</a> of the Membership, Team,
- and public. W3C
- processes promote fairness, responsiveness, and progress: all facets of the W3C mission. This document describes the processes W3C
- follows in pursuit of its mission.</p>
+ and public. W3C processes promote fairness, responsiveness, and progress: all facets of the W3C mission.
+ This document describes the processes W3C follows in pursuit of its mission.</p>
<p>Here is a general overview of how W3C standardizes a Web technology. In many cases, the goal of this work is a
<a href="#RecsW3C">W3C Recommendation</a>, the W3C equivalent of a Web standard.</p>
@@ -356,20 +355,24 @@
<p>The Process Document promotes the goals of quality and fairness in technical decisions by encouraging
<a href="#Consensus">consensus</a>, requiring reviews (by both Members and public) as part of the
- <a href="#Reports">technical report development process</a>, and through an <a href="#ACAppeal">Advisory Committee Appeal process</a>.</p>
+ <a href="#Reports">technical report development process</a>, and through an
+ <a href="#ACAppeal">Advisory Committee Appeal process</a>.</p>
<p>The other sections of the Process Document:</p>
<ol>
<li>set forth <a href="#Policies">policies</a> for participation in W3C groups,</li>
<li>establish two permanent groups within W3C: the <a href="#TAG">Technical Architecture Group (TAG)</a>, to help resolve
- Consortium-wide technical issues; and the <a href="#AB">Advisory Board (AB)</a>, to help resolve Consortium-wide non-technical
- issues, and to manage the <a href="#GAProcess">evolution of the W3C process</a>, and</li>
- <li>describe other interactions between the <a href="#Members">Members</a> (as represented by the <a href="#AC">W3C Advisory
- Committee</a>), the Team, and the general public.</li>
+ Consortium-wide technical issues; and the <a href="#AB">Advisory Board (AB)</a>, to help resolve
+ Consortium-wide non-technical issues, and to manage the <a href="#GAProcess">evolution of the W3C process</a>, and</li>
+ <li>describe other interactions between the <a href="#Members">Members</a> (as represented by the
+ <a href="#AC">W3C Advisory Committee</a>), the Team, and the general public.</li>
</ol>
+
<h2 id="Organization">2 Members, Advisory Committee, Team, Advisory Board, Technical Architecture Group</h2>
- <p>W3C's mission is to lead the Web to its full potential. W3C <a href="#Members">Member</a> organizations provide resources to this
- end, and the W3C <a href="#Team">Team</a> provides the technical leadership and organization to coordinate the effort.</p>
+
+ <p>W3C's mission is to lead the Web to its full potential. W3C <a href="#Members">Member</a> organizations
+ provide resources to this end, and the W3C <a href="#Team">Team</a> provides the technical leadership
+ and organization to coordinate the effort.</p>
<h3 id="Members">2.1 Members</h3>
@@ -396,15 +399,18 @@
author and review <a href="#Reports">technical reports</a>.</li>
</ol>
- <p id="MemberSubscription">W3C membership is open to all entities, as described in "<a href="https://www.w3.org/Consortium/join">How to
- Join W3C</a>" [<a href="#ref-join-w3c">PUB5</a>]; (refer to the public list of <a href="https://www.w3.org/Consortium/Member/List">current
- W3C Members</a> [<a href="#ref-current-mem">PUB8</a>]). Organizations subscribe according to the <a href="https://www.w3.org/Consortium/Agreement/Member-Agreement">Membership
- Agreement</a> [<a href="#ref-member-agreement">PUB6</a>]. The <a href="#Team">Team</a> <em class="rfc2119">must</em> ensure that
- Member participation agreements remain <a href="#Team-only">Team-only</a> and that no Member receives preferential treatment within
- W3C.</p>
- <p id="IndividualParticipation">W3C does not have a class of membership tailored to, or priced for individuals. However, an individual
- <em class="rfc2119">may</em> join W3C as an Affiliate Member. In this case the same restrictions pertaining to <a href="#MemberRelated">related
- Members</a> apply when the individual also <a href="#member-rep">represents</a> another W3C Member.</p>
+ <p id="MemberSubscription">W3C membership is open to all entities, as described in
+ "<a href="https://www.w3.org/Consortium/join">How to Join W3C</a>" [<a href="#ref-join-w3c">PUB5</a>];
+ (refer to the public list of <a href="https://www.w3.org/Consortium/Member/List">current W3C Members</a>
+ [<a href="#ref-current-mem">PUB8</a>]). Organizations subscribe according to the
+ <a href="https://www.w3.org/Consortium/Agreement/Member-Agreement">Membership Agreement</a>
+ [<a href="#ref-member-agreement">PUB6</a>]. The <a href="#Team">Team</a> <em class="rfc2119">must</em> ensure that
+ Member participation agreements remain <a href="#Team-only">Team-only</a> and that no Member receives
+ preferential treatment within W3C.</p>
+ <p id="IndividualParticipation">W3C does not have a class of membership tailored to, or priced for individuals.
+ However, an individual <em class="rfc2119">may</em> join W3C as an Affiliate Member. In this case the same
+ restrictions pertaining to <a href="#MemberRelated">related Members</a> apply when the individual also
+ <a href="#member-rep">represents</a> another W3C Member.</p>
<h4 id="MemberBenefits">2.1.1 Rights of Members</h4>
@@ -437,7 +443,9 @@
[<a href="#ref-discipline-gl">MEM14</a>].</p>
<h4 id="RelatedAndConsortiumMembers">2.1.2 Membership Consortia and related Members</h4>
+
<h5 id="MemberConsortia">2.1.2.1 Membership Consortia</h5>
+
<p>If the Member is itself a consortium, user society, or otherwise has members or sponsors, as described in paragraph 5g of
the <a href="https://www.w3.org/Consortium/Agreement/Member-Agreement">Membership Agreement</a> and hereafter called a
"<dfn>Member Consortium</dfn>" the rights and privileges of W3C Membership granted by W3C Process extend to the the
@@ -463,6 +471,7 @@
further IPR commitment is made by the individuals' employers.</p>
<h5 id="MemberRelated">2.1.2.2 Related Members</h5>
+
<p>In the interest of ensuring the integrity of the consensus process, Member involvement in some of the processes in this
document is affected by related Member status. As used herein, two Members are related if:</p>
<ol>
@@ -476,32 +485,38 @@
<a href="https://www.w3.org/Member/Intro">New Member Orientation</a> [<a href="#ref-new-member">MEM4</a>].</p>
<h4 id="AC">2.1.3 Advisory Committee (AC)</h4>
- <p>When an organization joins W3C (see "<a href="https://www.w3.org/Consortium/join">How to Join W3C</a>" [<a href="#ref-join-w3c">PUB5</a>]),
- it <em class="rfc2119">must</em> name its Advisory Committee representative as part of the Membership Agreement. The <a href="https://www.w3.org/Member/Intro">New
- Member Orientation</a> explains how to subscribe or unsubscribe to Advisory Committee mailing lists, provides information about
- Advisory Committee meetings, explains how to name a new Advisory Committee representative, and more. Advisory Committee
- representatives <em class="rfc2119">must</em> follow the <a href="#coi">conflict of interest policy</a> by disclosing information
- according to the mechanisms described in the New Member Orientation. See also the additional roles of Advisory Committee
- representatives described in the <a href="https://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
- <p>Additional information for Members is available at the <a href="https://www.w3.org/Member/">Member Web site</a> [<a href="#ref-member-web">MEM6</a>].</p>
+
+ <p>When an organization joins W3C (see "<a href="https://www.w3.org/Consortium/join">How to Join W3C</a>"
+ [<a href="#ref-join-w3c">PUB5</a>]), it <em class="rfc2119">must</em> name its Advisory Committee representative as part
+ of the Membership Agreement. The <a href="https://www.w3.org/Member/Intro">New Member Orientation</a> explains how to
+ subscribe or unsubscribe to Advisory Committee mailing lists, provides information about Advisory Committee Meetings,
+ explains how to name a new Advisory Committee representative, and more. Advisory Committee representatives
+ <em class="rfc2119">must</em> follow the <a href="#coi">conflict of interest policy</a> by disclosing information
+ according to the mechanisms described in the New Member Orientation. See also the additional roles of
+ Advisory Committee representatives described in the
+ <a href="https://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
+ <p>Additional information for Members is available at the <a href="https://www.w3.org/Member/">Member Web site</a>
+ [<a href="#ref-member-web">MEM6</a>].</p>
+
<h5 id="ACCommunication">2.1.3.1 Advisory Committee Mailing Lists</h5>
<p>The Team <em class="rfc2119">must</em> provide two mailing lists for use by the Advisory Committee:</p>
<ol>
- <li>One for official announcements (e.g., those required by this document) from the Team to the Advisory Committee. This list is
- read-only for Advisory Committee representatives.</li>
+ <li>One for official announcements (e.g., those required by this document) from the Team to the Advisory Committee.
+ This list is read-only for Advisory Committee representatives.</li>
<li>One for discussion among Advisory Committee representatives. Though this list is primarily for Advisory Committee
- representatives, the Team <em class="rfc2119">must</em> monitor discussion and <em class="rfc2119">should</em> participate in
- discussion when appropriate. Ongoing detailed discussions <em class="rfc2119">should</em> be moved to other appropriate lists
- (new or existing, such as a mailing list created for a <a href="#GAEvents">Workshop</a>).</li>
+ representatives, the Team <em class="rfc2119">must</em> monitor discussion and <em class="rfc2119">should</em>
+ participate in discussion when appropriate. Ongoing detailed discussions <em class="rfc2119">should</em> be moved
+ to other appropriate lists (new or existing, such as a mailing list created for a <a href="#GAEvents">Workshop</a>).</li>
</ol>
- <p>An Advisory Committee representative <em class="rfc2119">may</em> request that additional individuals from their organization be
- subscribed to these lists. Failure to contain distribution internally <em class="rfc2119">may</em> result in suspension of
- additional email addresses, at the discretion of the Team.</p>
+ <p>An Advisory Committee representative <em class="rfc2119">may</em> request that additional individuals from their
+ organization be subscribed to these lists. Failure to contain distribution internally <em class="rfc2119">may</em>
+ result in suspension of additional email addresses, at the discretion of the Team.</p>
<h5 id="ACMeetings">2.1.3.2 Advisory Committee Meetings</h5>
- <p>The Team organizes a <a href="#ftf-meeting">face-to-face meeting</a> for the Advisory Committee <span class="time-interval">twice
- a year</span>. The Team appoints the Chair of these meetings (generally the CEO). At each Advisory
- Committee meeting, the Team <em class="rfc2119">should</em> provide an update to the Advisory Committee about:</p>
+ <p>The Team organizes a <a href="#ftf-meeting">face-to-face meeting</a> for the Advisory Committee
+ <span class="time-interval">twice a year</span>. The Team appoints the Chair of these meetings (generally the CEO).
+ At each Advisory Committee meeting, the Team <em class="rfc2119">should</em> provide an update to the
+ Advisory Committee about:</p>
<dl>
<dt><em>Resources</em></dt>
<dd>
@@ -514,28 +529,33 @@
<dd>
<ul>
<li>The allocation of the annual budget, including size of the Team and their approximate deployment.</li>
- <li>A list of all activities (including but not limited to Working and Interest Groups) and brief status statement about each,
- in particular those started or terminated since the previous Advisory Committee meeting.</li>
+ <li>A list of all activities (including but not limited to Working and Interest Groups) and brief status statement
+ about each, in particular those started or terminated since the previous Advisory Committee meeting.</li>
<li>The allocation of resources to pursuing <a href="#Liaisons">liaisons</a> with other organizations.</li>
</ul>
</dd>
</dl>
- <p>Each Member organization <em class="rfc2119">should</em> send one <a href="#member-rep">representative</a> to each Advisory
- Committee Meeting. In exceptional circumstances (e.g., during a period of transition between representatives from an organization),
+ <p>Each Member organization <em class="rfc2119">should</em> send one <a href="#member-rep">representative</a> to each
+ Advisory Committee Meeting. In exceptional circumstances (e.g., during a period of transition between representatives
+ from an organization),
the meeting Chair <em class="rfc2119">may</em> allow a Member organization to send two representatives to a meeting.</p>
- <p>The Team <em class="rfc2119">must</em> announce the date and location of each Advisory Committee meeting no later than at the end
- of the previous meeting; <span class="time-interval">one year's</span> notice is preferred. The Team <em class="rfc2119">must</em>
+ <p>The Team <em class="rfc2119">must</em> announce the date and location of each Advisory Committee meeting no later than
+ at the end of the previous meeting; <span class="time-interval">one year's</span> notice is preferred. The Team
+ <em class="rfc2119">must</em>
announce the region of each Advisory Committee meeting at least <span class="time-interval">one year</span> in advance.</p>
- <p>More information about <a href="https://www.w3.org/Member/Meeting/">Advisory Committee meetings</a> [<a href="#ref-ac-meetings">MEM5</a>]
- is available at the Member Web site.</p>
+ <p>More information about <a href="https://www.w3.org/Member/Meeting/">Advisory 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="https://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 <em class="rfc2119">may</em> delegate responsibility (generally to other individuals in the Team) for any of
- their roles described in this document.</p>
+
+ <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="https://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 <em class="rfc2119">may</em> 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
@@ -544,20 +564,24 @@
adjudicating as "tie-breaker" for <a href="#WGAppeals">Group decision appeals</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>
+ <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 <em class="rfc2119">may</em> 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 members <em class="rfc2119">may</em> 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="https://www.w3.org/TeamSubmission/">published Team Submissions</a> [<a href="#ref-team-submission-list">PUB16</a>]
- is available at the W3C Web site.</p>
+ <p>The list of <a href="https://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>
@@ -568,29 +592,35 @@
a <a href="#SubmissionNo">Submission Appeal</a> when a Member Submission is 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 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 <em class="rfc2119">must</em> 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 <em class="rfc2119">should</em> send a summary of each of its meetings to the Advisory Committee and other
- group Chairs. The Advisory Board <em class="rfc2119">should</em> 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="https://www.w3.org/2002/ab/">Advisory Board home page</a> [<a href="#ref-ab-home">PUB30</a>].</p>
+ <p>The Advisory Board <em class="rfc2119">should</em> send a summary of each of its meetings to the Advisory Committee
+ and other group Chairs. The Advisory Board <em class="rfc2119">should</em> 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="https://www.w3.org/2002/ab/">Advisory Board home page</a> [<a href="#ref-ab-home">PUB30</a>].</p>
+
<h4 id="ABParticipation">2.3.1 Advisory Board Participation</h4>
- <p>The Advisory Board consists of nine elected participants and a Chair. The Team appoints the Chair of the <a href="#AB">Advisory
- Board</a>, who is generally the CEO.</p>
- <p>The remaining nine Advisory Board participants are elected by the W3C Advisory Committee following the <a href="#AB-TAG-elections">AB/TAG
- nomination and election process</a>.</p>
- <p>With the exception of the Chair, the terms of all Advisory Board participants are for <span class="time-interval">two years</span>.
- Terms are staggered so that each year, either four or five terms expire. If an individual is elected to fill an incomplete term,
- that individual's term ends at the normal expiration date of that term. Regular Advisory Board terms begin on 1 July and end on 30
- June.</p>
+
+ <p>The Advisory Board consists of nine elected participants and a Chair. The Team appoints the Chair of the
+ <a href="#AB">Advisory Board</a>, who is generally the CEO.</p>
+ <p>The remaining nine Advisory Board participants are elected by the W3C Advisory Committee following the
+ <a href="#AB-TAG-elections">AB/TAG nomination and election process</a>.</p>
+ <p>With the exception of the Chair, the terms of all Advisory Board participants are for
+ <span class="time-interval">two years</span>. Terms are staggered so that each year, either four or five terms expire.
+ If an individual is elected to fill an incomplete term, that individual's term ends at the normal expiration date of
+ that term. Regular Advisory Board terms begin on 1 July and end on 30 June.</p>
+
<h3 id="TAG">2.4 Technical Architecture Group (TAG)</h3>
- <p>Created in February 2001, the mission of the TAG is stewardship of the Web architecture. There are three aspects to this mission:</p>
+
+ <p>Created in February 2001, the mission of the TAG is stewardship of the Web architecture. There are three aspects to
+ this mission:</p>
<ol>
- <li>to document and build consensus around principles of Web architecture and to interpret and clarify these principles when
- necessary;</li>
+ <li>to document and build consensus around principles of Web architecture and to interpret and clarify these
+ principles when necessary;</li>
<li>to resolve issues involving general Web architecture brought to the TAG;</li>
<li>to help coordinate cross-technology architecture developments inside and outside W3C.</li>
</ol>
@@ -598,67 +628,79 @@
<p>The TAG hears a <a href="#SubmissionNo">Submission Appeal</a> when a Member Submission is rejected for reasons related
to Web architecture; see also the <a href="#AB">Advisory Board</a>.</p>
- <p>The TAG's scope is limited to technical issues about Web architecture. The TAG <em class="rfc2119">should not</em> consider
- administrative, process, or organizational policy issues of W3C, which are generally addressed by the W3C Advisory Committee,
- Advisory Board, and Team. Please refer to the <a href="https://www.w3.org/2004/10/27-tag">TAG charter</a> [<a href="#ref-tag-charter">PUB25</a>]
+ <p>The TAG's scope is limited to technical issues about Web architecture. The TAG <em class="rfc2119">should not</em>
+ consider administrative, process, or organizational policy issues of W3C, which are generally addressed by the
+ W3C Advisory Committee, Advisory Board, and Team. Please refer to the
+ <a href="https://www.w3.org/2004/10/27-tag">TAG charter</a> [<a href="#ref-tag-charter">PUB25</a>]
for more information about the background and scope of the TAG, and the expected qualifications of TAG participants.</p>
<p>The Team <em class="rfc2119">must</em> make available two mailing lists for the TAG:</p>
<ul>
- <li>a public discussion (not just input) list for issues of Web architecture. The TAG will conduct its public business on this list.</li>
- <li>a <a href="#Member-only">Member-only</a> list for discussions within the TAG and for requests to the TAG that, for whatever
- reason, cannot be made on the public list.</li>
+ <li>a public discussion (not just input) list for issues of Web architecture. The TAG will conduct its public business
+ on this list.</li>
+ <li>a <a href="#Member-only">Member-only</a> list for discussions within the TAG and for requests to the TAG that,
+ for whatever reason, cannot be made on the public list.</li>
</ul>
<p>The TAG <em class="rfc2119">may</em> also request the creation of additional topic-specific, public mailing lists.
For some TAG discussions (e.g., a <a href="#SubmissionNo">Submission Appeal</a>), the TAG <em class="rfc2119">may</em>
use a list that will be <a href="#Member-only">Member-only</a>.</p>
- <p>The TAG <em class="rfc2119">should</em> send a summary of each of its <a href="#GeneralMeetings">meetings</a> to the Advisory
- Committee and other group Chairs. The TAG <em class="rfc2119">should</em> also report on its activities at each <a href="#ACMeetings">Advisory
- Committee meeting</a>.</p>
- <p>When the TAG votes to resolve an issue, each TAG participant (whether appointed, elected, or the Chair) has one vote; see also the
- section on <a href="https://www.w3.org/2004/10/27-tag#Voting">voting in the TAG charter</a> [<a href="#ref-tag-charter">PUB25</a>]
- and the general section on <a href="#Votes">votes</a> in this Process Document.</p>
- <p>Details about the TAG (e.g., the list of TAG participants, mailing list information, and summaries of TAG meetings) are available
- at the <a href="https://www.w3.org/2001/tag/">TAG home page</a> [<a href="#ref-tag-home">PUB26</a>].</p>
+ <p>The TAG <em class="rfc2119">should</em> send a summary of each of its <a href="#GeneralMeetings">meetings</a> to the
+ Advisory Committee and other group Chairs. The TAG <em class="rfc2119">should</em> also report on its activities at each
+ <a href="#ACMeetings">Advisory Committee meeting</a>.</p>
+ <p>When the TAG votes to resolve an issue, each TAG participant (whether appointed, elected, or the Chair) has one vote;
+ see also the section on <a href="https://www.w3.org/2004/10/27-tag#Voting">voting in the TAG charter</a>
+ [<a href="#ref-tag-charter">PUB25</a>] and the general section on <a href="#Votes">votes</a> in this Process Document.</p>
+ <p>Details about the TAG (e.g., the list of TAG participants, mailing list information, and summaries of TAG meetings)
+ are available at the <a href="https://www.w3.org/2001/tag/">TAG home page</a> [<a href="#ref-tag-home">PUB26</a>].</p>
+
<h4 id="tag-participation">2.4.1 Technical Architecture Group Participation</h4>
- <p>The TAG consists of eight elected or appointed participants and a Chair. The Team appoints the Chair of the TAG, who is generally
- the <a href="#def-Director">Director</a>.</p>
- <p>Three TAG participants are appointed by the Director. Appointees are <em class="rfc2119">not required</em> to be on the W3C Team.
- The Director <em class="rfc2119">may</em> appoint <a href="#fellows">W3C Fellows</a> to the TAG.</p>
- <p>The remaining five TAG participants are elected by the W3C Advisory Committee following the <a href="#AB-TAG-elections">AB/TAG
- nomination and election process</a>.</p>
- <p>With the exception of the Chair, the terms of all TAG participants are for <span class="time-interval">two years</span>. Terms are
- staggered so that each year, either two or three elected terms, and either one or two appointed terms expire. If an individual is
- appointed or elected to fill an incomplete term, that individual's term ends at the normal expiration date of that term. Regular TAG
- terms begin on 1 February and end on 31 January.</p>
+
+ <p>The TAG consists of eight elected or appointed participants and a Chair. The Team appoints the Chair of the TAG,
+ who is generally the <a href="#def-Director">Director</a>.</p>
+ <p>Three TAG participants are appointed by the Director. Appointees are <em class="rfc2119">not required</em> to be
+ on the W3C Team. The Director <em class="rfc2119">may</em> appoint <a href="#fellows">W3C Fellows</a> to the TAG.</p>
+ <p>The remaining five TAG participants are elected by the W3C Advisory Committee following the
+ <a href="#AB-TAG-elections">AB/TAG nomination and election process</a>.</p>
+ <p>With the exception of the Chair, the terms of all TAG participants are for <span class="time-interval">two years</span>.
+ Terms are staggered so that each year, either two or three elected terms, and either one or two appointed terms expire.
+ If an individual is appointed or elected to fill an incomplete term, that individual's term ends at the normal
+ expiration date of that term. Regular TAG terms begin on 1 February and end on 31 January.</p>
+
<h3 id="AB-TAG-participation">2.5 Advisory Board and Technical Architecture Group Participation</h3>
- <p>Advisory Board and TAG participants have a special role within W3C: they are elected by the Membership and appointed by the
- Director with the expectation that they will use their best judgment to find the best solutions for the Web, not just for any
- particular network, technology, vendor, or user. Advisory Board and TAG participants are expected to participate regularly and
- fully. Advisory Board and TAG participants <em class="rfc2119">should</em> attend <a href="#ACMeetings">Advisory Committee
- meetings</a>.</p>
- <p>An individual participates on the Advisory Board or TAG from the moment the individual's term begins until the term ends or the
- seat is <a href="#AB-TAG-vacated">vacated</a>. Although Advisory Board and TAG participants do not advocate for the commercial
- interests of their employers, their participation does carry the responsibilities associated with Member representation, Invited
- Expert status, or Team representation (as described in the section on the <a href="#AB-TAG-elections">AB/TAG nomination and
- election process</a>). See also the licensing obligations on TAG participants in <a href="https://www.w3.org/Consortium/Patent-Policy#sec-Obligations">section
- 3</a> of the <a href="https://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>],
+
+ <p>Advisory Board and TAG participants have a special role within W3C: they are elected by the Membership and
+ appointed by the Director with the expectation that they will use their best judgment to find the best solutions
+ for the Web, not just for any particular network, technology, vendor, or user. Advisory Board and TAG participants
+ are expected to participate regularly and fully. Advisory Board and TAG participants <em class="rfc2119">should</em>
+ attend <a href="#ACMeetings">Advisory Committee meetings</a>.</p>
+ <p>An individual participates on the Advisory Board or TAG from the moment the individual's term begins until the term ends
+ or the seat is <a href="#AB-TAG-vacated">vacated</a>. Although Advisory Board and TAG participants do not advocate for
+ the commercial interests of their employers, their participation does carry the responsibilities associated with
+ Member representation, Invited Expert status, or Team representation (as described in the section on the
+ <a href="#AB-TAG-elections">AB/TAG nomination and election process</a>). See also the licensing obligations on
+ TAG participants in <a href="https://www.w3.org/Consortium/Patent-Policy#sec-Obligations">section 3</a> of the
+ <a href="https://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>],
and the claim exclusion process of <a href="https://www.w3.org/Consortium/Patent-Policy#sec-Exclusion">section 4</a>.</p>
+
<h4 id="AB-TAG-constraints">2.5.1 Advisory Board and Technical Architecture Group Participation Constraints</h4>
- <p>Given the few seats available on the Advisory Board and the TAG, and in order to ensure that the diversity of W3C Members is
- represented:</p>
+
+ <p>Given the few seats available on the Advisory Board and the TAG, and in order to ensure that the diversity of
+ W3C Members is represented:</p>
<ul>
- <li>A Member organization is permitted at most one participant on the TAG except when having more than one participant is caused by
- a change of affiliation of an existing participant. At the completion of the next regularly scheduled election for the TAG, the
- Member organization <em class="rfc2119">must</em> have returned to having at most one participant.</li>
+ <li>A Member organization is permitted at most one participant on the TAG except when having more than one participant
+ is caused by a change of affiliation of an existing participant. At the completion of the next regularly scheduled
+ election for the TAG, the Member organization <em class="rfc2119">must</em> have returned to having at most
+ one participant.</li>
<li>A Member organization is permitted at most one participant on the AB.</li>
<li>An individual <em class="rfc2119">must not</em> participate on both the TAG and the AB.</li>
</ul>
- <p>If, for whatever reason, these constraints are not satisfied (e.g., because an AB participant changes jobs), one participant <em class="rfc2119">must</em>
- cease AB participation until the situation has been resolved. If after <span class="time-interval">30 days</span> the situation has
- not been resolved, the Chair will declare one participant's seat to be vacant. When more than one individual is involved, the <a href="#random">verifiable
- random selection procedure</a> described below will be used to choose one person for continued participation.</p>
+ <p>If, for whatever reason, these constraints are not satisfied (e.g., because an AB participant changes jobs),
+ one participant <em class="rfc2119">must</em> cease AB participation until the situation has been resolved. If after
+ <span class="time-interval">30 days</span> the situation has not been resolved, the Chair will declare one participant's
+ seat to be vacant. When more than one individual is involved, the
+ <a href="#random">verifiable random selection procedure</a> described below will be used to choose one person for
+ continued participation.</p>
<h4 id="AB-TAG-elections">2.5.2 Advisory Board and Technical Architecture Group Elections</h4>
@@ -711,98 +753,119 @@
[<a href="#ref-election-howto">MEM15</a>] for more details.</p>
<h5 id="random">2.5.2.1 Verifiable Random Selection Procedure</h5>
- <p>When it is necessary to use a verifiable random selection process (e.g., in an AB or TAG election, to "draw straws" in case of a
- tie or to fill a short term), W3C uses the random and verifiable procedure defined in <a href="http://www.ietf.org/rfc/rfc2777.txt">RFC
- 2777</a> [<a href="#ref-RFC2777">RFC2777</a>]. The procedure orders an input list of names (listed in alphabetical order by family
- name unless otherwise specified) into a "result order."</p>
+ <p>When it is necessary to use a verifiable random selection process (e.g., in an AB or TAG election, to "draw straws"
+ in case of a tie or to fill a short term), W3C uses the random and verifiable procedure defined in
+ <a href="http://www.ietf.org/rfc/rfc2777.txt">RFC 2777</a> [<a href="#ref-RFC2777">RFC2777</a>]. The procedure orders
+ an input list of names (listed in alphabetical order by family name unless otherwise specified) into a "result order."</p>
<p>W3C applies this procedure as follows:</p>
<ol>
- <li>When N people have tied for M (less than N) seats. In this case, only the names of the N individuals who tied are provided as
- input to the procedure. The M seats are assigned in result order.</li>
- <li>After all elected individuals have been identified, when N people are eligible for M (less than N) short terms. In this case,
- only the names of those N individuals are provided as input to the procedure. The short terms are assigned in result order.</li>
+ <li>When N people have tied for M (less than N) seats. In this case, only the names of the N individuals who tied
+ are provided as input to the procedure. The M seats are assigned in result order.</li>
+ <li>After all elected individuals have been identified, when N people are eligible for M (less than N) short terms.
+ In this case, only the names of those N individuals are provided as input to the procedure. The short terms are assigned
+ in result order.</li>
</ol>
+
<h4 id="AB-TAG-vacated">2.5.3 Advisory Board and Technical Architecture Group Vacated Seats</h4>
+
<p>An Advisory Board or TAG participant's seat is vacated when either of the following occurs:</p>
<ul>
<li>the participant <a href="#resignation">resigns</a>, or</li>
<li>the Chair asks the participant to <a href="#resignation">resign</a>.</li>
</ul>
- <p>When an Advisory Board or TAG participant changes affiliations, as long as <a href="#AB-TAG-constraints">Advisory Board and TAG
- participation constraints</a> are respected, the individual <em class="rfc2119">may</em> continue to participate until the next
- regularly scheduled election for that group. Otherwise, the seat is vacated.</p>
+ <p>When an Advisory Board or TAG participant changes affiliations, as long as
+ <a href="#AB-TAG-constraints">Advisory Board and TAG participation constraints</a> are respected, the individual
+ <em class="rfc2119">may</em> continue to participate until the next regularly scheduled election for that group.
+ Otherwise, the seat is vacated.</p>
<p>Vacated seats are filled according to this schedule:</p>
<ul>
- <li>When an appointed TAG seat is vacated, the Director <em class="rfc2119">may</em> re-appoint someone immediately, but no later
- than the next regularly scheduled election.</li>
- <li>When an elected seat on either the AB or TAG is vacated, the seat is filled at the next regularly scheduled election for the
- group unless the group Chair requests that W3C hold an election before then (for instance, due to the group's workload). The group
- Chair <em class="rfc2119">should not</em> request an exceptional election if the next regularly scheduled election is fewer than
- three months away.</li>
+ <li>When an appointed TAG seat is vacated, the Director <em class="rfc2119">may</em> re-appoint someone immediately,
+ but no later than the next regularly scheduled election.</li>
+ <li>When an elected seat on either the AB or TAG is vacated, the seat is filled at the next regularly scheduled election
+ for the group unless the group Chair requests that W3C hold an election before then (for instance,
+ due to the group's workload). The group Chair <em class="rfc2119">should not</em> request an exceptional election
+ if the next regularly scheduled election is fewer than three months away.</li>
</ul>
+
<h2 id="Policies">3 General Policies for W3C Groups</h2>
- <p>This section describes general policies for W3C groups regarding participation, meeting requirements, and decision-making. These
- policies apply to <span id="participant">participants</span> in the following groups: <a href="#AC">Advisory Committee</a>, <a href="#ABParticipation">Advisory
- Board</a>, <a href="#tag-participation">TAG</a>, <a href="#wgparticipant">Working Groups</a>, and <a href="#igparticipant">Interest
- Groups</a>.</p>
+
+ <p>This section describes general policies for W3C groups regarding participation, meeting requirements, and decision-making.
+ These policies apply to <span id="participant">participants</span> in the following groups:
+ <a href="#AC">Advisory Committee</a>, <a href="#ABParticipation">Advisory Board</a>, <a href="#tag-participation">TAG</a>,
+ <a href="#wgparticipant">Working Groups</a>, and <a href="#igparticipant">Interest Groups</a>.</p>
+
<h3 id="ParticipationCriteria">3.1 Individual Participation Criteria</h3>
+
<p>There are three qualities an individual is expected to demonstrate in order to participate in W3C:</p>
<ol>
<li>Technical competence in one's role</li>
<li>The ability to act fairly</li>
<li>Social competence in one's role</li>
</ol>
- <p>Advisory Committee representatives who nominate individuals from their organization for participation in W3C activities are
- responsible for assessing and attesting to the qualities of those nominees.</p>
- <p>See also the participation requirements described in <a href="https://www.w3.org/Consortium/Patent-Policy#sec-Disclosure">section 6</a>
- of the <a href="https://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
+ <p>Advisory Committee representatives who nominate individuals from their organization for participation in W3C activities
+ are responsible for assessing and attesting to the qualities of those nominees.</p>
+ <p>See also the participation requirements described in
+ <a href="https://www.w3.org/Consortium/Patent-Policy#sec-Disclosure">section 6</a> of the
+ <a href="https://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
+
<h4 id="coi">3.1.1 Conflict of Interest Policy</h4>
- <p>Individuals participating materially in W3C work <em class="rfc2119">must</em> disclose significant relationships when those
- relationships might reasonably be perceived as creating a conflict of interest with the individual's role at W3C. These disclosures
- <em class="rfc2119">must</em> be kept up-to-date as the individual's affiliations change and W3C membership evolves (since, for
- example, the individual might have a relationship with an organization that joins or leaves W3C). Each section in this document that
- describes a W3C group provides more detail about the disclosure mechanisms for that group.</p>
- <p>The ability of an individual to fulfill a role within a group without risking a conflict of interest is clearly a function of the
- individual's affiliations. When these affiliations change, the individual's assignment to the role <em class="rfc2119">must</em> be
- evaluated. The role <em class="rfc2119">may</em> be reassigned according to the appropriate process. For instance, the Director <em
- class="rfc2119">may</em> appoint a new group Chair when the current Chair changes affiliations (e.g., if there is a risk of
- conflict of interest, or if there is risk that the Chair's new employer will be over-represented within a W3C activity).</p>
+
+ <p>Individuals participating materially in W3C work <em class="rfc2119">must</em> disclose significant relationships when
+ those relationships might reasonably be perceived as creating a conflict of interest with the individual's role at W3C.
+ These disclosures <em class="rfc2119">must</em> be kept up-to-date as the individual's affiliations change and
+ W3C membership evolves (since, for example, the individual might have a relationship with an organization that joins or
+ leaves W3C). Each section in this document that describes a W3C group provides more detail about the disclosure mechanisms
+ for that group.</p>
+ <p>The ability of an individual to fulfill a role within a group without risking a conflict of interest is clearly a
+ function of the individual's affiliations. When these affiliations change, the individual's assignment to the role
+ <em class="rfc2119">must</em> be evaluated. The role <em class="rfc2119">may</em> be reassigned according to the
+ appropriate process. For instance, the Director <em class="rfc2119">may</em> appoint a new group Chair when the
+ current Chair changes affiliations (e.g., if there is a risk of conflict of interest, or if there is risk that the
+ Chair's new employer will be over-represented within a W3C activity).</p>
<p>The following are some scenarios where disclosure is appropriate:</p>
<ul>
- <li>Paid consulting for an organization whose activity is relevant to W3C, or any consulting compensated with equity (shares of
- stock, stock options, or other forms of corporate equity).</li>
+ <li>Paid consulting for an organization whose activity is relevant to W3C, or any consulting compensated with
+ equity (shares of stock, stock options, or other forms of corporate equity).</li>
<li>A decision-making role/responsibility (such as participating on the Board) in other organizations relevant to W3C.</li>
<li>A position on a publicly visible advisory body, even if no decision making authority is involved.</li>
</ul>
<p>Individuals seeking assistance on these matters <em class="rfc2119">should</em> contact the Team.</p>
- <p>Team members are subject to the <a href="https://www.w3.org/2000/09/06-conflictpolicy">W3C Team conflict of interest policy</a> [<a
- href="#ref-coi">PUB23</a>].</p>
+ <p>Team members are subject to the
+ <a href="https://www.w3.org/2000/09/06-conflictpolicy">W3C Team conflict of interest policy</a>
+ [<a href="#ref-coi">PUB23</a>].</p>
+
<h4 id="member-rep">3.1.2 Individuals Representing a Member Organization</h4>
- <p>Generally, individuals representing a Member in an official capacity within W3C are employees of the Member organization. However,
- an Advisory Committee representative <em class="rfc2119">may</em> designate a non-employee to represent the Member. Non-employee
- Member representatives <em class="rfc2119">must</em> disclose relevant affiliations to the Team and to any group in which the
- individual participates.</p>
- <p>In exceptional circumstances (e.g., situations that might jeopardize the progress of a group or create a <a href="#coi">conflict
- of interest</a>), the <a href="#def-Director">Director</a> <em class="rfc2119">may</em> decline to allow an individual
- designated by an Advisory Committee representative to participate in a group.</p>
- <p>A group charter <em class="rfc2119">may</em> limit the number of individuals representing a W3C Member (or group of <a href="#MemberRelated">related
- Members</a>).</p>
+
+ <p>Generally, individuals representing a Member in an official capacity within W3C are employees of the Member organization.
+ However, an Advisory Committee representative <em class="rfc2119">may</em> designate a non-employee to represent the
+ Member. Non-employee Member representatives <em class="rfc2119">must</em> disclose relevant affiliations to the Team and
+ to any group in which the individual participates.</p>
+ <p>In exceptional circumstances (e.g., situations that might jeopardize the progress of a group or create a
+ <a href="#coi">conflict of interest</a>), the <a href="#def-Director">Director</a> <em class="rfc2119">may</em>
+ decline to allow an individual designated by an Advisory Committee representative to participate in a group.</p>
+ <p>A group charter <em class="rfc2119">may</em> limit the number of individuals representing a W3C Member (or group of
+ <a href="#MemberRelated">related Members</a>).</p>
+
<h3 id="GeneralMeetings">3.2 Meetings</h3>
- <p>W3C groups (including the <a href="#ACMeetings">Advisory Committee</a>, <a href="#AB">Advisory Board</a>, <a href="#TAG">TAG</a>,
- and <a href="#GroupsWG">Working Groups</a>) <em class="rfc2119">should</em> observe the meeting requirements in this section.</p>
+
+ <p>W3C groups (including the <a href="#ACMeetings">Advisory Committee</a>, <a href="#AB">Advisory Board</a>,
+ <a href="#TAG">TAG</a>, and <a href="#GroupsWG">Working Groups</a>) <em class="rfc2119">should</em> observe the
+ meeting requirements in this section.</p>
<p>W3C distinguishes two types of meetings:</p>
<ol>
- <li>A <dfn id="ftf-meeting">face-to-face meeting</dfn> is one where most of the attendees are expected to participate in the same
- physical location.</li>
- <li>A <dfn id="distributed-meeting">distributed meeting</dfn> is one where most of the attendees are expected to participate from
- remote locations (e.g., by telephone, video conferencing, or <abbr title="Internet Relay Chat">IRC</abbr>).</li>
+ <li>A <dfn id="ftf-meeting">face-to-face meeting</dfn> is one where most of the attendees are expected to
+ participate in the same physical location.</li>
+ <li>A <dfn id="distributed-meeting">distributed meeting</dfn> is one where most of the attendees are expected
+ to participate from remote locations (e.g., by telephone, video conferencing, or
+ <abbr title="Internet Relay Chat">IRC</abbr>).</li>
</ol>
- <p>A Chair <em class="rfc2119">may</em> invite an individual with a particular expertise to attend a meeting on an exceptional basis.
- This person is a meeting guest, not a group <a href="#participant">participant</a>. Meeting guests do not have <a href="#Votes">voting
- rights</a>. It is the responsibility of the Chair to ensure that all meeting guests respect the chartered <a href="#confidentiality-levels">level
- of confidentiality</a> and other group requirements.</p>
- <p>Meeting announcements <em class="rfc2119">should</em> be sent to all appropriate group mailing lists, i.e., those most relevant to
- the anticipated meeting participants.</p>
+ <p>A Chair <em class="rfc2119">may</em> invite an individual with a particular expertise to attend a meeting on
+ an exceptional basis. This person is a meeting guest, not a group <a href="#participant">participant</a>. Meeting guests
+ do not have <a href="#Votes">voting rights</a>. It is the responsibility of the Chair to ensure that all meeting guests
+ respect the chartered <a href="#confidentiality-levels">level of confidentiality</a> and other group requirements.</p>
+
+ <p>Meeting announcements <em class="rfc2119">should</em> be sent to all appropriate group mailing lists, i.e., those most
+ relevant to the anticipated meeting participants.</p>
<p>The following table lists requirements for organizing a meeting:</p>
<table border="1">
<tbody>
@@ -839,96 +902,119 @@
</tr>
</tbody>
</table>
- <p><sup>*</sup> To allow proper planning (e.g., travel arrangements), the Chair is responsible for giving sufficient advance notice
- about the date and location of a meeting. Shorter notice for a meeting is allowed provided that there are no objections from group
- participants.</p>
+ <p><sup>*</sup> To allow proper planning (e.g., travel arrangements), the Chair is responsible for giving sufficient
+ advance notice about the date and location of a meeting. Shorter notice for a meeting is allowed provided that there
+ are no objections from group participants.</p>
+
<h3 id="Consensus">3.3 Consensus</h3>
- <p>Consensus is a core value of W3C. To promote consensus, the W3C process requires Chairs to ensure that groups consider all
- legitimate views and objections, and endeavor to resolve them, whether these views and objections are expressed by the active
- participants of the group or by others (e.g., another W3C group, a group in another organization, or the general public). Decisions
- <em class="rfc2119">may</em> be made during meetings (<a href="#ftf-meeting">face-to-face</a> or <a href="#distributed-meeting">distributed</a>)
- as well as through email. <strong>Note:</strong> The Director, CEO, and COO have the role of assessing consensus within the
- Advisory Committee.</p>
- <p>The following terms are used in this document to describe the level of support for a decision among a set of eligible individuals:</p>
+
+ <p>Consensus is a core value of W3C. To promote consensus, the W3C process requires Chairs to ensure that groups consider
+ all legitimate views and objections, and endeavor to resolve them, whether these views and objections are expressed by
+ the active participants of the group or by others (e.g., another W3C group, a group in another organization, or the
+ general public). Decisions <em class="rfc2119">may</em> be made during meetings (<a href="#ftf-meeting">face-to-face</a>
+ or <a href="#distributed-meeting">distributed</a>) as well as through email. <strong>Note:</strong> The Director, CEO,
+ and COO have the role of assessing consensus within the Advisory Committee.</p>
+ <p>The following terms are used in this document to describe the level of support for a decision among a set of eligible
+ individuals:</p>
<ol>
- <li><dfn id="def-Consensus">Consensus</dfn>: A substantial number of individuals in the set support the decision and nobody in the
- set registers a <a href="#FormalObjection">Formal Objection</a>. Individuals in the set may abstain. Abstention is either an
- explicit expression of no opinion or silence by an individual in the set. <dfn id="def-Unanimity">Unanimity</dfn> is the
- particular case of consensus where all individuals in the set support the decision (i.e., no individual in the set abstains).</li>
- <li><dfn id="def-Dissent">Dissent</dfn>: At least one individual in the set registers a <a href="#FormalObjection">Formal Objection</a>.</li>
+ <li><dfn id="def-Consensus">Consensus</dfn>: A substantial number of individuals in the set support the decision and
+ nobody in the set registers a <a href="#FormalObjection">Formal Objection</a>. Individuals in the set may abstain.
+ Abstention is either an explicit expression of no opinion or silence by an individual in the set.
+ <dfn id="def-Unanimity">Unanimity</dfn> is the particular case of consensus where all individuals in the set support
+ the decision (i.e., no individual in the set abstains).</li>
+ <li><dfn id="def-Dissent">Dissent</dfn>: At least one individual in the set registers a
+ <a href="#FormalObjection">Formal Objection</a>.</li>
</ol>
- <p>By default, the set of individuals eligible to participate in a decision is the set of group participants. The Process Document
- does not require a quorum for decisions (i.e., the minimal number of eligible participants required to be present before the Chair
- can call a question). A charter <em class="rfc2119">may</em> include a quorum requirement for consensus decisions.</p>
- <p>Where unanimity is not possible, a group <em class="rfc2119">should</em> strive to make consensus decisions where there is
- significant support and few abstentions. The Process Document does not require a particular percentage of eligible participants to
- agree to a motion in order for a decision to be made. To avoid decisions where there is widespread apathy, (i.e., little support and
- many abstentions), groups <em class="rfc2119">should</em> set minimum thresholds of active support before a decision can be
- recorded. The appropriate percentage <em class="rfc2119">may</em> vary depending on the size of the group and the nature of the
- decision. A charter <em class="rfc2119">may</em> include threshold requirements for consensus decisions. For instance, a charter
- might require a supermajority of eligible participants (i.e., some established percentage above 50%) to support certain types of
- consensus decisions.</p>
+ <p>By default, the set of individuals eligible to participate in a decision is the set of group participants. The
+ Process Document does not require a quorum for decisions (i.e., the minimal number of eligible participants required
+ to be present before the Chair can call a question). A charter <em class="rfc2119">may</em> include a
+ quorum requirement for consensus decisions.</p>
+ <p>Where unanimity is not possible, a group <em class="rfc2119">should</em> strive to make consensus decisions where
+ there is significant support and few abstentions. The Process Document does not require a particular percentage of
+ eligible participants to agree to a motion in order for a decision to be made. To avoid decisions where there is
+ widespread apathy, (i.e., little support and many abstentions), groups <em class="rfc2119">should</em> set
+ minimum thresholds of active support before a decision can be recorded. The appropriate percentage
+ <em class="rfc2119">may</em> vary depending on the size of the group and the nature of the decision. A charter
+ <em class="rfc2119">may</em> include threshold requirements for consensus decisions. For instance, a charter
+ might require a supermajority of eligible participants (i.e., some established percentage above 50%) to support
+ certain types of consensus decisions.</p>
+
<h4 id="managing-dissent">3.3.1 Managing Dissent</h4>
- <p>In some cases, even after careful consideration of all points of view, a group might find itself unable to reach consensus. The
- Chair <em class="rfc2119">may</em> record a decision where there is dissent (i.e., there is at least one <a href="#FormalObjection">Formal
- Objection</a>) so that the group may make progress (for example, to produce a deliverable in a timely manner). Dissenters cannot
- stop a group's work simply by saying that they cannot live with a decision. When the Chair believes that the Group has duly
- considered the legitimate concerns of dissenters as far as is possible and reasonable, the group <em class="rfc2119">should</em>
- move on.</p>
- <p>Groups <em class="rfc2119">should</em> favor proposals that create the weakest objections. This is preferred over proposals that
- are supported by a large majority but that cause strong objections from a few people. As part of making a decision where there is
- dissent, the Chair is expected to be aware of which participants work for the same (or <a href="#MemberRelated">related</a>) Member
- organizations and weigh their input accordingly.</p>
+
+ <p>In some cases, even after careful consideration of all points of view, a group might find itself unable to reach
+ consensus. The Chair <em class="rfc2119">may</em> record a decision where there is dissent (i.e., there is at least one
+ <a href="#FormalObjection">Formal Objection</a>) so that the group may make progress (for example, to produce a
+ deliverable in a timely manner). Dissenters cannot stop a group's work simply by saying that they cannot live with a
+ decision. When the Chair believes that the Group has duly considered the legitimate concerns of dissenters as far as is
+ possible and reasonable, the group <em class="rfc2119">should</em> move on.</p>
+ <p>Groups <em class="rfc2119">should</em> favor proposals that create the weakest objections. This is preferred over
+ proposals that are supported by a large majority but that cause strong objections from a few people. As part of making
+ a decision where there is dissent, the Chair is expected to be aware of which participants work for the same (or
+ <a href="#MemberRelated">related</a>) Member organizations and weigh their input accordingly.</p>
+
<h4 id="WGArchiveMinorityViews">3.3.2 Recording and Reporting Formal Objections</h4>
- <p>In the W3C process, an individual may register a Formal Objection to a decision. A <dfn id="FormalObjection">Formal Objection</dfn>
- to a group decision is one that the reviewer requests that the Director consider as part of evaluating the related decision (e.g.,
- in response to a <a href="#rec-advance">request to advance</a> a technical report). <strong>Note:</strong> In this document, the
- term "Formal Objection" is used to emphasize this process implication: Formal Objections receive Director consideration. The word
- "objection" used alone has ordinary English connotations.</p>
- <p>An individual who registers a Formal Objection <em class="rfc2119">should</em> cite technical arguments and propose changes that
- would remove the Formal Objection; these proposals <em class="rfc2119">may</em> be vague or incomplete. Formal Objections that do
- not provide substantive arguments or rationale are unlikely to receive serious consideration by the Director.</p>
- <p>A record of each Formal Objection <em class="rfc2119">must</em> be <a href="#confidentiality-change">publicly available</a>. A
- Call for Review (of a document) to the Advisory Committee <em class="rfc2119">must</em> identify any Formal Objections.</p>
+
+ <p>In the W3C process, an individual may register a Formal Objection to a decision. A
+ <dfn id="FormalObjection">Formal Objection</dfn> to a group decision is one that the reviewer requests that the
+ Director consider as part of evaluating the related decision (e.g., in response to a
+ <a href="#rec-advance">request to advance</a> a technical report). <strong>Note:</strong> In this document, the
+ term "Formal Objection" is used to emphasize this process implication: Formal Objections receive Director consideration.
+ The word "objection" used alone has ordinary English connotations.</p>
+ <p>An individual who registers a Formal Objection <em class="rfc2119">should</em> cite technical arguments and propose
+ changes that would remove the Formal Objection; these proposals <em class="rfc2119">may</em> be vague or incomplete.
+ Formal Objections that do not provide substantive arguments or rationale are unlikely to receive serious consideration
+ by the Director.</p>
+ <p>A record of each Formal Objection <em class="rfc2119">must</em> be
+ <a href="#confidentiality-change">publicly available</a>. A Call for Review (of a document) to the Advisory Committee
+ <em class="rfc2119">must</em> identify any Formal Objections.</p>
+
<h4 id="formal-address">3.3.3 Formally Addressing an Issue</h4>
- <p>In the context of this document, a group has formally addressed an issue when it has sent a public, substantive response to the
- reviewer who raised the issue. A substantive response is expected to include rationale for decisions (e.g., a technical explanation,
- a pointer to charter scope, or a pointer to a requirements document). The adequacy of a response is measured against what a W3C
- reviewer would generally consider to be technically sound. If a group believes that a reviewer's comments result from a
- misunderstanding, the group <em class="rfc2119">should</em> seek clarification before reaching a decision.</p>
- <p>As a courtesy, both Chairs and reviewers <em class="rfc2119">should</em> set expectations for the schedule of responses and
- acknowledgments. The group <em class="rfc2119">should</em> reply to a reviewer's initial comments in a timely manner. The group <em
- class="rfc2119">should</em> set a time limit for acknowledgment by a reviewer of the group's substantive response; a reviewer
- cannot block a group's progress. It is common for a reviewer to require a week or more to acknowledge and comment on a substantive
- response. The group's responsibility to respond to reviewers does not end once a reasonable amount of time has elapsed. However,
- reviewers <em class="rfc2119">should</em> realize that their comments will carry less weight if not sent to the group in a timely
- manner.</p>
- <p>Substantive responses <em class="rfc2119">should</em> be recorded. The group <em class="rfc2119">should</em> maintain an accurate
- summary of all substantive issues and responses to them (e.g., in the form of an issues list with links to mailing list archives).</p>
+
+ <p>In the context of this document, a group has formally addressed an issue when it has sent a public, substantive response
+ to the reviewer who raised the issue. A substantive response is expected to include rationale for decisions (e.g., a
+ technical explanation, a pointer to charter scope, or a pointer to a requirements document). The adequacy of a response
+ is measured against what a W3C reviewer would generally consider to be technically sound. If a group believes that a
+ reviewer's comments result from a misunderstanding, the group <em class="rfc2119">should</em> seek clarification
+ before reaching a decision.</p>
+ <p>As a courtesy, both Chairs and reviewers <em class="rfc2119">should</em> set expectations for the schedule of
+ responses and acknowledgments. The group <em class="rfc2119">should</em> reply to a reviewer's initial comments in a
+ timely manner. The group <em class="rfc2119">should</em> set a time limit for acknowledgment by a reviewer of the
+ group's substantive response; a reviewer cannot block a group's progress. It is common for a reviewer to require a week
+ or more to acknowledge and comment on a substantive response. The group's responsibility to respond to reviewers does
+ not end once a reasonable amount of time has elapsed. However, reviewers <em class="rfc2119">should</em> realize that
+ their comments will carry less weight if not sent to the group in a timely manner.</p>
+ <p>Substantive responses <em class="rfc2119">should</em> be recorded. The group <em class="rfc2119">should</em> maintain
+ an accurate summary of all substantive issues and responses to them (e.g., in the form of an issues list with links to
+ mailing list archives).</p>
+
<h4 id="WGChairReopen">3.3.4 Reopening a Decision When Presented With New Information</h4>
+
<p>The Chair <em class="rfc2119">may</em> reopen a decision when presented with new information, including:</p>
<ul>
<li>additional technical information,</li>
<li>comments by email from participants who were unable to attend a scheduled meeting,</li>
- <li>comments by email from meeting attendees who chose not to speak out during a meeting (e.g., so they could confer later with
- colleagues or for cultural reasons).</li>
+ <li>comments by email from meeting attendees who chose not to speak out during a meeting (e.g., so they could confer
+ later with colleagues or for cultural reasons).</li>
</ul>
- <p>The Chair <em class="rfc2119">should</em> record that a decision has been reopened, and <em class="rfc2119">must</em> do so upon
- request from a group participant.</p>
+ <p>The Chair <em class="rfc2119">should</em> record that a decision has been reopened, and <em class="rfc2119">must</em>
+ do so upon request from a group participant.</p>
+
<h3 id="Votes">3.4 Votes</h3>
+
<p>A group <em class="rfc2119">should</em> only conduct a vote to resolve a <em>substantive issue</em> after the Chair has
- determined that all available means of <a href="#Consensus">reaching consensus</a> through technical discussion and compromise have
- failed, and that a vote is necessary to break a deadlock. In this case the Chair <em class="rfc2119">must</em> record (e.g., in the
- minutes of the meeting or in an archived email message):</p>
+ determined that all available means of <a href="#Consensus">reaching consensus</a> through technical discussion and
+ compromise have failed, and that a vote is necessary to break a deadlock. In this case the Chair
+ <em class="rfc2119">must</em> record (e.g., in the minutes of the meeting or in an archived email message):</p>
<ul>
<li>an explanation of the issue being voted on;</li>
<li>the decision to conduct a vote (e.g., a simple majority vote) to resolve the issue;</li>
<li>the outcome of the vote;</li>
<li>any Formal Objections.</li>
</ul>
- <p>In order to vote to resolve a substantive issue, an individual <em class="rfc2119">must</em> be a group <a href="#participant">participant</a>.
- Each organization represented in the group <em class="rfc2119">must</em> have at most one vote, even when the organization is
- represented by several participants in the group (including Invited Experts). For the purposes of voting:</p>
+ <p>In order to vote to resolve a substantive issue, an individual <em class="rfc2119">must</em> be a group
+ <a href="#participant">participant</a>. Each organization represented in the group <em class="rfc2119">must</em> have
+ at most one vote, even when the organization is represented by several participants in the group (including
+ Invited Experts). For the purposes of voting:</p>
<ul>
<li>A Member or group of <a href="#MemberRelated">related Members</a> is considered a single organization.</li>
<li>The <a href="#Team">Team</a> is considered an organization.</li>
@@ -941,14 +1027,13 @@
for a participant.</p>
<p>A group <em class="rfc2119">may</em> vote for other purposes than to resolve a substantive issue. For instance, the
- Chair often
- conducts a "straw poll" vote as a means of determining whether there is consensus about a potential decision.</p>
- <p>A group <em class="rfc2119">may</em> also vote to make a process decision. For example, it is appropriate to decide by simple
- majority whether to hold a meeting in San Francisco or San Jose (there's not much difference geographically). When simple majority
- votes are used to decide minor issues, the minority are <em class="rfc2119">not required</em> to state the reasons for their
- dissent, and the group is <em class="rfc2119">not required</em> to record individual votes.</p>
- <p>A group charter <em class="rfc2119">should</em> include formal voting procedures (e.g., quorum or threshold requirements) for
- making decisions about substantive issues.</p>
+ Chair often conducts a "straw poll" vote as a means of determining whether there is consensus about a potential decision.</p>
+ <p>A group <em class="rfc2119">may</em> also vote to make a process decision. For example, it is appropriate to decide by
+ simple majority whether to hold a meeting in San Francisco or San Jose (there's not much difference geographically).
+ When simple majority votes are used to decide minor issues, the minority are <em class="rfc2119">not required</em> to
+ state the reasons for their dissent, and the group is <em class="rfc2119">not required</em> to record individual votes.</p>
+ <p>A group charter <em class="rfc2119">should</em> include formal voting procedures (e.g., quorum or threshold requirements)
+ for making decisions about substantive issues.</p>
<p>Procedures for <a href="#ACVotes">Advisory Committee votes</a> are described separately.</p>
@@ -979,9 +1064,9 @@
<section id="chapterDissemination">
<h2 id="dissemination">4 Dissemination Policies</h2>
- <p>The Team is responsible for managing communication within W3C and with the general public (e.g., news services, press releases,
- managing the Web site and access privileges, and managing calendars). Members <em class="rfc2119">should</em> solicit review by
- the Team prior to issuing press releases about their work within W3C.</p>
+ <p>The Team is responsible for managing communication within W3C and with the general public (e.g., news services,
+ press releases, managing the Web site and access privileges, and managing calendars). Members
+ <em class="rfc2119">should</em> solicit review by the Team prior to issuing press releases about their work within W3C.</p>
<p>The Team makes every effort to ensure the persistence and availability of the following public information:</p>
<ul>
<li><a href="#Reports">W3C technical reports</a> whose publication has been approved by the Director. Per the Membership
@@ -1003,12 +1088,14 @@
to the Team for inclusion on this calendar.</p>
<h3 id"confidentiality-levels"="">4.1 Confidentiality Levels</h3>
- <p>There are three principal levels of access to W3C information (on the W3C Web site, in W3C meetings, etc.): public, Member-only,
- and Team-only.</p>
- <p>While much information made available by W3C is public, <dfn id="Member-only">"Member-only" information</dfn> is available to
- authorized parties only, including representatives of Member organizations, <a href="#invited-expert-wg">Invited Experts</a>, the
- Advisory Board, the TAG, and the Team. For example, the <a href="#WGCharter">charter</a> of some Working Groups may specify a
- Member-only confidentiality level for group proceedings.</p>
+
+ <p>There are three principal levels of access to W3C information (on the W3C Web site, in W3C meetings, etc.): public,
+ Member-only, and Team-only.</p>
+ <p>While much information made available by W3C is public, <dfn id="Member-only">"Member-only" information</dfn>
+ is available to authorized parties only, including representatives of Member organizations,
+ <a href="#invited-expert-wg">Invited Experts</a>, the Advisory Board, the TAG, and the Team. For example, the
+ <a href="#WGCharter">charter</a> of some Working Groups may specify a Member-only confidentiality level for
+ group proceedings.</p>
<p id="Team-only">"Team-only" information is available to the Team and other authorized parties.</p>
<p>Those authorized to access Member-only and Team-only information:</p>
<ul>
@@ -1016,104 +1103,131 @@
<li><em class="rfc2119">must</em> use reasonable efforts to maintain the proper level confidentiality, and</li>
<li><em class="rfc2119">must not</em> release this information to the general public or press.</li>
</ul>
- <p>The Team <em class="rfc2119">must</em> provide mechanisms to protect the confidentiality of Member-only information and ensure
- that authorized parties have proper access to this information. Documents <em class="rfc2119">should</em> clearly indicate
- whether they require Member-only confidentiality. Individuals uncertain of the confidentiality level of a piece of information <em
- class="rfc2119">should</em> contact the Team.</p>
- <p>Advisory Committee representatives <em class="rfc2119">may</em> authorize Member-only access to <a href="#member-rep">Member
- representatives</a> and other individuals employed by the Member who are considered appropriate recipients. For instance, it is
- the responsibility of the Advisory Committee representative and other employees and official representatives of the organization
- to ensure that Member-only news announcements are distributed for internal use only within their organization. Information about
+ <p>The Team <em class="rfc2119">must</em> provide mechanisms to protect the confidentiality of Member-only information
+ and ensure that authorized parties have proper access to this information. Documents <em class="rfc2119">should</em>
+ clearly indicate whether they require Member-only confidentiality. Individuals uncertain of the confidentiality level
+ of a piece of information <em class="rfc2119">should</em> contact the Team.</p>
+ <p>Advisory Committee representatives <em class="rfc2119">may</em> authorize Member-only access to
+ <a href="#member-rep">Member representatives</a> and other individuals employed by the Member who are considered
+ appropriate recipients. For instance, it is the responsibility of the Advisory Committee representative and other
+ employees and official representatives of the organization to ensure that Member-only news announcements are
+ distributed for internal use only within their organization. Information about
Member mailing lists is available in the <a href="https://www.w3.org/Member/Intro">New Member Orientation</a>.</p>
+
<h4 id="confidentiality-change">4.1.1 Changing Confidentiality Level</h4>
- <p>As a benefit of membership, W3C provides some Team-only and Member-only channels for certain types of communication. For example,
- Advisory Committee representatives can send <a href="#ACReview">reviews</a> to a Team-only channel. However, for W3C processes
- with a significant public component, such as the technical report development process, it is also important for information that
- affects decision-making to be publicly available. The Team <em class="rfc2119">may</em> need to communicate Team-only information
- to a Working Group or the public. Similarly, a Working Group whose proceedings are Member-only <em class="rfc2119">must</em> make
+
+ <p>As a benefit of membership, W3C provides some Team-only and Member-only channels for certain types of communication.
+ For example, Advisory Committee representatives can send <a href="#ACReview">reviews</a> to a Team-only channel.
+ However, for W3C processes with a significant public component, such as the technical report development process, it
+ is also important for information that affects decision-making to be publicly available. The Team
+ <em class="rfc2119">may</em> need to communicate Team-only information to a Working Group or the public. Similarly,
+ a Working Group whose proceedings are Member-only <em class="rfc2119">must</em> make
public information pertinent to the technical report development process.</p>
- <p>This document clearly indicates which information <em class="rfc2119">must</em> be available to Members or the public, even
- though that information was initially communicated on Team-only or Member-only channels. Only the Team and parties authorized by
- the Team change the level of confidentiality of this information. When doing so:</p>
+ <p>This document clearly indicates which information <em class="rfc2119">must</em> be available to Members or the public,
+ even though that information was initially communicated on Team-only or Member-only channels. Only the Team and
+ parties authorized by the Team change the level of confidentiality of this information. When doing so:</p>
<ol>
- <li>The Team <em class="rfc2119">must</em> use a version of the information that was expressly provided by the author for the new
- confidentiality level. In Calls for Review and other similar messages, the Team <em class="rfc2119">should</em> remind
- recipients to provide such alternatives.</li>
- <li>The Team <em class="rfc2119">must not</em> attribute the version for the new confidentiality level to the author without the
- author's consent.</li>
- <li>If the author has not conveyed to the Team a version that is suitable for another confidentiality level, the Team <em class="rfc2119">may</em>
- make available a version that reasonably communicates what is required, while respecting the original level of confidentiality,
- and without attribution to the original author.</li>
+ <li>The Team <em class="rfc2119">must</em> use a version of the information that was expressly provided by the author
+ for the new confidentiality level. In Calls for Review and other similar messages, the Team
+ <em class="rfc2119">should</em> remind recipients to provide such alternatives.</li>
+ <li>The Team <em class="rfc2119">must not</em> attribute the version for the new confidentiality level to the
+ author without the author's consent.</li>
+ <li>If the author has not conveyed to the Team a version that is suitable for another confidentiality level, the Team
+ <em class="rfc2119">may</em> make available a version that reasonably communicates what is required, while
+ respecting the original level of confidentiality, and without attribution to the original author.</li>
</ol>
</section>
+
<section id="ChapterGroups">
+
<h2 id="GAGeneral">5 Working Groups and Interest Groups</h2>
+
<p id="GAGroups">This document defines two types of groups:</p>
<ol>
- <li><a href="#GroupsWG">Working Groups.</a> Working Groups typically produce deliverables (e.g., <a href="#rec-advance">Recommendation
- Track technical reports</a>, software, test suites, and reviews of the deliverables of other groups). There are additional
- participation requirements described in the <a href="https://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</li>
- <li><a href="#GroupsIG">Interest Groups.</a> The primary goal of an Interest Group is to bring together people who wish to
- evaluate potential Web technologies and policies. An Interest Group is a forum for the exchange of ideas.</li>
+ <li><a href="#GroupsWG">Working Groups.</a> Working Groups typically produce deliverables (e.g.,
+ <a href="#rec-advance">Recommendation Track technical reports</a>, software, test suites, and reviews of the
+ deliverables of other groups). There are additional participation requirements described in the
+ <a href="https://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a>
+ [<a href="#ref-patentpolicy">PUB33</a>].</li>
+ <li><a href="#GroupsIG">Interest Groups.</a> The primary goal of an Interest Group is to bring together people who
+ wish to evaluate potential Web technologies and policies. An Interest Group is a forum for the exchange of ideas.</li>
</ol>
- <p>Interest Groups do not publish <a href="#RecsW3C">Recommendation Track technical reports</a>; see information about <a href="#WGNote">maturity
- levels for Interest Groups</a>.</p>
+ <p>Interest Groups do not publish <a href="#RecsW3C">Recommendation Track technical reports</a>; see information about
+ <a href="#WGNote">maturity levels for Interest Groups</a>.</p>
+
<h3 id="ReqsAllGroups">5.1 Requirements for All Working and Interest Groups</h3>
- <p>Each group <em class="rfc2119">must</em> have a charter. Requirements for the charter depend on the group type. All group
- charters <em class="rfc2119">must</em> be public (even if other proceedings of the group are <a href="#Member-only">Member-only</a>).
- Existing charters that are not yet public <em class="rfc2119">must</em> be made public when next revised or extended (with
- attention to <a href="#confidentiality-change">changing confidentiality level</a>).</p>
- <p>Each group <em class="rfc2119">must</em> have a <dfn id="GeneralChairs">Chair</dfn> (or co-Chairs) to coordinate the group's
- tasks. The Director appoints (and re-appoints) Chairs for all groups. The Chair is a <a href="#member-rep">Member representative</a>,
- a <a href="#Team">Team representative</a>, or an <a href="#invited-expert-wg">Invited Expert</a> (invited by the Director). The
- requirements of this document that apply to those types of participants apply to Chairs as well. The <a href="/Guide/chair-roles">role
- of the Chair [MEM14]</a> is described in the <a href="https://www.w3.org/Guide/">Member guide</a> [<a href="#ref-guide">MEM9</a>].</p>
- <p>Each group <em class="rfc2119">must</em> have a <dfn id="TeamContact">Team Contact</dfn>, who acts as the interface between the
- Chair, group participants, and the rest of the Team. The <a href="/Guide/staff-contact">role of the Team Contact</a> is described
- in the Member guide. The Chair and the Team Contact of a group <em class="rfc2119">should not</em> be the same individual.</p>
- <p>Each group <em class="rfc2119">must</em> have an archived mailing list for formal group communication (e.g., for meeting
- announcements and minutes, documentation of decisions, and <a href="#FormalObjection">Formal Objections</a> to decisions). It is
- the responsibility of the Chair and Team Contact to ensure that new participants are subscribed to all relevant mailing lists.
- Refer to the list of <a href="https://www.w3.org/Member/Mail/">group mailing lists</a> [<a href="#ref-mailing-lists">MEM2</a>].</p>
- <p>A Chair <em class="rfc2119">may</em> form task forces (composed of group participants) to carry out assignments for the group.
- The scope of these assignments <em class="rfc2119">must not</em> exceed the scope of the group's charter. A group <em class="rfc2119">should</em>
- document the process it uses to create task forces (e.g., each task force might have an informal "charter"). Task forces do not
- publish <a href="#Reports">technical reports</a>; the Working Group <em class="rfc2119">may</em> choose to publish their results
- as part of a technical report.</p>
+
+ <p>Each group <em class="rfc2119">must</em> have a charter. Requirements for the charter depend on the group type.
+ All group charters <em class="rfc2119">must</em> be public (even if other proceedings of the group are
+ <a href="#Member-only">Member-only</a>). Existing charters that are not yet public <em class="rfc2119">must</em>
+ be made public when next revised or extended (with attention to
+ <a href="#confidentiality-change">changing confidentiality level</a>).</p>
+ <p>Each group <em class="rfc2119">must</em> have a <dfn id="GeneralChairs">Chair</dfn> (or co-Chairs) to coordinate
+ the group's tasks. The Director appoints (and re-appoints) Chairs for all groups. The Chair is a
+ <a href="#member-rep">Member representative</a>, a <a href="#Team">Team representative</a>, or an
+ <a href="#invited-expert-wg">Invited Expert</a> (invited by the Director). The requirements of this document that
+ apply to those types of participants apply to Chairs as well. The
+ <a href="/Guide/chair-roles">role of the Chair [MEM14]</a> is described in the
+ <a href="https://www.w3.org/Guide/">Member guide</a> [<a href="#ref-guide">MEM9</a>].</p>
+ <p>Each group <em class="rfc2119">must</em> have a <dfn id="TeamContact">Team Contact</dfn>, who acts as the interface
+ between the Chair, group participants, and the rest of the Team. The
+ <a href="/Guide/staff-contact">role of the Team Contact</a> is described in the Member guide. The Chair and the
+ Team Contact of a group <em class="rfc2119">should not</em> be the same individual.</p>
+ <p>Each group <em class="rfc2119">must</em> have an archived mailing list for formal group communication (e.g., for
+ meeting announcements and minutes, documentation of decisions, and <a href="#FormalObjection">Formal Objections</a>
+ to decisions). It is the responsibility of the Chair and Team Contact to ensure that new participants are subscribed
+ to all relevant mailing lists. Refer to the list of
+ <a href="https://www.w3.org/Member/Mail/">group mailing lists</a> [<a href="#ref-mailing-lists">MEM2</a>].</p>
+ <p>A Chair <em class="rfc2119">may</em> form task forces (composed of group participants) to carry out assignments for
+ the group. The scope of these assignments <em class="rfc2119">must not</em> exceed the scope of the group's charter.
+ A group <em class="rfc2119">should</em> document the process it uses to create task forces (e.g., each task force
+ might have an informal "charter"). Task forces do not publish <a href="#Reports">technical reports</a>; the
+ Working Group <em class="rfc2119">may</em> choose to publish their results as part of a technical report.</p>
+
<h3>5.2 <dfn id="GroupsWG">Working Groups</dfn> and <dfn id="GroupsIG">Interest Groups</dfn></h3>
- <p>Although Working Groups and Interest Groups have different purposes, they share some characteristics, and so are defined together
- in the following sections.</p>
+
+ <p>Although Working Groups and Interest Groups have different purposes, they share some characteristics, and so are
+ defined together in the following sections.</p>
+
<h4>5.2.1 <dfn id="group-participation">Working Group and Interest Group Participation Requirements</dfn></h4>
- <p>There are three types of individual <dfn id="wgparticipant">participants in a Working Group</dfn>: <a href="#member-rep">Member
- representatives</a>, <a href="#invited-expert-wg">Invited Experts</a>, and <a href="#Team">Team representatives</a> (including
- the <a href="#TeamContact">Team Contact</a>).</p>
- <p>There are four types of individual <dfn id="igparticipant">participants in an Interest Group</dfn>: the same three types as for
- Working Groups plus, for an Interest Group where the only <a href="#ig-mail-only">participation requirement is mailing list
- subscription</a>, <dfn id="public-participant-ig">public participants</dfn>.</p>
- <p>Except where noted in this document or in a group charter, all participants share the same rights and responsibilities in a
- group; see also the <a href="#ParticipationCriteria">individual participation criteria</a>.</p>
+
+ <p>There are three types of individual <dfn id="wgparticipant">participants in a Working Group</dfn>:
+ <a href="#member-rep">Member representatives</a>, <a href="#invited-expert-wg">Invited Experts</a>,
+ and <a href="#Team">Team representatives</a> (including the <a href="#TeamContact">Team Contact</a>).</p>
+ <p>There are four types of individual <dfn id="igparticipant">participants in an Interest Group</dfn>: the same three
+ types as for Working Groups plus, for an Interest Group where the only
+ <a href="#ig-mail-only">participation requirement is mailing list subscription</a>,
+ <dfn id="public-participant-ig">public participants</dfn>.</p>
+ <p>Except where noted in this document or in a group charter, all participants share the same rights and responsibilities
+ in a group; see also the <a href="#ParticipationCriteria">individual participation criteria</a>.</p>
<p>A participant <em class="rfc2119">must</em> represent at most one organization in a Working Group or Interest Group.</p>
<p>An individual <em class="rfc2119">may</em> become a Working or Interest Group participant at any time during the group's
- existence. See also relevant requirements in <a href="https://www.w3.org/Consortium/Patent-Policy#sec-join">section 4.3</a> of the
+ existence. See also relevant requirements in
+ <a href="https://www.w3.org/Consortium/Patent-Policy#sec-join">section 4.3</a> of the
<a href="https://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
- <p>On an exceptional basis, a Working or Interest Group participant <em class="rfc2119">may</em> designate a <dfn id="mtg-substitute">substitute</dfn>
- to attend a <a href="#GeneralMeetings">meeting</a> and <em class="rfc2119">should</em> inform the Chair. The substitute <em class="rfc2119">may</em>
- act on behalf of the participant, including for <a href="#Votes">votes</a>. For the substitute to vote, the participant <em class="rfc2119">must</em>
- inform the Chair in writing in advance. As a courtesy to the group, if the substitute is not well-versed in the group's
- discussions, the regular participant <em class="rfc2119">should</em> authorize another participant to act as <a href="#proxy">proxy</a>
- for votes.</p>
- <p>To allow rapid progress, Working Groups are intended to be small (typically fewer than 15 people) and composed of experts in the
- area defined by the charter. In principle, Interest Groups have no limit on the number of participants. When a Working Group grows
- too large to be effective, W3C <em class="rfc2119">may</em> split it into an Interest Group (a discussion forum) and a much
- smaller Working Group (a core group of highly dedicated participants).</p>
- <p>See also the licensing obligations on Working Group participants in <a href="https://www.w3.org/Consortium/Patent-Policy#sec-Obligations">section
- 3</a> of the <a href="https://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>],
- and the patent claim exclusion process of <a href="https://www.w3.org/Consortium/Patent-Policy#sec-Exclusion">section 4</a>.</p>
+ <p>On an exceptional basis, a Working or Interest Group participant <em class="rfc2119">may</em> designate a
+ <dfn id="mtg-substitute">substitute</dfn> to attend a <a href="#GeneralMeetings">meeting</a> and
+ <em class="rfc2119">should</em> inform the Chair. The substitute <em class="rfc2119">may</em> act on behalf of the
+ participant, including for <a href="#Votes">votes</a>. For the substitute to vote, the participant
+ <em class="rfc2119">must</em> inform the Chair in writing in advance. As a courtesy to the group, if the substitute
+ is not well-versed in the group's discussions, the regular participant <em class="rfc2119">should</em> authorize
+ another participant to act as <a href="#proxy">proxy</a> for votes.</p>
+ <p>To allow rapid progress, Working Groups are intended to be small (typically fewer than 15 people) and composed of
+ experts in the area defined by the charter. In principle, Interest Groups have no limit on the number of participants.
+ When a Working Group grows too large to be effective, W3C <em class="rfc2119">may</em> split it into an Interest Group
+ (a discussion forum) and a much smaller Working Group (a core group of highly dedicated participants).</p>
+ <p>See also the licensing obligations on Working Group participants in
+ <a href="https://www.w3.org/Consortium/Patent-Policy#sec-Obligations">section 3</a> of the
+ <a href="https://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>],
+ and the patent claim exclusion process of
+ <a href="https://www.w3.org/Consortium/Patent-Policy#sec-Exclusion">section 4</a>.</p>
+
<h5>5.2.1.1 <dfn id="member-rep-wg">Member Representative</dfn> in a Working Group</h5>
+
<p>An individual is a Member representative in a Working Group if all of the following conditions are satisfied:</p>
<ul>
- <li>the Advisory Committee representative of the Member in question has designated the individual as a Working Group participant,
- and</li>
+ <li>the Advisory Committee representative of the Member in question has designated the individual as a
+ Working Group participant, and</li>
<li>the individual qualifies for <a href="#member-rep">Member representation</a>.</li>
</ul>
<p><dfn id="member-rep-info">To designate an individual as a Member representative in a Working Group</dfn>, an
@@ -1122,22 +1236,25 @@
and charter (including the participation requirements of the
<a href="https://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>]):</p>
<ol>
- <li>The name of the W3C Member the individual represents and whether the individual is an employee of that Member organization;</li>
- <li>A statement that the individual accepts the participation terms set forth in the charter (with an indication of charter date
- or version);</li>
- <li>A statement that the Member will provide the necessary financial support for participation (e.g., for travel, telephone calls,
- and conferences).</li>
+ <li>The name of the W3C Member the individual represents and whether the individual is an employee of that
+ Member organization;</li>
+ <li>A statement that the individual accepts the participation terms set forth in the charter (with an indication
+ of charter date or version);</li>
+ <li>A statement that the Member will provide the necessary financial support for participation (e.g., for travel,
+ telephone calls, and conferences).</li>
</ol>
- <p>A Member participates in a Working Group from the moment the first Member representative joins the group until either of the
- following occurs:</p>
+ <p>A Member participates in a Working Group from the moment the first Member representative joins the group until
+ either of the following occurs:</p>
<ul>
<li>the group closes, or</li>
- <li>the Member <a href="#resignation">resigns</a> from the Working Group; this is done through the Member's Advisory
- Committee representative.</li>
+ <li>the Member <a href="#resignation">resigns</a> from the Working Group; this is done through the
+ Member's Advisory Committee representative.</li>
</ul>
+
<h5>5.2.1.2 <dfn id="member-rep-ig">Member Representative</dfn> in an Interest Group</h5>
- <p>When the participation requirements exceed <a href="#ig-mail-only">Interest Group mailing list subscription</a>, an individual
- is a Member representative in an Interest Group if all of the following conditions are satisfied:</p>
+
+ <p>When the participation requirements exceed <a href="#ig-mail-only">Interest Group mailing list subscription</a>,
+ an individual is a Member representative in an Interest Group if all of the following conditions are satisfied:</p>
<ul>
<li>the Advisory Committee representative of the Member in question has designated the individual as an
Interest Group participant, and</li>
@@ -1221,7 +1338,8 @@
<p>W3C creates a charter based on interest from the Members and Team. The Team <em class="rfc2119">must</em> notify
the Advisory Committee when a charter for a new Working Group or Interest Group is in development. This is intended
to raise awareness, even if no formal proposal is yet available. Advisory Committee representatives
- <em class="rfc2119">may</em> provide feedback on the <a href="#ACCommunication">Advisory Committee discussion list</a>.</p>
+ <em class="rfc2119">may</em> provide feedback on the
+ <a href="#ACCommunication">Advisory Committee discussion list</a>.</p>
<p>W3C <em class="rfc2119">may</em> begin work on a Working Group or Interest Group charter at any time.</p>
@@ -1366,7 +1484,7 @@
<h4>5.2.7 <dfn id="GeneralTermination">Working Group and Interest Group Closure</dfn></h4>
<p>A Working Group or Interest Group charter specifies a duration for the group. The Director, subject to
- an <a href="#ACAppeal">Advisory Committee Appeal</a>initiated by Advisory Committee representatives,
+ an <a href="#ACAppeal">Advisory Committee Appeal</a> initiated by Advisory Committee representatives,
<em class="rfc2119">may</em> decide to close a group prior to the date specified in the charter in
any of the following circumstances:</p>
<ul>
@@ -1378,7 +1496,9 @@
<p>Closing a Working Group has implications with respect to the
<a href="https://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
</section>
+
<h2 id="Reports">6 W3C Technical Report Development Process</h2>
+
<p>The W3C technical report development process is the set of steps and requirements followed by W3C
<a href="#GroupsWG">Working Groups</a> to standardize Web technology. The W3C technical report development process
is designed to:</p>
@@ -1396,25 +1516,31 @@
<a href="https://www.w3.org/Consortium/Patent-Policy#sec-Licensing">section 2</a> of the
<a href="https://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].
</p>
+
<h3 id="rec-advance">6.1 W3C Technical Reports</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="https://www.w3.org/TR/">Technical Reports page https://www.w3.org/TR</a>.</p>
<p>This chapter describes the formal requirements for publishing and maintaining a W3C Recommendation or Note.</p>
- <p>Typically a series of Working Drafts are published, each of which refines a document under development to complete the scope of
- work envisioned by a Working Group's charter. For a technical specification, once review suggests the Working Group has met their
- requirements satisfactorily for a new standard, there is a <a href="#last-call">Candidate Recommendation</a> phase. This allows the entire W3C membership to
- provide feedback on whether the specification is appropriate as a W3C Recommendation, while the Working Group formally collects
- implementation experience to demonstrate that the specification works in practice. The next phase is a Proposed Recommendation, to
- finalize the review of W3C Members. If the Director determines that W3C member review supports a specification becoming a standard,
- W3C publishes it as a Recommendation.</p>
- <p>Groups may also publish documents as W3C Notes, typically either to document information other than technical specifications, such
- as use cases motivating a specification and best practices for its use, or to clarify the status of work that is abandoned. </p>
- <p>Some W3C Notes are developed through successive Working Drafts, with an expectation that they will become Notes, while others are
- simply published. There are few formal requirements to publish a document as a W3C Note, and they have no standing as a
- recommendation of W3C but are simply documents preserved for historical reference.</p>
- <p>Individual Working Groups and Interest Groups may adopt additional processes for developing publications, so long as they do not
- conflict with the requirements in this chapter.</p>
+ <p>Typically a series of Working Drafts are published, each of which refines a document under development to complete
+ the scope of work envisioned by a Working Group's charter. For a technical specification, once review suggests the
+ Working Group has met their requirements satisfactorily for a new standard, there is a
+ <a href="#last-call">Candidate Recommendation</a> phase. This allows the entire W3C membership to provide feedback
+ on whether the specification is appropriate as a W3C Recommendation, while the Working Group formally collects
+ implementation experience to demonstrate that the specification works in practice. The next phase is a
+ Proposed Recommendation, to finalize the review of W3C Members. If the Director determines that W3C member review
+ supports a specification becoming a standard, W3C publishes it as a Recommendation.</p>
+ <p>Groups may also publish documents as W3C Notes, typically either to document information other than technical
+ specifications, such as use cases motivating a specification and best practices for its use, or to clarify the
+ status of work that is abandoned. </p>
+ <p>Some W3C Notes are developed through successive Working Drafts, with an expectation that they will become Notes,
+ while others are simply published. There are few formal requirements to publish a document as a W3C Note, and they
+ have no standing as a recommendation of W3C but are simply documents preserved for historical reference.</p>
+ <p>Individual Working Groups and Interest Groups may adopt additional processes for developing publications, so long as
+ they do not conflict with the requirements in this chapter.</p>
+
<h4 id="recs-and-notes">6.1.1 Recommendations and Notes</h4>
+
<p>W3C follows these steps when advancing a technical report to Recommendation.</p>
<ol>
<li>Publication of the <a href="#first-wd">First Public Working Draft</a>,</li>
@@ -1556,85 +1682,101 @@
</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>
+ <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">6.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>
+ <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
+ <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 it is time to do a final review</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="https://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>
+ <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="https://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>
+ <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 <em class="rfc2119">must</em> not be made to a Proposed Recommendation except by publishing a new Working
- Draft or Candidate Recommendation.</dd>
+ <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 <em class="rfc2119">must</em> 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>
+ <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>
+ <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="https://www.w3.org/Consortium/Patent-Policy#sec-Requirements">section 5</a> of
- the <a href="https://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</dd>
+ requirements for W3C Recommendations in
+ <a href="https://www.w3.org/Consortium/Patent-Policy#sec-Requirements">section 5</a> of the
+ <a href="https://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>
+
+ <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">6.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="https://www.w3.org/TR/">Technical Reports page https://www.w3.org/TR</a> [<a href="#ref-doc-list">PUB11</a>].</p>
+ <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="https://www.w3.org/TR/">Technical Reports page https://www.w3.org/TR</a>
+ [<a href="#ref-doc-list">PUB11</a>].</p>
+
<h4 id="general-requirements">6.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="https://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>
+ document. The <a href="https://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 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="https://www.w3.org/Guide/pubrules">Publication
- Rules</a> [<a href="#ref-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="https://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>
+
+ <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="https://www.w3.org/Guide/pubrules">Publication Rules</a> [<a href="#ref-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="https://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">6.2.2 Advancement on the Recommendation Track</h4>
@@ -1666,37 +1808,47 @@
Advisory Committee Review.</p>
<h4 id="doc-reviews">6.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.
+
+ <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>
+ <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">6.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 were able
- to actually perform reviews of and provide comments on the specification. 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 <a href="https://www.w3.org/Guide/Charter.html#horizontal-review">W3C
- Horizontal Groups</a> and groups identified as dependencies in the charter or identified as <a href="https://www.w3.org/2001/11/StdLiaison.html">liaisons</a>
- [<a href="#ref-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 <em class="rfc2119">should</em> announce to other W3C Working Groups as well as the general public, especially those
- affected by this specification, a proposal to enter <a href="#last-call">Candidate Recommendation</a> (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>
+
+ <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 were able to actually perform
+ reviews of and provide comments on the specification. 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
+ <a href="https://www.w3.org/Guide/Charter.html#horizontal-review">W3C Horizontal Groups</a> and groups identified as
+ dependencies in the charter or identified as <a href="https://www.w3.org/2001/11/StdLiaison.html">liaisons</a>
+ [<a href="#ref-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 <em class="rfc2119">should</em> announce to other W3C Working Groups as well as the
+ general public, especially those affected by this specification, a proposal to enter
+ <a href="#last-call">Candidate Recommendation</a> (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">6.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>
+
+ <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>
@@ -1705,67 +1857,79 @@
<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>
+ <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">6.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>
+
+ <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>Changes that reasonable implementers would not interpret as changing architectural or interoperability requirements or their
- implementation. Changes which resolve ambiguities in the specification are considered to change (by clarification) the
- implementation requirements and do not fall into this class.</dd>
- <dd>Examples of changes in this class are correcting non-normative code examples where the code clearly conflicts with normative
- requirements, clarifying informative use cases or other non-normative text, fixing typos or grammatical errors where the change
- does not change implementation requirements. If there is any doubt or dissent as to whether requirements are changed, such changes
- do not belong to this class..</dd>
+ <dd>Changes that reasonable implementers would not interpret as changing architectural or interoperability requirements
+ or their implementation. Changes which resolve ambiguities in the specification are considered to change
+ (by clarification) the implementation requirements and do not fall into this class.</dd>
+ <dd>Examples of changes in this class are correcting non-normative code examples where the code clearly conflicts with
+ normative requirements, clarifying informative use cases or other non-normative text, fixing typos or grammatical errors
+ where the change does not change implementation requirements. If there is any doubt or dissent as to whether requirements
+ are changed, such changes do not belong to this class..</dd>
<dt>3. Corrections that do not add new features</dt>
- <dd>These changes <em class="rfc2119">may</em> affect conformance to the specification. A change that affects conformance is one
- that:
+ <dd>These changes <em class="rfc2119">may</em> 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 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>
+ <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">6.3 Working Draft</h3>
- <p>A Public Working Draft is published on the <a href="https://www.w3.org/TR/">W3C's Technical Reports page</a> [<a href="#ref-doc-list">PUB11</a>]
- for review, and for simple historical reference. For all Public Working Drafts a Working Group</p>
+
+ <p>A Public Working Draft is published on the <a href="https://www.w3.org/TR/">W3C's Technical Reports page</a>
+ [<a href="#ref-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>
+ <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">6.3.1 First Public Working Draft</h4>
- <p>To publish the First Public Working Draft of a document, a Working Group <em class="rfc2119">must</em> 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="https://www.w3.org/Consortium/Patent-Policy/#sec-Exclusion">section
- 4</a> of the <a href="https://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
+
+ <p>To publish the First Public Working Draft of a document, a Working Group <em class="rfc2119">must</em> 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="https://www.w3.org/Consortium/Patent-Policy/#sec-Exclusion">section 4</a> of the
+ <a href="https://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
+
<h4 id="revised-wd">6.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>
+
+ <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">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>
@@ -1775,34 +1939,39 @@
<li><a href="#Note">Working Group Note</a></li>
</ul>
<h4 id="tr-end">6.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>
+ <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">6.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>
+
+ <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> 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>
+ <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 the specification is
- appropriate to publish as a W3C Recommendation.</p>
- <p> A Candidate Recommendation corresponds to a "Last Call Working Draft" as used in the <a href="https://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="https://www.w3.org/Consortium/Patent-Policy/#sec-Exclusion">section 4</a> of the <a href="https://www.w3.org/Consortium/Patent-Policy">W3C
- Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
+ <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 the
+ specification is appropriate to publish as a W3C Recommendation.</p>
+ <p> A Candidate Recommendation corresponds to a "Last Call Working Draft" as used in the
+ <a href="https://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="https://www.w3.org/Consortium/Patent-Policy/#sec-Exclusion">section 4</a> of the
+ <a href="https://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
<p>Possible next steps:</p>
<ul>
<li>Return to <a href="#revised-wd">Working Draft</a></li>
@@ -1825,14 +1994,17 @@
<p>In addition the Working Group:</p>
<ul>
- <li><em class="rfc2119">must</em> show that the revised specification meets all Working Group requirements, or explain why the
- requirements have changed or been deferred,</li>
- <li><em class="rfc2119">must</em> specify the deadline for further 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 revised specification meets all Working Group requirements, or explain
+ why the requirements have changed or been deferred,</li>
+ <li><em class="rfc2119">must</em> specify the deadline for further 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> document the changes since the previous Candidate Recommendation, </li>
- <li><em class="rfc2119">must</em> show that the proposed changes have 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>
+ <li><em class="rfc2119">must</em> show that the proposed changes have 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 revised Candidate Recommendation to
other W3C groups and the Public.</p>
@@ -1851,24 +2023,26 @@
<li><em class="rfc2119">must</em> show adequate <a href="#implementation-experience">implementation experience</a>
except where an exception is approved by the Director,</li>
<li><em class="rfc2119">must</em> show that the document has received <a href="#wide-review">wide review,</a></li>
- <li><em class="rfc2119">must</em> show that all issues raised during the Candidate Recommendation review period other than by
- Advisory Committee representatives acting in their formal AC representative role have been <a href="#formal-address">formally
- addressed</a>,</li>
- <li><em class="rfc2119">must </em>identify any substantive issues raised since the close of the Candidate Recommendation review
- period by parties other than Advisory Committee representatives acting in their formal AC representative role,</li>
- <li><em class="rfc2119">may</em> have removed features identified in the Candidate Recommendation document as "at risk" without
- republishing the specification as a Candidate Recommendation.</li>
+ <li><em class="rfc2119">must</em> show that all issues raised during the Candidate Recommendation review period other
+ than by Advisory Committee representatives acting in their formal AC representative role have been
+ <a href="#formal-address">formally addressed</a>,</li>
+ <li><em class="rfc2119">must </em>identify any substantive issues raised since the close of the Candidate Recommendation
+ review period by parties other than Advisory Committee representatives acting in their formal AC representative role,</li>
+ <li><em class="rfc2119">may</em> have removed features identified in the Candidate Recommendation document as "at risk"
+ without republishing the specification as a Candidate Recommendation.</li>
</ul>
<p>The Director:</p>
<ul>
- <li><em class="rfc2119">must</em> announce the publication of a Proposed Recommendation to the <a href="#AC">Advisory Committee</a>,
- and</li>
- <li><span><em class="rfc2119">may</em> approve a Proposed Recommendation with minimal implementation experience where there is a
- compelling reason to do so. In such a case, the Director <em class="rfc2119">should</em> explain the reasons for that decision.</span></li>
+ <li><em class="rfc2119">must</em> announce the publication of a Proposed Recommendation to the
+ <a href="#AC">Advisory Committee</a>, and</li>
+ <li><span><em class="rfc2119">may</em> approve a Proposed Recommendation with minimal implementation experience where
+ there is a compelling reason to do so. In such a case, the Director <em class="rfc2119">should</em> explain the
+ reasons for that decision.</span></li>
</ul>
- <p>Since a W3C Recommendation <em class="rfc2119">must not</em> include any substantive changes from the Proposed Recommendation it
- is based on, to make any substantive change to a Proposed Recommendation the Working Group <em class="rfc2119">must</em> return the
- specification to <a href="#last-call">Candidate Recommendation</a> or Working Draft.</p>
+ <p>Since a W3C Recommendation <em class="rfc2119">must not</em> include any substantive changes from the
+ Proposed Recommendation it is based on, to make any substantive change to a Proposed Recommendation the Working Group
+ <em class="rfc2119">must</em> return the specification to <a href="#last-call">Candidate Recommendation</a> or
+ Working Draft.</p>
<p>Possible Next Steps:</p>
<ul>
<li>Return to <a href="#revised-wd">Working Draft</a></li>
@@ -1901,8 +2075,10 @@
</ul>
<h3 id="rec-modify">6.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="https://www.w3.org/2003/01/republishing/">Requirements
- for modification of W3C Technical Reports</a> [<a href="#in-place-tr-mod">PUB35</a>].</p>
+
+ <p>This section details the management of errors in, and the process for making changes to a Recommendation. Please see also
+ the <a href="https://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 xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg" viewBox="0 60 640 240" height="16em" width="60em">
@@ -2110,6 +2286,7 @@
</p>
<h4 id="errata">6.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 error that can be resolved by one or more
@@ -2125,6 +2302,7 @@
of the Recommendation by the process for Revising a Recommendation described in the next section.</p>
<h4 id="revised-rec">6.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>
@@ -2152,6 +2330,7 @@
First Public Working Draft.</p>
<h3 id="Note">6.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
@@ -2246,9 +2425,12 @@
version-specific URL.</p>
<h3 id="further-reading">Further reading</h3>
- <p>Refer to <a href="https://www.w3.org/2003/05/Transitions">"How to Organize a Recommendation Track Transition"</a> in the <a href="https://www.w3.org/Guide/">Member
- guide</a> for practical information about preparing for the reviews and announcements of the various steps, and <a href="https://www.w3.org/2002/05/rec-tips">tips
- on getting to Recommendation faster</a> [<a href="#ref-rec-tips">PUB27</a>].</p>
+
+ <p>Refer to <a href="https://www.w3.org/2003/05/Transitions">"How to Organize a Recommendation Track Transition"</a> in
+ the <a href="https://www.w3.org/Guide/">Member guide</a> for practical information about preparing for the reviews
+ and announcements of the various steps, and
+ <a href="https://www.w3.org/2002/05/rec-tips">tips on getting to Recommendation faster</a>
+ [<a href="#ref-rec-tips">PUB27</a>].</p>
<h2 id="ReviewAppeal">7 Advisory Committee Reviews, Appeals, and Votes</h2>
@@ -2532,7 +2714,7 @@
<h3 id="TeamSubmissionRights">10.2 Team Rights and Obligations</h3>
- <p>Although they are not technical reports, the documents in a Member Submission <em class="rfc2119">must</em> fulfill the
+ <p>Although they are not technical reports, the documents in a Member Submission <em class="rfc2119">must</em> fulfil the
requirements established by the Team, including the Team's
<a href="https://www.w3.org/Guide/pubrules">Publication Rules</a>.</p>
@@ -2746,7 +2928,8 @@
<h2 id="changes">14 Changes</h2>
- <p>This document is based on the <a href="https://www.w3.org/2015/Process-20150901/">1 September 2015 Process</a>. <a href="https://dvcs.w3.org/hg/AB/">Detailed change logs</a> are available.</p>
+ <p>This document is based on the <a href="https://www.w3.org/2015/Process-20150901/">1 September 2015 Process</a>.
+ <a href="https://dvcs.w3.org/hg/AB/">Detailed change logs</a> are available.</p>
<p>The notable changes include:</p>
@@ -2769,7 +2952,8 @@
- section <a href="#GAEvents">8</a></li>
</ul>
- <h3>Between the <a href="https://dvcs.w3.org/hg/AB/raw-file/9827cf0fed91/cover.html">28 July 2016 draft</a> and the <a href="https://dvcs.w3.org/hg/AB/raw-file/80f98ce79b35/cover.html">18 July 2016 draft</a>:</h3>
+ <h3>Between the <a href="https://dvcs.w3.org/hg/AB/raw-file/9827cf0fed91/cover.html">28 July 2016 draft</a> and the
+ <a href="https://dvcs.w3.org/hg/AB/raw-file/80f98ce79b35/cover.html">18 July 2016 draft</a>:</h3>
<ul>
<li>Further editorial clarification that an Obsolete Recommendation can be "unobsoleted"
@@ -2778,7 +2962,8 @@
- <a href="#CharterReview">5.2.3</a>, <a href="#cfp">5.2.4</a>, and <a href="#WGCharter">5.2.6</a>.</li>
</ul>
- <h3>Between the <a href="https://dvcs.w3.org/hg/AB/raw-file/80f98ce79b35/cover.html">18 July 2016 draft</a> and the <a href="https://dvcs.w3.org/hg/AB/raw-file/f070f753bcea/cover.html">10 July 2016 draft</a>:</h3>
+ <h3>Between the <a href="https://dvcs.w3.org/hg/AB/raw-file/80f98ce79b35/cover.html">18 July 2016 draft</a> and the
+ <a href="https://dvcs.w3.org/hg/AB/raw-file/f070f753bcea/cover.html">10 July 2016 draft</a>:</h3>
<ul>
<li>Editorial clarification of the status of an Obsolete Recommendation - section <a href="#rec-rescind">6.9</a></li>