Skip to content

Commit

Permalink
try to consolidate text further
Browse files Browse the repository at this point in the history
  • Loading branch information
codehag committed Nov 6, 2020
1 parent cfbf570 commit 7891363
Showing 1 changed file with 10 additions and 12 deletions.
22 changes: 10 additions & 12 deletions index.html
Original file line number Diff line number Diff line change
Expand Up @@ -183,30 +183,28 @@ <h2>Calls for implementation and feedback</h2>

<h2>Tips for achieving consensus</h2>

<p>During the discussion of a proposal any aspect may be discussed, however consensus is given as an indicator of the current stage. Delegates should openly give feedback on proposals, and especially for a proposal for stage advancement where the concern is relevant to the stage. Delegates should raise their concerns early and asynchronously, in order to help the champion resolve any issues.
<p>During the discussion of a proposal any aspect may be discussed. Consensus is given as an indicator of the current stage. Delegates should openly give feedback on proposals, and especially for a proposal for stage advancement where the concern is relevant to the stage. Delegates should raise their concerns early and asynchronously, in order to help the champion resolve any issues.

<p>The committee may come to a point where consensus is not reached in committee regarding the feature. There are two forms that this typically takes, and these are colloquially refered to as constraints or blocks.
<p>A delegate may pose a constraint as necessary for advancement. A constraint refers to an desired property of the proposal, accompanied by a rationale. We encourage this to also be done asynchronously in issues, and in incubator calls, as well as in plenary. In this situation, the delegate should expect to work with the champion and other delegates during earlier stages to incorporate their constraint into the solution, and to consider different possible tradeoffs. In general, the earlier a constraint is raised, the better.

<p>A constraint refers to an desired property of the proposal, accompanied by a rationale. Frequently, many different conflicting constraints are posited about proposals, and the committee collectively may make tradeoffs selecting a particular design even though it compromises one or more constraints.
<p>Frequently, many different conflicting constraints are posited about proposals, and the committee collectively may make tradeoffs selecting a particular design even though it compromises one or more constraints.

<p>A delegate may pose a constraint as necessary for advancement. We encourage this to also be done asynchronously in issues, and in incubator calls, as well as in plenary. In this situation, the delegate should expect to work with the champion and other delegates during earlier stages to incorporate their constraint into the solution, and to consider different possible tradeoffs. In general, the earlier a constraint is raised, the better.

<p>Given that consensus on Stage 3 means "the solution is complete", i.e., all open design issues have been resolved including anticipated implementation and ecosystem compatibility issues. All TC39 participants should validate the design of proposals they care about before granting Stage 3 consensus.

<p>In order to ensure that the committee is able to do its work effectively, there are restrictions to the introduction of new constraints and relitigation of addressed issues in stage 3. Proposals which have fulfilled the acceptance criteria may not be withheld from advancement unless the constraint is related to implementation experience or identifies an issue or information which has not previously been discussed by the committee. Withholding consensus for stage 4 advancement is limited, as during stage 3 the intention is to allow implementers to invest in implementations, and maintain the significance of stage 3 in the process.
<p>Given that consensus on Stage 3 means "the solution is complete", i.e., all open design issues have been resolved including anticipated implementation and ecosystem compatibility issues. All TC39 participants should validate the design of proposals they care about before granting Stage 3 consensus. Stage 3 proposals which have fulfilled the acceptance criteria for Stage 4 may not be withheld from advancement unless the issue raised is related to implementation experience or identifies a problem or information which has not previously been discussed by the committee. The intention is to allow implementers to invest in implementations, and maintain the significance of stage 3 in the process.

</div>
<div class="green">

<h2>In cases where the committee does not come to consensus</h2>

<p>If a proposal is presented for advancement, but does not advance, the committee must record a good description of why a proposal did not advance. This should be done both in the meeting notes and within an issue in the proposal's tracker, but not limited to those. This allows us to understand issues in the proposal and similar proposals in a coherent way.
<p>The committee may come to a point where consensus is not reached in committee regarding the feature. In this case, the committee must record a good description of why a proposal did not advance. This should be done both in the meeting notes and within an issue in the proposal's tracker, but not limited to those. This allows us to understand issues in the proposal and similar proposals in a coherent way.

<p>There are two forms that this typically takes, the first is the violation of a constraint and the other is colloquially known as a block.

<p>In the case of a constraint, delegates may consider that the violation of a constraint is sufficiently serious reason to withhold their consensus for stage advancement. The committee should provide an actionable plan whenever possible. The committee does not have an established concept of a rejected proposal--it is always possible for the champion to make changes and come back to ask for consensus.
<p>In the first case, delegates may consider that the violation of a constraint is sufficiently serious reason to withhold their consensus for stage advancement. The dissenting delegate(s) and the champion(s) should work together accordingly to resolve the issue.

<p>Not all issues with proposals may be constructively solved, however. Some issues are too fundamental and serious, requiring a significant rework of the proposal, or may be unsolvable. In these situations, if consensus is withheld, it might be referred to colloquially as a "block", as the proposal will require substantial work to address the concern or may need to be rethought all together.
<p>Not all issues with proposals are easily solvable. Some issues are too fundamental and serious, requiring a significant rework of the proposal, or may be unsolvable. In these situations, if consensus is withheld, it might be referred to colloquially as a "block". The proposal will require substantial work to address the concern, may need to be rethought all together, or may not have enough justification to pursue at this time.

<p>When possible, it is preferable to raise an actionable constraint.
<p>When possible, it is preferable to raise an actionable constraint. The committee does not have an established concept of a rejected proposal--it is always possible for the champion to make changes and come back to ask for consensus.

</div>
<div class="green">
Expand Down

0 comments on commit 7891363

Please sign in to comment.