Made the SHOULD document known implementation a requirement at every transition level. ISSUE-38
authorcharles
Wed, 18 Sep 2013 17:26:32 -0400
changeset 20 2571dd7597b3
parent 19 83147ea1de14
child 21 b491807959c9
Made the SHOULD document known implementation a requirement at every transition level. ISSUE-38
tr.html
--- a/tr.html	Wed Sep 18 17:23:07 2013 -0400
+++ b/tr.html	Wed Sep 18 17:26:32 2013 -0400
@@ -21,7 +21,7 @@
           Patent Policy</a> [<a href="http://www.w3.org/2005/10/Process-20051014/refs.html#ref-patentpolicy">PUB33</a>]
        as "Last Call Working Draft"</dd>
      <dd class="new"><strong>Note:</strong> Last Call Candidate Recommendations
        will normally be accepted 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><a name="RecsW3C" id="RecsW3C">W3C Recommendation (REC)</a></dt>
      <dd>A W3C Recommendation is a specification or set of normative guidelines
        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.</dd>
      <dt><a name="WGNote" id="WGNote">Working Group Note, Interest Group Note
          (NOTE) </a></dt>
      <dd>A Working Group Note or Interest Group Note is published by a
        chartered Working Group or Interest Group to <span class="new">provide
          a stable reference for some document that is not intended to be a
          normative specification, but is nevertheless useful. For example,
          supporting documents such as Use case and Requirements documents, or
          Design Principles, that explain what the Working Group was trying to
          achieve with a specification, or non-normative 'Good Practices"
          documents.</span> A Working Group <em class="rfc2119">may</em> also
        publish a specification as a Note if they stop work without producing a
        Recommendation. <span class="changed">A Working Group or Interest Group</span>
        <em class="rfc2119">may</em> <span class="from">(was "W3C" in 7.1.4)</span>
        publish a Note with or without its prior publication as a Working Draft.</dd>
      <dt><a name="RescindedRec" id="RescindedRec">Rescinded Recommendation</a></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="http://www.w3.org/2005/10/Process-20051014/refs.html#ref-patentpolicy">PUB33</a>].</dd>
    </dl>
    <p class="new">Working Groups and Interest Groups <em class="rfc2119">may</em>
      publish "Editor's drafts". Editor's drafts have no official standing
      whatsoever, and do not imply consensus of a Working Group or Interest
      Group, nor are their contents endorsed in any way by W3C or its members,
      except to the extent that such contents happen to be consistent with some
      other document which carries a higher level of endorsement.</p>
    <h3>7.2 <a name="transition-reqs" id="transition-reqs">General Requirements
        for Advancement on the Recommendation Track</a></h3>
    <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> <span class="from">(was in 7.2)</span>
        record the group's decision to request advancement.</li>
      <li><em class="rfc2119">must </em><span class="from">(was repeated in
          maturity levels)</span> obtain Director approval.</li>
      <li><em class="rfc2119 ">must</em> <span class="from">(was in 7.2)</span>
        provide public documentation of all substantive to the technical report
        since the previous step. A <dfn id="substantive-change">substantive
          change</dfn> (whether deletion, inclusion, or other modification) is
        one where someone could reasonably expect that making the change would
        invalidate an individual's review or implementation experience. Other
        changes (e.g., clarifications, bug fixes, editorial repairs, and minor
        error corrections) are minor changes. The community also appreciates
        public documentation of minor changes.</li>
      <li><em class="rfc2119">must</em> <a href="http://www.w3.org/2005/10/Process-20051014/policies.html#formal-address">formally
           address</a> <span class="from">(was in 7.2)</span> all issues raised
        about the document since the previous maturity level.</li>
      <li><em class="rfc2119">must</em> <span class="from">(was in 7.2)</span>
        provide <span class="new">public</span> documentation of any <a href="http://www.w3.org/2005/10/Process-20051014/policies.html#FormalObjection">Formal
-          Objections</a>.</li>
      <li><em class="rfc2119 changed">should</em> <span class="from">(was must
          for CR+ in 7.2)</span> report which, if any, of the Working Group's
        requirements for this document have changed since the previous step.</li>
      <li><em class="rfc2119 changed">should</em> <span class="from">(was must
          for CR+ in 7.2)</span> report any changes in dependencies with other
        groups.</li>
    </ul>
    <h4>7.2.2 <a id="wide-review">Wide Review</a></h4>
    <p>The requirements for wide review are not precisely defined by the
      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 and thereby an opportunity to comment
      on the specification. Before approving transitions, the Director will
      consider who has actually reviewed the document and provided comments,
      particularly in light of the listed dependencies, and how the Working
      Group has solicited and responded to review. In particular, the Director
      is likely to consider the record of requests to and responses from groups
      identified as dependencies in the charter, as well as seeking evidence of
      clear communication to the general public about appropriate times and
      which content to review. </p>
    <p>As an example, inviting review of new or significantly revised sections
      published in Heartbeat 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. A recommended practice is
      making a specific announcement to other W3C Working Groups as well as the
      general public that a group proposes to enter Last Call Candidate
      Recommendation in e.g. 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.3 Implementation Experience</h4>
    <p>Implementation experience is required to show that a specification is
      sufficiently clear, complete, and relevant to market needs 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 adequate implementation
      experience the Director will consider (though not be limited to):</p>
    <ul>
      <li>is each feature implemented, and how is this demonstrated; (for
        example, is there a test suite)?</li>
      <li>are there independent interoperable implementations?</li>
      <li>are there implementations created by 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 (creation, consuming, publishing…)?</li>
    </ul>
    <h3>7.3 <a name="doc-reviews" id="doc-reviews">Reviews and Review
        Responsibilities</a></h3>
    <p>A document is available for review from the moment it is first published.
      Working Groups <em class="rfc2119">should</em> <a href="http://www.w3.org/2005/10/Process-20051014/policies.html#formal-address">formally
+          Objections</a>.</li>
      <li><em class="rfc2119 changed">should</em> <span class="from">(was must
          for CR+ in 7.2)</span> report which, if any, of the Working Group's
        requirements for this document have changed since the previous step.</li>
      <li><em class="rfc2119 changed">should</em> <span class="from">(was must
          for CR+ in 7.2)</span> report any changes in dependencies with other
        groups.</li>
      <li class="new"><em class="rfc2119">should</em> document known
        implementation.</li>
    </ul>
    <h4>7.2.2 <a id="wide-review">Wide Review</a></h4>
    <p>The requirements for wide review are not precisely defined by the
      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 and thereby an opportunity to comment
      on the specification. Before approving transitions, the Director will
      consider who has actually reviewed the document and provided comments,
      particularly in light of the listed dependencies, and how the Working
      Group has solicited and responded to review. In particular, the Director
      is likely to consider the record of requests to and responses from groups
      identified as dependencies in the charter, as well as seeking evidence of
      clear communication to the general public about appropriate times and
      which content to review. </p>
    <p>As an example, inviting review of new or significantly revised sections
      published in Heartbeat 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. A recommended practice is
      making a specific announcement to other W3C Working Groups as well as the
      general public that a group proposes to enter Last Call Candidate
      Recommendation in e.g. 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.3 Implementation Experience</h4>
    <p>Implementation experience is required to show that a specification is
      sufficiently clear, complete, and relevant to market needs 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 adequate implementation
      experience the Director will consider (though not be limited to):</p>
    <ul>
      <li>is each feature implemented, and how is this demonstrated; (for
        example, is there a test suite)?</li>
      <li>are there independent interoperable implementations?</li>
      <li>are there implementations created by 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 (creation, consuming, publishing…)?</li>
    </ul>
    <h3>7.3 <a name="doc-reviews" id="doc-reviews">Reviews and Review
        Responsibilities</a></h3>
    <p>A document is available for review from the moment it is first published.
      Working Groups <em class="rfc2119">should</em> <a href="http://www.w3.org/2005/10/Process-20051014/policies.html#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 <span class="from">(was
      should)</span> are often reluctant to make <a href="#substantive-change">substantive
       changes</a> to a mature document, <span class="new">particularly if this
      would cause significant compatibility problems due to existing
      implementation</span>. Worthy ideas <em class="rfc2119">should</em> be
    recorded even when not incorporated into a mature document.
    <h3>7.4 <a name="rec-advance" id="rec-advance">Advancing a Technical Report
        to Recommendation</a></h3>
    <p>W3C follows these steps when advancing a technical report to
      Recommendation.</p>
    <ol>
      <li><a href="#first-wd">Publication of the First Public Working Draft</a>,</li>
      <li><a href="#hb-wd">Publication of zero or more "Heartbeat" Public
          Working Drafts</a>.</li>
      <li><a href="#last-call">Publication of a Last Call Candidate
          Recommendation</a>.</li>
      <li><a href="#rec-publication">Publication as a Recommendation</a>.</li>
    </ol>
    <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> refuse permission 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-level">maturity level</a>. The Director <em class="rfc2119">must</em>
      <span class="from">(was in 7.4.6)</span> inform the <a href="http://www.w3.org/2005/10/Process-20051014/organization.html#AC">Advisory
         Committee</a> and group Chairs when a technical report has been refused
      permission to advance in maturity level and returned to a Working Group
      for further work.</p>
    <h4>7.4.1.a <a name="first-wd" id="first-wd">First Public Working Draft</a>
    </h4>
    <p>To publish a First Public Working draft, in addition to the general
      requirements for advancement a Working Group</p>
    <ul>
      <li> <em class="rfc2119">should</em> document the extent of consensus on
        the content, and outstanding issues on which the Working Group does not
        have consensus.</li>
      <li> <em class="rfc2119">may</em> request publication of a Working Draft
        even if it is unstable and does not meet all Working Group requirements.</li>
    </ul>
    <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> This publication triggers a patent disclosure request, as per <a href="http://www.w3.org/Consortium/Patent-Policy#sec-disclosure-requests">section
@@ -30,7 +30,7 @@
 4.1
         of the W3C Patent Policy</a> [<a href="http://www.w3.org/2005/10/Process-20051014/refs.html#ref-patentpolicy">PUB33</a>]
      for information about the policy implications of the First Public Working
      Draft. </p>
    <p>Possible next steps:</p>
    <ul>
      <li><a href="#hb-wd">"Heartbeat" Working Draft</a></li>
      <li><a href="#last-call">Last Call - Candidate recommendation</a>.</li>
      <li><a href="#tr-end">Working Group Note</a></li>
    </ul>
    <h4>7.4.1.b <a name="hb-wd" id="hb-wd">"Heartbeat" Working Draft</a></h4>
    <p class="new">A working group <em class="rfc2119">should</em> publish a
      "Heartbeat" Public Working Draft every 6 months, or when there have been
      significant changes to the document that would benefit from review from
      beyond the Working Group<em class="rfc2119"></em>.<span class="from">(was
        must in @@ch4?)</span> </p>
    <p>A Heartbeat Working Draft is not an advancement in maturity level. To
      publish a Heartbeat Working draft, a Working Group <span class="from">(copied
         since this is not a new maturity level)</span> </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>
      <li><em class="rfc2119">should</em> document the extent of consensus on
        the content, and outstanding issues on which the Working Group does not
        have consensus.</li>
      <li><em class="rfc2119">may</em> request publication of a Working Draft
        even if it is unstable and does not meet all Working Group requirements.</li>
    </ul>
    <p>Possible next steps:</p>
    <ul>
      <li><a href="#hb-wd">"Heartbeat" Working Draft</a></li>
      <li><a href="#last-call">Last Call - Candidate recommendation</a>.</li>
      <li><a href="#tr-end">Working Group Note</a></li>
    </ul>
    <h4>7.4.2 <a name="last-call" id="last-call">Last Call Candidate
        Recommendation </a></h4>
    <p>To publish a Last Call Candidate recommendation, in addition to the
      general requirements for advancement 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 class="new"><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 changed">must</em> <span class="from">(was should)</span>
        be at least four weeks after publication, <span class="new">and <em class="rfc2119">should</em>
          be longer for complex documents.</span></li>
      <li class="new">If the document has previously been published as a Last
        Call Candidate Recommendation, <em class="rfc2119">must</em> document
        the changes since the previous Last Call Candidate Recommendation. </li>
      <li class="changed"><em class="rfc2119">must</em> show that the
        specification has received <a href="#wide-review">wide review</a>.</li>
      <li class="new"><em class="rfc2119">should</em> document known
        implementation.</li>
      <li><em class="rfc2119">may</em> identify features in the document that
        are considered "at risk". These features <em class="rfc2119">may</em>
        be removed before advancement to Recommendation without a requirement to
        publish a new Last Call Candidate Recommendation.</li>
    </ul>
    <p>The Director <em class="rfc2119">must</em> announce the publication of a
      Last Call Candidate Recommendation to other W3C groups and to the public.
    </p>
    <p> This publication triggers a patent disclosure request, as per <a href="http://www.w3.org/Consortium/Patent-Policy#sec-disclosure-requests">section
+          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>
      <li><em class="rfc2119">should</em> document the extent of consensus on
        the content, and outstanding issues on which the Working Group does not
        have consensus.</li>
      <li><em class="rfc2119">may</em> request publication of a Working Draft
        even if it is unstable and does not meet all Working Group requirements.</li>
    </ul>
    <p>Possible next steps:</p>
    <ul>
      <li><a href="#hb-wd">"Heartbeat" Working Draft</a></li>
      <li><a href="#last-call">Last Call - Candidate recommendation</a>.</li>
      <li><a href="#tr-end">Working Group Note</a></li>
    </ul>
    <h4>7.4.2 <a name="last-call" id="last-call">Last Call Candidate
        Recommendation </a></h4>
    <p>To publish a Last Call Candidate recommendation, in addition to the
      general requirements for advancement 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 class="new"><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 changed">must</em> <span class="from">(was should)</span>
        be at least four weeks after publication, <span class="new">and <em class="rfc2119">should</em>
          be longer for complex documents.</span></li>
      <li class="new">If the document has previously been published as a Last
        Call Candidate Recommendation, <em class="rfc2119">must</em> document
        the changes since the previous Last Call Candidate Recommendation. </li>
      <li class="changed"><em class="rfc2119">must</em> show that the
        specification has received <a href="#wide-review">wide review</a>.</li>
      <li><em class="rfc2119">may</em> identify features in the document that
        are considered "at risk". These features <em class="rfc2119">may</em>
        be removed before advancement to Recommendation without a requirement to
        publish a new Last Call Candidate Recommendation.</li>
    </ul>
    <p>The Director <em class="rfc2119">must</em> announce the publication of a
      Last Call Candidate Recommendation to other W3C groups and to the public.
    </p>
    <p> This publication triggers a patent disclosure request, as per <a href="http://www.w3.org/Consortium/Patent-Policy#sec-disclosure-requests">section
         6.3</a> of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C
        Patent Policy</a> [<a href="http://www.w3.org/2005/10/Process-20051014/refs.html#ref-patentpolicy">PUB33</a>].
       See also <a href="http://www.w3.org/Consortium/Patent-Policy/#sec-exclusion-with">section
 4.1