- From: Maciej Stachowiak via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 24 Mar 2010 17:49:29 +0000
- To: public-html-commits@w3.org
Update of /sources/public/html5/decision-policy
In directory hutz:/tmp/cvs-serv5024
Added Files:
decision-policy-v2.html
Log Message:
Copy Decision Policy to a separate instance, in preparation for revisions so they can be
kept separate from the working copy.
--- NEW FILE: decision-policy-v2.html ---
<!DOCTYPE html>
<html>
<head>
<title>HTML Working Group Decision Policy</title>
<link href="http://www.w3.org/StyleSheets/TR/W3C-ED" rel="stylesheet" type="text/css">
<meta charset="utf-8">
<style>
article, section {
display: block;
margin: 0px }
#states-and-keywords, #states-and-keywords td, #states-and-keywords th {
border: 2px solid black;
border-collapse: collapse }
</style>
</head>
<body>
<article>
<h1>HTML Working Group Decision Policy</h1>
<section>
<h2>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>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
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
to each separate specification individually.</p>
<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
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
below.</li>
<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>
<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
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>
are found below.</li>
</ul>
</section>
<section>
<h2 id="basic">Basic Process</h2>
<p>The Basic Process describes the overall handling of an issue; 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
that need full Working Group consideration, this process refers to the
Escalation Process.</p>
<p><img src="basic-process.png" alt="Flowchart illustrating the process described below."><br>
<small><a href="basic-process.svg">(SVG version)</a></small></p>
<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 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
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, 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 able to produce the
disposition of comments directly from the bug tracker. A bug report is
most useful if it includes the following components:</p>
<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>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>
<p>
<b>Note:</b> These components are not absolutely mandatory for all bug
reports. But bug reports that do not have enough information to
identify a problem or potential action may be closed as INVALID.
</p>
</dd>
<dt>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 include the following:</p>
<ul>
<li>A change in bug status to RESOLVED.</li>
<li>A clear statement of whether the comment was accepted or rejected.</li>
<li>A rationale for the change or lack of change (at least enough for the Disposition of Comments).</li>
<li>A link to the relevant spec diff or diffs, if the spec was changed.</li>
<li>Boilerplate text advising the commenter how to indicate their reply and escalate if desired.</li>
</ul>
</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,
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>
<dt>5.a. Yes: Close Bug</dt>
<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>
<dt>5.b. (No Response)</dt>
<dd>If the commenter never responds in the bug in any way, after two
weeks will will assume no response is forthcoming, and indicate that
in disposition of comments. At this point the bug will be tagged with
the NoReply keyword. <b>** This is an endpoint for the
process. **</b></dd>
<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
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. The issue then returns to <a href="#basic-step-1">step 1</a>.</dd>
<dt>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 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.</p>
<p>The issue tracker issue should reference the original bugzilla
bug. The bugzilla bug will reference the issue and have the
TrackerIssue keyword added.</p>
<p>Note: comments with additional information may still be added to a
bugzilla bug after it has been escalated to the tracker.</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>
<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>
<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>
<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>
<dt>9.a. Formal Objection</dt>
<dd>If the commenter does wish to enter a Formal Objection, he or she
should do so according to W3C Process. This includes explicitly
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
tagged with the FormalObjection keyword. <b>** This is an endpoint for
the process. **</b></dd>
<dt>9.b. Ordinary Disagreement</dt>
<dd>If the commenter does not wish to enter a Formal Objection, then
the resolution will simply be indicated as a disagreement on the
Disposition of Comments. The bug should be placed in the CLOSED state
and marked with the Disagree keyword. <b>** This is an endpoint for
the process. **</b></dd>
<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
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>
</dl>
<p>The following table summarizes what different bug states and
keywords say about where a bug stands in the process. All the
conditions marked with an asterisk (*) are ones we must drive to zero
to finish review of Last Call comments.</p>
<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 boilerplate.*</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>VERIFIED 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>
</table>
</section>
<section>
<h2 id="escalation">Escalation Process</h2>
<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
Change Proposals to come to a decision.</p>
<p><img src="escalation-process.png" alt="Flowchart illustrating the process described below."><br>
<small><a href="escalation-process.svg">(SVG version)</a></small></p>
<dl>
<dt>0. Amicable Resolution</dt>
<dd>At any stage of the process, the issue can be settled amicably, If
spec changes are made that satisfy the person who raised the issue, or
the person who raised it otherwise wishes to withdraw, and no one
objects, the issue will be closed by Call for Consensus. Generally in
this case no technical decision is entered, unless that seems
important in particular cases. The Basic Process then proceeds
from <a href="#basic-step-7a">step 7a</a> <b>** This is an endpoint
for the escalation process. **</b></dd>
<dt>1. Raised Issue: Chairs Solicit Proposals<dt>
<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
Proposals will go out to the HTML WG mailing list and possibly via
other channels as well. Note: it's ok for multiple people to volunteer
to produce independent proposals for the same issue. If no one
volunteers within a month, proceed
to <a href="#escalation-step-2a">step 2.a</a>. Otherwise proceed
to <a href="#escalation-step-2b">step 2.b.</a> </p>
<p>Note: information can be added to an Issue without writing a full
Change Proposal by sending email to the public-html mailing list that
mentions the issue number in the format ISSUE-<i>nnn</i>
where <i>nnn</i> is the issue number.</dd>
<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 CLOSED without prejudice and deferred to the next
version of HTML. In this case, we affirm the 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 closed without prejudice and 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
does the proposal address, and how does the proposal makes things
better?</li>
<li>Proposal Details: This may take one of the following four forms:
<ul>
<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>
</ul>
<li>Impact: Effects, both positive and negative, of the change. What conformance classes will have to change? What are the risks?</li>
</ol>
<p>Complete Change Proposals should be recorded somewhere in W3C space
(wiki, dev.w3.org, archived mailing list) and the Working Group should
be notified by email. If the author of the Change Proposal is not a
member of the Working Group, then he or she should agree to the W3C
Patent Policy and grant a non-exclusive copyright assignment as
<a href="http://www.w3.org/Consortium/Legal/2007/06-invited-expert.html#L118">required
for invited experts</a>.</p>
<p>If a Change Proposal is not complete by the deadline (default one month), proceed to <a href="#escalation-step-2a">step 2.a</a>.
</dd>
<dt id="escalation-step3">3. Discussion</dt>
<dd>The Change Proposal (or multiple Proposals) may be discussed and
revised for a reasonable period. Authors of Change Proposals are
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.
<dt>4. Call for Consensus</dt>
<dd>If the chairs believe it is clear whether 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
<a href="#escalation-step-5b">step 5.b</a> without a Call for Consensus.</dd>
<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
Consensus becomes a resolution. The Working Group affirms or overrules
the editor's decision depending on the outcome. The Basic Process then
proceeds from <a href="#basic-step-7a">step 7a</a>
or <a href="#basic-step-7b">step 7b</a> as appropriate. <b>** This is
an endpoint for the escalation process. **</b> </dd>
<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>
<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
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
outcome. The Basic Process then
proceeds from <a href="#basic-step-7a">step 7a</a>
or <a href="#basic-step-7b">step 7b</a> as appropriate. <b>** This is
an endpoint for the escalation process. **</b> </dd>
</dl>
</section>
</article>
</body>
</html>
Received on Wednesday, 24 March 2010 17:49:32 UTC