Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decision policy update #1737

Merged
merged 5 commits into from Apr 21, 2021
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
20 changes: 17 additions & 3 deletions decision-policy.php
Expand Up @@ -14,7 +14,7 @@
<p>The Working Group strives to reach consensus via unanimous agreement. However, at times unanimity is not possible, and for the sake of continuing to work on important topics the group must arrive at a consensus decision and move forward. In the course of establishing consensus it is critical that all participants have the opportunity to express their views for consideration so that all relevant information can be used in arriving at the conclusion. Consensus indicates that a substantial number of individuals in the group support a proposal, and within the AG Working Group consensus can be achieved through this process. </p>
<p><a href="https://www.w3.org/2018/Process-20180201/#Consensus">Consensus</a> is not a vote. The exact number of working group participants supporting a Call for Consensus compared to objections is not the only factor in the decision. Although significant support from the active membership is always desirable, consensus means working through objections until they are resolved either through amending the decision or in rare cases overriding the objection as laid out in <a href="https://www.w3.org/2018/Process-20180201/#managing-dissent">Managing Dissent</a>. In order to work through objections they must have a clear rationale based on the technical merit or with reference to the agreed scope of the work. Moving on usually means a careful approach is taken. For example, <em>not</em> adding something to the documentation.</p>
<p>Additions to normative text such as new success criteria should have a pre-defined scope. For example, the <a href="https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteria">requirements for WCAG 2.1 success criteria</a>. Where new normative text does not reach consensus the reasons should be recorded, depending on the origin of the text. For example, if the new text originated in a github issue or pull request, it could be labeled with "Unsupported addition".</p>
<p>During discussion on a topic, participants are welcome to raise objections freely to help ensure that all available information can be considered and contribute to the best possible decision. However, when the chairs issue a Call for Consensus, objections should not be raised unless the individual strongly believes the decision is the wrong one in spite of discussion, and the individual cannot "live with" the decision. Compromise on points that the individual considers suboptimal but can "live with" is an essential part of group decisions that must meet various requirements. </p>
<p>During discussion on a topic, participants are welcome to raise objections freely to help ensure that all available information can be considered and contribute to the best possible decision. However, when the chairs issue a Call for Consensus (CfC), objections should not be raised unless the individual strongly believes the decision is the wrong one in spite of discussion, and the individual cannot "live with" the decision. Compromise on points that the individual considers suboptimal but can "live with" is an essential part of group decisions that must meet various requirements.</p>
<ol>
<li> Discussion on a topic proceeds until the chairs believe that all points of view have been expressed and the group has considered the variety of information presented. Depending on the topic, this discussion may take a couple of days or a couple of weeks, or more.
<ol>
Expand All @@ -24,17 +24,31 @@
<li> When the chairs believe that the group is ready to come to a decision they announce a Call for Consensus by email to the Working Group's mailing list. The Call must remain open for a minimum of two working days.
<ol>
<li> The Call is open to responses from all group members. </li>
<li>The Call will be for a single topic, will clearly indicate that it is a Call for Consensus, and will contain pointers to the relevant discussion. This may include links to GitHub issues or pull requests, AG surveys, email threads, or meeting minutes.</li>
<li> The Call will be for a single topic, will clearly indicate that it is a Call for Consensus, and will contain pointers to the relevant discussion. This may include links to GitHub issues or pull requests, AG surveys, email threads, or meeting minutes.</li>
<li> A resolution recorded in a WG teleconference may precede a Call for Consensus, but it may not replace the official Call for Consensus. </li>
<li> Issues that are regarded as editorial by the Chairs do not require a Working Group decision in order for the Chairs to address, and thus do not require a Call for Consensus. If there is disagreement by participants on whether something is editorial this can be brought to the attention of the chairs either privately or in the context of the wider group. </li>
</ol>
</li>
</li>Responding to the Call for Consensus
<ol>
<li>Individuals are invited, but not required, to support the decision by replying to the CfC email with “+1”, or to indicate a “can live with” status by replying with a “+0”.</li>
<li>Objections can be raised by replying to the CfC email with “-1”. In order to facilitate understanding and discussion, it is recommended to include a rationale which includes:
<ul>
<li>why the individual objects to the proposed decision;</li>
<li>describes how the objection was raised and considered during discussion leading to the CfC, including how reactions to the potential objection were addressed;</li>
<li>what alternate decision would remove the objection <b>and</b> be likely to gain consensus in the WG.</li>
</ul>
</li>
<li>Objections are subject to examination by the WG and therefore must be filed on the public record.</li>
</ol>
<li>
</li>
<li>Evaluating the Call for Consensus.
<ol>
<li>If no objections are received by the deadline, the draft decision becomes a formal decision of the Working Group. </li>
<li>If objections are received but the chairs believe the objections have already been considered as far as is possible and reasonable, and the reviewers providing the objections can "live with” the decision, the draft decision becomes a formal decision of the Working Group. </li>
<li>If objections are received that the chairs believe present substantive new information or if the chairs believe there is not a clear consensus in the Working Group, they will reopen the discussion, as detailed in <a href="http://www.w3.org/Consortium/Process/#WGChairReopen">section 3.3.4 of the Process Document (Reopening a Decision When Presented With New Information)</a>.</li>
<li>If working group member(s) continue to disagree and the chairs do not believe it presents substantive new information, or it does not meet the criteria established for adding new normative content, the chairs may decide the draft decision becomes a formal decision of the Working Group despite the objection.</li>
<li>If working group member(s) continue to disagree and the chairs do not believe it presents substantive new information, or it does not meet the criteria established for adding new normative content, the chairs (with consensus of the Working Group) may decide the draft decision becomes a formal decision of the Working Group despite the objection.</li>
</ol>
</li>
<li>The Working Group chairs record the Formal Decisions on the <a href="./wiki/Decisions">AG Decisions page</a> on the wiki. The change to the WCAG documents is incorporated into the editors draft and recorded in the appropriate change log.</li>
Expand Down