- From: Maciej Stachowiak via cvs-syncmail <cvsmail@w3.org>
- Date: Mon, 20 Jun 2011 06:45:34 +0000
- To: public-html-commits@w3.org
Update of /sources/public/html5/decision-policy
In directory hutz:/tmp/cvs-serv22615
Modified Files:
decision-policy-v2.html
Log Message:
Address "Editorial comments on Decision Policy, Part 1"
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12992
Index: decision-policy-v2.html
===================================================================
RCS file: /sources/public/html5/decision-policy/decision-policy-v2.html,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -d -r1.32 -r1.33
--- decision-policy-v2.html 20 Jun 2011 06:29:33 -0000 1.32
+++ decision-policy-v2.html 20 Jun 2011 06:45:32 -0000 1.33
@@ -29,9 +29,20 @@
<section>
<h2>1. Introduction</h2>
-<p>For products of the HTML Working Group, particularly HTML5, we expect a high volume of Last Call comments. We expect most comments can be resolved in a satisfactory way by the editor of the affected draft. However, there are a few reasons we need to formalize our process a little bit. First, we are required by W3C Process to track and formally respond to all Last Call comments, and to produce a disposition of comments document in order to exit Last Call. Second, some comments will not be satisfactory as initially fielded by the editor, and will need to be resolved by a decision of the Working Group. Third, it needs to be very clear to commenters how to get their input formally considered.</p>
+<p>For products of the HTML Working Group, particularly HTML5, we
+expect a high volume of Last Call comments. We expect most comments
+can be resolved in a satisfactory way by the Editor of the affected
+draft. However, there are a few reasons we need to formalize our
+process a little bit. First, we are required by W3C Process to track
+and formally respond to all Last Call comments, and to produce a
+disposition of comments document in order to exit Last Call. Second,
+some commenters may not be satisfied by how their Last Call or
+pre-Last Call comment is initially proceed by the Editor, and the
+commentwill need to be resolved by a decision of the Working
+Group. Third, it needs to be very clear to commenters how to get their
+input formally considered.</p>
-<p>Non-members are encouraged to join the working group so they can
+<p>Non-members are encouraged to join the Working Group so they can
fully participate in this process. But extenuating circumstances for
not joining the group will be considered by the Chairs on a
case-by-case basis.</p>
@@ -46,12 +57,16 @@
<ul id=toc>
<li><a href="#overview">3. Overview of Comment Processing</a> - Summary of how to submit and track comments to the HTML WG.</li>
-<li><a href="#basic">4. Basic Process</a> - The bugzilla-based process by which feedback is initially submitted and considered by Editors.</li>
-<li><a href="#escalation">5. Escalation Process</a> - The tracker-based process by which commenters can escalate issues for consideration by the full Working Group.</li>
+<li><a href="#basic">4. Basic Process</a> - The Bugzilla-based process by which feedback is initially submitted and considered by Editors.</li>
+
+<li><a href="#escalation">5. Escalation Process</a> - The
+Tracker-based process by which commenters can escalate comments to
+Issues for consideration by the full Working Group.</li>
+
<li><a href="#cp-review-process">6. Change Proposal Review Process</a> - The process by which Chairs review Change Proposals.</li>
-<li><a href="#lc-review">7. Last Call and Pre-Last Call Review Process</a> - The meta-process by which the Group drives an LC or Pre-LC Review.</li>
+<li><a href="#lc-review">7. Last Call and Pre-Last Call Review Process</a> - The meta-process by which the Working Group drives an LC or Pre-LC Review.</li>
<li><a href="#reopening">8. Requests for a Decision to be Reopened Based on New Information</a> - The process by which Working Group members may ask to have a decision reopened, if they believe they have relevant new information.</li>
-<li><a href="#enhanced-cc">9. Enhanced Change Control</a> - The policy for enhanced change control and revert requests after pre-LC cutoff dates and during LC review.</li>
+<li><a href="#enhanced-cc">9. Enhanced Change Control</a> - The policy for enhanced change control and revert requests after specific pre-LC cutoff dates and during LC review.</li>
</ul>
@@ -61,17 +76,12 @@
<section>
<h2 id=overview>3. Overview of Comment Processing</h2>
-<p>While the primary purpose of this process is for Last Call, we'd
-like to start on the process of migrating the Working Group over to
-the process right away. We've already informally been asking
-commenters to follow some of these steps.</p>
-
<p>The way we will make decisions involves two subprocesses:
the <a href="#basic">Basic Process</a> and
the <a href="#escalation">Escalation Process</a>. The Basic Process
works primarily through Bugzilla; we believe most comments on drafts
can be addressed this way, without the need to involve the full
-working group. For some issues though, the input of the full Working
+Working Group. For some comments though, the input of the full Working
Group will be needed. Throughout these processes, we will rely on
three types of entities to make progress. Some of these will require a
Working Group member to do some work. These processes will be applied
@@ -83,21 +93,21 @@
<ul>
<li><b>Bugzilla bugs:</b> These record a problem, and are given an
-initial disposition by the editor of the affected spec. If you want to
+initial disposition by the Editor of the affected spec. If you want to
report a problem, you should expect that you will have to file
-bugzilla bugs, or convince someone else to do so. Details
-of <a href="#bugzilla-bug">what should go in a bug</a> are explained
+Bugzilla bugs, or convince someone else to do so. Details
+of <a href="#Bugzilla-bug">what should go in a bug</a> are explained
below.</li>
-<li><b>Tracker Issues:</b> These record that an editor's resolution
+<li><b>Tracker Issues:</b> These record that an Editor's Resolution
was not satisfactory, and so the full Working Group must address the
-issue. Action items and informational updates go here. If you are
-unhappy with the way an editor addressed a bugzilla bug, you should be
-prepared to request escalation to a tracker issue.</li>
+comment. Action items and informational updates go here. If you are
+unhappy with the way an Editor addressed a Bugzilla bug, you should be
+prepared to request escalation to a Tracker Issue.</li>
<li><b>Change Proposals:</b> These documents will describe and justify
a particular proposed spec change. They are needed to make progress on
-resolving issue tracker issues. If you want to have an issue addressed
+resolving Tracker Issues. If you want to have an issue addressed
after escalation, you should expect that you will have to write a
Change Proposal, or convince someone else to do so. Details
of <a href="#change-proposal">what should go in a Change Proposal</a>
@@ -110,10 +120,10 @@
<section>
<h2 id="basic">4. Basic Process</h2>
-<p>The Basic Process describes the overall handling of an issue; we
+<p>The Basic Process describes the overall handling of a comment; we
believe most steps can be handled without close involvement of the
Chairs or the Working Group as a whole. We expect most comments will
-be disposed reasonably by the editor of the relevant spec. For issues
+be disposed reasonably by the Editor of the relevant spec. For issues
that need full Working Group consideration, this process refers to the
Escalation Process.</p>
@@ -122,30 +132,30 @@
<dl>
<dt>0. (Optional) Email</dt>
-<dd>Issues can be brought up initially by email, if discussion is
-needed before the issue is clear enough to file a bug. Commenters may
+<dd>Comments can be brought up initially by email, if discussion is
+needed before the problem is clear enough to file a bug. Commenters may
go directly to the next step if they are very clear on their issue
already.</dd>
<dt id="basic-step-1">1. Bugzilla Bug</dt>
-<dd><p>Issues should
+<dd><p>Comments should
be <a href="http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG">filed
as bugs in W3C Bugzilla</a> to be formally considered. If the
commenter has difficulties filing a bug, the best approach is to email
the comment
to <a href="mailto:public-html-comments@w3.org">public-html-comments@w3.org</a>,
and one of the Chairs or a volunteer will assist them. Bugs will be
-initially assigned to the editor of the relevant draft. Although
-editors may field issues through other forums if they wish, we will
-require editors to address all bugzilla bugs. We need bugs to be in
-bugzilla to ensure that nothing is dropped on the floor, and to be
+initially assigned to the Editor of the relevant draft. Although
+Editors may field comments through other forums if they wish, we will
+require Editors to address all Bugzilla bugs. We need bugs to be in
+Bugzilla to ensure that nothing is dropped on the floor, and to be
able to produce the disposition of comments directly from the bug
-tracker. A bug report is most useful if it includes the following
+Tracker. A bug report is most useful if it includes the following
components:</p>
-<ul id="bugzilla-bug">
+<ul id="Bugzilla-bug">
<li>A clear statement of a problem with the spec—bug reports are more useful if they identify concrete problems.</li>
- <li>Only one issue—please use separate bugs for separate issues.</li>
+ <li>Only one specific problem—please use separate bugs for separate problems with the spec.</li>
<li>An indication of what section or sections of the spec are affected.</li>
<li>At least one suggested way to solve the problem. Optionally, this can include sample spec text. Listing multiple alternatives is ok, and even a vague suggestion is fine at this stage.</li>
</ul>
@@ -159,7 +169,7 @@
<dt id="basic-step-2">2. Editor's Response</dt>
<dd><p>Editors will give an initial disposition to incoming bugs. When
-an editor gives the initial editor's response, he or she should
+an Editor gives the initial Editor's response, he or she should
include the following:</p>
<ul>
@@ -175,10 +185,10 @@
<pre>
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
-you have additional information and would like the editor to reconsider, please
+you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
-title and text for the tracker issue; or you may create a tracker issue
+title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:</p>
http://dev.w3.org/html5/decision-policy/decision-policy.html
@@ -195,21 +205,21 @@
<p>For some particular bug resolutions, a full Editor's Response is
not necessary, and it may be appropriate for someone other than the
-editor of the relevant draft to resolve the bug. The table below
+Editor of the relevant draft to resolve the bug. The table below
documents the bug resolutions, and expectations for each:</p>
<table id="bug-resolutions">
<tr><th>Resolution</th><th>Description</th></tr>
<tr><td>FIXED</td><td>Accepted or partially accepted. Spec was
-changed. Editor's resolution and diff link are required. Rationale
+changed. Editor's Resolution and diff link are required. Rationale
should explain the reason for accepting the comment. It may simply
cite agreement with arguments in a previous bug comment.</td></tr>
<tr><td>WORKSFORME</td><td>Accepted, but no spec change. The spec already
addresses the comment due to a previous change. Editor's response
required, but the rationale just needs to point to the previous change
or existing spec text that addresses the comment. A resolution may be
-entered by someone other than the editor if they can explain why the
-spec already addresses the issue.</td></tr>
+entered by someone other than the Editor if they can explain why the
+spec already addresses the comment.</td></tr>
<tr><td>NEEDSINFO</td><td>Additional information is required to accept
or reject this comment. Editor's response required. Editor should be
clear on what additional info is required. It is strongly recommended
@@ -224,23 +234,23 @@
<tr><td>REMIND</td><td>Do not use this resolution.</td></tr>
<tr><td>INVALID</td><td>Bug is obvious junk or spam. Or, originator
decides upon reconsideration that the comment is wrong. Does not
-require a full editor's response.</td></tr>
-<tr><td>DUPLICATE</td><td>Bug is the same issue as another bug. Does not require a full
-editor's response.</td></tr>
+require a full Editor's response.</td></tr>
+<tr><td>DUPLICATE</td><td>Bug is reporting the same problem as another bug. Does not require a full
+Editor's response.</td></tr>
</table>
</dd>
<dt>3. Verify Response Info</dt>
<dd>Once bugs are RESOLVED, we will ask volunteers, including Team
Contacts, to make sure they include all of the needed components of an
-editor's response, and to add any that are missing. Once this is done,
+Editor's response, and to add any that are missing. Once this is done,
the bug should move to the VERIFIED state.</dd>
<dt>4. Commenter Satisfied?</dt>
-<dd> At this point in the process, the commenter should review the editor's response, and choose one of the following Step 5 actions. The commenter has two weeks to take action from the time the bug is put in VERIFIED state.</dd>
+<dd> At this point in the process, the commenter should review the Editor's response, and choose one of the following Step 5 actions. The commenter has two weeks to take action from the time the bug is put in VERIFIED state.</dd>
<dt>5.a. Yes: Close Bug</dt>
-<dd>If the commenter is satisfied with the editor's response, the
+<dd>If the commenter is satisfied with the Editor's response, the
commenter should indicate that by changing the bug state to
CLOSED. <b>** This is an endpoint for the process. **</b></dd>
@@ -253,54 +263,54 @@
<dt>5.c. Want Reconsideration: Reopen Bug</dt>
<dd>If the commenter feels they have new information or arguments, or
-that the editor overlooked something, and would like the editor to
+that the Editor overlooked something, and would like the Editor to
reconsider, it's ok to move the bug to the REOPENED state. Commenters
should exercise reasonable judgment on whether to use this option or
5.d., in particular, it's usually not a good idea to repeatedly reopen
the same bug. Note: A bug may be reopened by anyone who is
dissatisfied with the resolution, not just the original
-commenter. Once reopened, the issue returns
+commenter. Once reopened, the comment returns
to <a href="#basic-step-1">step 1</a>.</dd>
<dt id="basic-step-5d">5.d. No: Escalate to Issue</dt>
<dd><p>If the commenter is dissatisfied with the resolution and does
-not believe it is productive to ask the editor to reconsider, he or
-she may ask to escalate the issue to the issue tracker. A commenter
+not believe it is productive to ask the Editor to reconsider, he or
+she may ask to escalate the comment to the issue Tracker. A commenter
with Tracker access can raise an Issue directly. A commentor without
-tracker access should apply the TrackerRequest keyword, and should
-suggest a title and text for the tracker issue. Team contacts or other
-volunteers with access will move TrackerRequest issues into the
-tracker. Note: A bug may be escalated by anyone who is dissatisfied
+Tracker access should apply the TrackerRequest keyword, and should
+suggest a title and text for the Tracker Issue. Team contacts or other
+volunteers with access will move TrackerRequest bugs into the
+Tracker. Note: A bug may be escalated by anyone who is dissatisfied
with the resolution, not just the original commenter. </p>
-<p>The issue tracker issue should reference the original bugzilla
-bug. The bugzilla bug will reference the issue and have the
+<p>The Tracker Issue should reference the original Bugzilla
+bug. The Bugzilla bug will reference the issue and have the
TrackerIssue keyword added.</p>
<p><b>Note:</b> comments with additional information may still be added to a
-bugzilla bug after it has been escalated to the tracker.</p>
+Bugzilla bug after it has been escalated to the Tracker.</p>
<p><b>Clarification:</b>It's not correct per this policy to both
-escalate a bug to the tracker <em>and</em> reopen it. Only one of
+escalate a bug to the Tracker <em>and</em> reopen it. Only one of
these two actions should be taken. Reopen the bug if you would like
-the editor to give it fresh consideration; escalate it if you'd like
-to move beyond the editor's response and get consideration from the
+the Editor to give it fresh consideration; escalate it if you'd like
+to move beyond the Editor's response and get consideration from the
full Working Group.</p></dd>
<dt>5.e. No, But Willing to Concede: Close Bug and mark Disagree</dt>
-<dd>If the commenter is unsatisfied with the editor's response, but
-does not wish to pursue the issue further by escalating or reopeneing,
+<dd>If the commenter is unsatisfied with the Editor's response, but
+does not wish to pursue the comment further by escalating or reopeneing,
the commenter should indicate that by changing the bug state to
CLOSED and add the Disagree keyword. <b>** This is an endpoint for the process. **</b></dd>
<dt>6. Working Group Decision</dt>
-<dd>Issues escalated to the tracker will be decided by Working Group Decision. The <a href="#escalation">Escalation Process</a> describes how Working Group decisions are made.</dd>
+<dd>Issues escalated to the Tracker will be decided by Working Group Decision. The <a href="#escalation">Escalation Process</a> describes how Working Group decisions are made.</dd>
<dt id="basic-step-7a">7.a. Affirm Editor's Response</dt>
-<dd>The Working Group Decision that results from the Escalation Process may be to affirm the editor's response. In this case proceed to <a href="#basic-step-8">step 8</a>.</dd>
+<dd>The Working Group Decision that results from the Escalation Process may be to affirm the Editor's response. In this case proceed to <a href="#basic-step-8">step 8</a>.</dd>
<dt id="basic-step-7b">7.b. Overrule Editor's Response</dt>
-<dd>The Working Group Decision that results from the Escalation Process may be to overrule the editor's response. In this case proceed to <a href="#basic-step-10">step 10</a>.</dd>
+<dd>The Working Group Decision that results from the Escalation Process may be to overrule the Editor's response. In this case proceed to <a href="#basic-step-10">step 10</a>.</dd>
<dt id="basic-step-8">8. Does Commenter Wish to Formally Object?<dt>
<dd>The commenter should decide at this point if they wish to enter a Formal Objection against the Working Group decision.</dd>
@@ -311,7 +321,7 @@
stating that it is a Formal Objection, as well as giving a technical
justification for the objection, and at least one way the objection
could be removed. The Formal Objection should be recorded in the
-bugzilla bug, and the bug should be placed in the CLOSED state and
+Bugzilla bug, and the bug should be placed in the CLOSED state and
tagged with the FormalObjection keyword. <b>** This is an endpoint for
the process. **</b></dd>
@@ -325,7 +335,7 @@
<dt id="basic-step-10">10. Tag Bug as WG Decision and Reopen</dt>
<dd>The bug is reopened indicating the WG decision, and tagged with
the WGDecision keyword. The bug is then returned to REOPENED state for
-action by the editor to implement the Working Group decision, which
+action by the Editor to implement the Working Group decision, which
will be recorded in the form of a <a href="#change-proposal">Change
Proposal</a>. The process returns to <a href="#basic-step-1">step
1</a>.</dd>
@@ -339,16 +349,16 @@
<table id="states-and-keywords">
<tr><th>State and Keywords</th> <th>Meaning</th></tr>
-<tr><td>UNCONFIRMED, NEW, ASSIGNED, REOPENED</td> <td>Waiting for editor response.*</td></tr>
-<tr><td>REOPENED and WGDecision</td> <td>Waiting for editor to implement Working Group decision.*</td></tr>
-<tr><td>RESOLVED</td><td>Editor has addressed issue, waiting for review by verifier.*</td></tr>
+<tr><td>UNCONFIRMED, NEW, ASSIGNED, REOPENED</td> <td>Waiting for Editor response.*</td></tr>
+<tr><td>REOPENED and WGDecision</td> <td>Waiting for Editor to implement Working Group decision.*</td></tr>
+<tr><td>RESOLVED</td><td>Editor has addressed comment, waiting for review by verifier.*</td></tr>
<tr><td>VERIFIED (and none of the below)</td><td>Waiting for response from commenter.*</td></tr>
<tr><td>VERIFIED and TrackerRequest</td><td>Reporter requested escalated to Working Group. Waiting for mechanics of escalation.*</tr>
<tr><td>VERIFIED and TrackerIssue</td><td>Reporter escalated to Working Group. Waiting for Working Group decision.*</tr>
<tr><td>CLOSED and NoReply</td><td>Reporter has not responded after two weeks or more.</td></tr>
-<tr><td>CLOSED and FormalObjection</td><td>The issue is settled, and reporter formally objected to WG.</td></tr>
-<tr><td>CLOSED and Disagreed</td><td>The issue is settled, and the reporter disagreed, but not as Formal Objection</td></tr>
-<tr><td>CLOSED (and none of those)</td><td>The issue is settled, and the reporter agreed with the final outcome.</td></tr>
+<tr><td>CLOSED and FormalObjection</td><td>The Tracker Issue is settled, and reporter formally objected to WG.</td></tr>
+<tr><td>CLOSED and Disagreed</td><td>The Tracker Issue is settled, and the reporter disagreed, but not as Formal Objection</td></tr>
+<tr><td>CLOSED (and none of those)</td><td>The Tracker Issue is settled, and the reporter agreed with the final outcome.</td></tr>
</table>
</section>
@@ -359,8 +369,8 @@
<p>Some issues cannot be settled solely through the Basic Process. In
such cases, a party to the dispute will request escalation to
-the <a href="http://www.w3.org/html/wg/tracker/"> Issue
-Tracker</a>. Once issues are in the tracker, we will use a system of
+the <a href="http://www.w3.org/html/wg/Tracker/"> Issue
+Tracker</a>. Once issues are in the Tracker, we will use a system of
Change Proposals to come to a decision.</p>
<p><img src="escalation-process-v2.png" alt="Flowchart illustrating the process described below."><br>
@@ -378,7 +388,7 @@
for the escalation process. **</b></dd>
<dt id="escalation-step-1">1. Raised Issue: Chairs Solicit Proposals<dt>
-<dd><p>When an issue enters it starts in the RAISED state. The chairs
+<dd><p>When an issue enters it starts in the RAISED state. The Chairs
solicit volunteers to write Change Proposals when the issue is
raised. For pre-existing issues, we will ask for volunteers in a
staggered fashion to avoid flooding the group. Requests for Change
@@ -397,16 +407,16 @@
<dt id="escalation-step-2a">2.a. Closed without Prejudice</dt>
<dd>If no one volunteers within a month of the Chairs' request, or a
Change Proposal is not presented by the deadline, the Tracker Issue
-will be marked POSTPONED in the tracker without prejudice and presumed
+will be marked POSTPONED in the Tracker without prejudice and presumed
deferred to the next version of HTML. In this case, we affirm the
-editor's decision by default. The Basic Process then proceeds
+Editor's decision by default. The Basic Process then proceeds
from <a href="#basic-step-7a">step 7a</a>. An issue that is closed
without prejudice in this way can only be re-raised with approval of
the Chairs. <b>** This is an endpoint for the escalation
process. **</b> </dd>
<dt id="escalation-step-2b">2.b. Open Issue: Writing a Change Proposal</dt>
-<dd> An issue with someone working on a change proposal is in the OPEN state. If the change proposal is not done by the deadline, the issue will be marked POSTPONED in the tracker without prejudice and presumed deferred to the next version of HTML. The default deadline to complete a Change Proposal is one month from the time someone volunteers. The chairs may grant a longer deadline for complex issues on request. A proper Change Proposal must include the following four components:
+<dd> An issue with someone working on a change proposal is in the OPEN state. If the change proposal is not done by the deadline, the issue will be marked POSTPONED in the Tracker without prejudice and presumed deferred to the next version of HTML. The default deadline to complete a Change Proposal is one month from the time someone volunteers. The Chairs may grant a longer deadline for complex issues on request. A proper Change Proposal must include the following four components:
<ol id="change-proposal">
<li>Summary: Describes the change in about 1-5 paragraphs of plain language.</li>
<li>Rationale: Describes the reason for the change. What problems
@@ -418,7 +428,7 @@
<li>A set of edit instructions, specific enough that they can be applied without ambiguity.</li>
<li>Spec text for a draft to be published separate from HTML5 (though such a draft can be proposed at any time without a Change Proposal).</li>
<li>Exact spec text for the sections to be changed, and a baseline revision for the version of the spec being changed.</li>
- <li>With prior permission from the chairs, a high-level prose description of the changes to be made.</li>
+ <li>With prior permission from the Chairs, a high-level prose description of the changes to be made.</li>
</ul>
<li>Impact: Effects, both positive and negative, of the change. What conformance classes will have to change? What are the risks?</li>
</ol>
@@ -440,10 +450,10 @@
strongly encouraged to seek consensus and revise their Change
Proposals to gain more support. Change Proposals that do not see wide
support are unlikely to succeed. Once an outcome is clear or no more
-productive discussion is happening, the chairs proceed to the next
-step. If consensus on a proposal is clear, the chairs may issue a Call
+productive discussion is happening, the Chairs proceed to the next
+step. If consensus on a proposal is clear, the Chairs may issue a Call
for Consensus (<a href="#escalation-step-4a">step 4.a</a>). If there
-are obvious objections or other alternatives, the chairs may instead
+are obvious objections or other alternatives, the Chairs may instead
issue a Call for Alternate Proposals
(<a href="#escalation-step-4.b">step 4.b</a>).</p>
@@ -456,9 +466,9 @@
<p>
<b>Note:</b> Editors may make changes that impact an issue under
-discussion, but that the editor is expected to identify on the mailing
+discussion, but that the Editor is expected to identify on the mailing
list any changes that may affect submitted Change Proposals. If there
-is an issue but no pending Change Proposal, then the editor is
+is an issue but no pending Change Proposal, then the Editor is
encouraged but not required to identify changes that may affect the
issue. In the case of some issues, it may be difficult to even
identify what changes would affect it without seeing a Change
@@ -467,11 +477,11 @@
</dd>
<dt id="escalation-sep-4.a">4.a. Call for Consensus</dt>
-<dd>If the chairs believe it is clear that the existing spec or
+<dd>If the Chairs believe it is clear that the existing spec or
some available Change Proposal enjoys consensus, they issue a Call for
Consensus to solicit objections. Based on the response, proceed to the
appropriate substep of step 5. If there is not enough clarity to make
-such a Call in the first place, the chairs may proceed directly to
+such a Call in the first place, the Chairs may proceed directly to
<a href="#escalation-step-5b">step 5.b</a> without a Call for Consensus.</dd>
<dt id="escalation-sep-4.b">4.b. Call for Alternate Proposals</dt>
@@ -502,9 +512,9 @@
<dt>5.a. Consensus Found</dt>
<dd>If there are no objections, very few (and weak) objections, or
-objections can be resolved, the chairs declare that the Call for
+objections can be resolved, the Chairs declare that the Call for
Consensus becomes a resolution. The Working Group affirms or overrules
-the editor's decision depending on the outcome. When reviewing the
+the Editor's decision depending on the outcome. When reviewing the
results of a survey, the Chairs will examine the Change Proposals, the
survey responses themselves, and any material linked from a survey
response. The Chairs do not guarantee that any other material, such as
@@ -516,16 +526,16 @@
<dt id="escalation-step-5b">5.b. No Clear Consensus</dt>
<dd>If there are numerous and/or serious objections, or if it is
-unclear to the chairs what the position of the working group is, the
-chairs may use a poll to get a sense of the working group.</dd>
+unclear to the Chairs what the position of the Working Group is, the
+Chairs may use a poll to get a sense of the Working Group.</dd>
<dt>6. Poll or Vote</dt>
<dd>A WG decision may be entered based on an informative straw poll as
one piece of input, or based on a formal and binding vote. Or the
-chairs can ask for a new round of proposals if the poll does not
+Chairs can ask for a new round of proposals if the poll does not
reveal a strongly preferred position; in this case, return
to <a href="#escalation-step-3">step 3</a>. Otherwise, the Working
-Group affirms or overrules the editor's decision depending on the
+Group affirms or overrules the Editor's decision depending on the
outcome. In that case, the Chairs will strive to identify the proposal
that draws the weakest objections, taking under consideration
objections raised in the straw poll, reasoning in the Change Proposals
@@ -599,7 +609,7 @@
<p>Eventually, drafts become mature enough that they are ready to
advance through the W3C Process. Given that drafts may see an ongoing
-significant influx of comments, once the draft is close, the chairs
+significant influx of comments, once the draft is close, the Chairs
will establish a timetable to aid progress to the next milestone. For
Pre-Last Call Review by the Working Group, the timetable defines the
process to get to Last Call. For Last Call Review by the broader
@@ -624,7 +634,7 @@
<dt id="lc-review-step-2">2. Review Period Begins</dt>
<dd>
At this point, the Working Group issues a solicitation for review
-comments. Review comments are to be submitted in bugzilla, per
+comments. Review comments are to be submitted in Bugzilla, per
the <a href="#basic">Basic Process</a>.
</dd>
@@ -652,7 +662,7 @@
</dd>
<dt id="lc-review-step-5">5. Deadline for Escalating Comments</dt>
-<dd>Within two weeks of the editor's response deadline, or a different
+<dd>Within two weeks of the Editor's response deadline, or a different
period as determined by the Chairs in consultation with the Editors
and the Working Group, all bugs from the review period must
be <a href="basic-step-5d">Escalated to Issues</a> if the commentor or
@@ -840,7 +850,7 @@
<ul>
<li>We do not expect this process to be used casually over random
changes. Anyone asking for this would have to convince the
-chairs that the change reduces consensus.</li>
+Chairs that the change reduces consensus.</li>
<li>We think there is little chance of this process being used to
revert a fix for a UA behavior bug, because (a) that is not the sort
@@ -860,7 +870,7 @@
standards, islikely to be controversial. Editors are strongly
encouraged to preflight any addition of willful violations with the
HTML Working Group as well as with any other affected Working
-Groups. HTML WG members, even non-editors, are encouraged to notify
+Groups. HTML WG members, even non-Editors, are encouraged to notify
other Working Groups of changes of this type.</li>
<li>If a change is preflighted with the group, via a bug with
@@ -897,7 +907,7 @@
<li>If a spec change that gets reverted was based on a bug, the bug
effectively goes WONTFIX. It would have to be owned by and given a
-rationale by the Chairs, since it wouldn't be the editor's choice to
+rationale by the Chairs, since it wouldn't be the Editor's choice to
revert. This bug could be escalated through the normal channels by
those who wish to reinstate the reverted change.</li>
Received on Monday, 20 June 2011 06:45:42 UTC