Introduce section on blocking changes #29
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -173,6 +173,32 @@ <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>Blocking 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 be blocked, however the committee does not have a concept of a rejected proposal.</p> | ||||||
|
There was a problem hiding this comment.
Suggested change
also this isn't entirely true; the committee has rejected proposals - see https://github.com/tc39/proposals/blob/master/inactive-proposals.md for the ones labelled "rejected". There was a problem hiding this comment. How do we draw the line between withdrawn, stalled and rejected? We do not identify in the notes that these proposals are rejected. They are recorded as having something along the lines of "not confident that all issues can be addressed" and "Some members of the committee are strongly opposed to this particular syntax change" or simply as "no advance". It looks like the entries in the inactive proposals list are opinionated rather than reflecting the notes. It would be more accurate to say that these are stalled, or withdrawn. We should probably be more strict in how we record things in the inactive proposals document. The closest we have to a rejection is this one which was blocked as "Adding new features, in new browsers, to fix features in old browsers, is not what we should be doing." -- We could say that this is a rejection, but by a single person, not from the committee as a whole. As such, this could equally be seen as not having consensus as per the last comment. We have had similar blocks in the past that eventually changed. I would say that it would be more accurate to update "inactive proposals" to correctly reflect the notes in question. There was a problem hiding this comment. It's also possible the notes aren't accurate there; for example, I was quite explicitly told that Error.isError was rejected when presenting it - I marked "withdrawn" since there was an alternative path to reach my goals. Similarly, Set/Map toJSON was also rejected. In general, I think a lack of consensus for stage 1, when there's no path forward for the committee to want to spend further time on it, feels like "rejected" is the right word to me. |
||||||
|
|
||||||
| <p>To block the advancement of a proposal, a reason must be given and it must be discussed in committee. If no reason is given, the block is void for vagueness. If a delegate needs more time to consider aspects of a proposal, they may request a delay on the decision, 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, and 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> | ||||||
codehag marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
|
||||||
| <p>Blockers need 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 blockers require the committee to reach consensus in order for the block to be valid: Blockers without a given reason, Blockers which have been discussed at length by the committee and were resolved.</p> | ||||||
|
|
||||||
| <p>Blocking criteria for reaching stage 1 are limited. Proposals which have fulfilled the acceptance criteria may not be blocked from reaching stage 1 unless there has been a very similar proposal that has already been through the process and has not advanced. In this case, the author(s) and champion(s) should be directed to the appropriate record of the previous proposal, so that they can revise their approach. The reason for this restricted ability to block is so that proposals have the necessary time to develop, and the committee has the necessary time to consider them.</p> | ||||||
|
There was a problem hiding this comment. @waldemarhorwat you had a comment here, that blocking criteria for stage 1 should not be limited. @bakkot had a similar, wider comment that blocking should not be too strictly defined. My rationale here is, stage 1 acceptance signifies that "this is not a waste of the champion's/authors time" -- but also that it isn't at a point that the committee considers it a problem worth solving. Some issues may seem not very important at the moment, but could become more important as they are explored further. I think the problem with what I wrote here initially, is that it limits blocking to proposals that have been presented before. This is wrong, how about instead
Suggested change
This is why I was thinking that stage 1 blocking should be limited. I am open to discuss others ideas about this, this has been my model of it. Additionally (and I may have overdone it) I am looking towards the "elide the process" clause from our document as a way to keep these "loose". So we should think of these blocking recommendations as "main path", and elide the process for exceptions. This was to @bakkot's comment regarding flexibility There was a problem hiding this comment. What is the problem we're trying to solve by making stage 1 blocking criteria more formal? There was a problem hiding this comment. I, and a number of other folks I've chatted with, don't agree with either the old or the new changes. Both are taking as a given that we should severely limit blocking criteria for stage 1. I don't see consensus that we should. There was a problem hiding this comment. Ok, based on this feedback, I will remove the text describing stage 1, and merge it with the "unlimited blocking" of stage 2 and stage 3. The goal of writing this criteria was to communicate better the convention that we have at committee. We very rarely block at stage 1. I am not sure how to get it across, it seems to vary by proposal, but that could be done in a second iteration, if this becomes and issue. I am fine with stage 1 being unlimited. |
||||||
|
|
||||||
| <p>Blocking criteria for reaching stage 2 and 3 are not limited. 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> | ||||||
codehag marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
|
||||||
| <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> | ||||||
codehag marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
|
||||||
| <h2>Scope of responsibility for Champions</h2> | ||||||
codehag marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
|
||||||
| <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> | ||||||
codehag marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
|
||||||
| <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. | ||||||
|
|
||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I very much don't like this phrased as "blocking" - we don't block in TC39, we simply may not provide consensus. The onus is and should be conceptually on the champion to persuade the committee to explicitly assent, not on committee members to "block".
What about:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We use the phrases "I am not blocking" and "are you blocking?". We don't say "are you withholding consensus" nor do we adequately ask the room for consensus. We use the mechanism of silence, which is not the same, especially not in a large room where silence is the default.
I think this is a problematic part of our process, but in the interest of writing what we do down, I (weakly) think we should write our current process rather than the ideal. I am fine with going with your suggestion bar my concerns that this doesn't accurately reflect our process or the language we use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I sort of resolved this but please check if it fits for you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @codehag here, the existing practice is clearly asking for blocks?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Historically, we asked for consensus for advancement. However, we've changed to asking if anyone objects to consensus in order to ensure everyone feels comfortable speaking up.
Certainly some folks have started wording their request as "does anyone block", but I don't think that reflects the spirit of the process document, historical behavior, or a universal agreement on the form of these things in the committee. In particular, I think the important part is that the default is that nothing advances, so when things don't advance, nobody is necessarily "blocking" or "obstructing progress".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I disagree, I don't think the default velocity of proposals themselves is relevant at all to this section. This section is describing what might stop something from advancing when advancement is asked for. When advancement is asked for, the default is that unless someone speaks up, we assume consensus. With that default, "withholding consensus" is a mystification of what's actively being asked: does anyone block. It'd do us a disservice to describe surfacing blocking concerns with a new term-of-art sounding language that we have not historically used.