Introduce section on blocking changes

index.html

@@ -173,6 +173,30 @@ <h2>Calls for implementation and feedback</h2>
 
 <p>When an addition is accepted at the “candidate” (stage 3) maturity level, the committee is signifying that it believes design work is complete and further refinement will require implementation experience, significant usage and external feedback.
 
+<h2>Withholding Consensus for Advancement</h2>
+
+<p>During the discussion of a proposal, at any stage, any aspect may be discussed, including those outside of the scope of its current stage. A proposal’s advancement may not have consensus, and may be "blocked". A block is a forumated reason for why a proposal should not advance in it's present form. The committee does not have a concept of a rejected proposal.</p>
+
+<p>In withholding consensus for advancement, a reason should be stated either as a delay or as a block. If no reason is given, the objection is void for vagueness. In the case of a delay -- a delegate may need more time to consider a given aspect of a proposal. They may request additional time, or allow conditional advancement.</p>
+
+<p>Conditional advancement is time-limited, giving the person raising the block time to discuss with the champions and authors about their concerns. If a proposal has conditional advancement, an issue is opened on the proposal’s repository. If the issue is resolved, the proposal automatically reaches the next stage without further discussion by the committee. If the issue cannot be resolved, the proposal does not advance.</p>
+
+<p>A Block needs to be well described and recorded within the committee, so that in future meetings and future proposals we can learn from failed proposals, and have a good record of why they failed.</p>
+
+<p>Regardless of stage, the following types of blocks require the committee to reach consensus in order for the block to be valid: Blocks related to an earlier stage, Blocks which have been discussed at length by the committee and were resolved, and insufficently stated blocks.</p>
+
+<p>Blocking criteria for reaching stage 1, 2 and 3 are not limited but should be weighed according to their stage. Proposals which have fulfilled the acceptance criteria may be blocked from advancement for any well stated reason.</p>
+
+<p>Blocking criteria for reaching stage 4 are limited. Proposals which have fulfilled the acceptance criteria may not be blocked from advancement unless the block is related to implementation experience or the block identifies an issue or information which has not previously been discussed by the committee. The reason stage 4 blocking is limited is to allow implementers to invest in implementations, and maintain the significance of stage 3 in the process.</p>
+
+<h2>Reverting to Earlier Stages</h2>
+
+<p>At any point in the process, a proposal may be downgraded in its stage in the case that a well stated blocker identifies an earlier stage issue that was not considered. This process requires an issue to be raised, and committee consensus to downgrade to a more appropriate stage.</p>
+
+<h2>Scope of responsibility for Champions</h2>
+
+<p>Champions are trusted to resolve smaller issues on their own without reference to the committee. Such issues are `nits` and can be raised at committee or as issues on github. Examples of `nits` are issues of taste such as naming.</p>
+
 <h2>Test262 tests</h2>
 
 <p>During stage 3, <a href="https://github.com/tc39/test262">test262</a> tests should be authored and submitted via pull request. Once it has been appropriately reviewed, it should be merged to aid implementors in providing the feedback expected during this stage.