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