Introduce section on blocking changes #29
Conversation
index.html
Outdated
|
|
||
| <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
| <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> | |
| <p>Blocking criteria for reaching stage 1 are limited. Proposals which have fulfilled the acceptance criteria may be blocked from reaching stage 1 if there are significant technical or foundational issues, or there has been a very similar proposal that has already been through the process and has not advanced for reasons that are not addressed in the new proposal. In the former case, the author(s) and champion(s) should have as an outcome the reason for the block. In the latter 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> |
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.
index.html
Outdated
| @@ -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> | |||
There was a problem hiding this comment.
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:
| <h2>Blocking Advancement</h2> | |
| <h2>Withholding Consensus for Advancement</h2> |
There was a problem hiding this comment.
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.
I think I sort of resolved this but please check if it fits for you.
There was a problem hiding this comment.
I agree with @codehag here, the existing practice is clearly asking for blocks?
There was a problem hiding this comment.
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.
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.
index.html
Outdated
| @@ -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.
| <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> | |
| <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, however the committee does not have a concept of a rejected proposal.</p> |
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.
There was a problem hiding this comment.
Thanks for writing this up. I like the following:
- Stage 3 to 4 blocking criteria
- A description of conditional advancement
- Require that blockers be explicitly recorded
I'm less enthusiastic and somewhat worried about the other parts of this PR, especially blocking criteria for stages 1.
The stages are progressively stronger signals that the committee sends, and taking back blocking later stages weaken their strength as signals. Blockers are, IMO, most usefully graded against this question: if we block advancement to some stage, which stakeholders have discouraged from trusting our future decisions? It so happens that currently, except in rare cases, the only time we significantly hurt a larger audience is blocking going from stage 3 to 4: the browser vendors, and the developers that may already be using those cutting-edge features.
Blocking advancement to stages 1, 2, and 3, on the other hand, usually only affects TC39 delegates. Even here we should still be mindful of people's time, thus not asking folks to write spec texts in stage 1 before iterating on the solution in stage 2, so on and so forth.
I feel like the most realistic thing we can record here in terms of criteria is that blockers should be reasonable and weighed accordingly to stage. I'm afraid enumeration of blocking criteria for those before stage 4 will lead to unproductive exegesis, as @bakkot pointed out on IRC before.
index.html
Outdated
|
|
||
| <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.
What is the problem we're trying to solve by making stage 1 blocking criteria more formal?
index.html
Outdated
|
|
||
| <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> |
|
@syg you mentioned
I believe I have addressed your concerns for stage 1, please check. This seems to be your main concern but there is a suggestion that you have others. Regarding your other concerns, can you identify them for me? I would like to address them. |
codehag
force-pushed
the
process-changes-blocking
branch
from
fd53c15 to
21fdf25
Compare
codehag
force-pushed
the
process-changes-blocking
branch
from
21fdf25 to
3587898
Compare
|
I wonder if we should talk a bit more here about the reasons people should express concerns and give feedback on proposals. For example, we could indicate:
|
|
a minor observation: I'd prefer some consistency in this document over the html tags. The document does not close Overall, I miss some feature on GitHub to render the HTML files here or perhaps this document being a markdown rendered through gh-pages. |
index.html
Outdated
|
|
||
| <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> |
There was a problem hiding this comment.
This is really confusing. I understand we are asking consensus for a reason that blocks a proposal from advancing. Some of the items are rather vague: "Blocks related to an earlier stage". I have some reference but only due to my experience at the committee, but it might need way more clarification for new comers.
The paragraph on like 190 might already solve the problem here.
I'd prefer if we rephrase this w/ something like "The committee might also request consensus for the reasons presented for blocking or delaying a proposal from stage advancement. Well stated reasons are expected to be objective, technical, and should provide an actionable plan whenever possible."
This suggested paragraph supports the following with connotation for well stated reasons.
There was a problem hiding this comment.
I don't think " objective" works -- people will either consider their positions to be objective, or will be presenting a very valid subjective view, i.e., a member industry position. I reworked that sentence a bit, let me know what you think.
I think this is important. I've found it extremely helpful when people have told me "I would like you to address these issues before this proposal advances to Stage 3". I'd like to make it clear that comments along those lines are productive, and work much better than holding your fire in an effort to seem more genial. I agree with @littledan that taking some time to identify constructive patterns of feedback is important. Many members (especially new members) won't necessarily be able to infer under which circumstances blunt but actionable feedback would help move things along, and under which circumstances feedback would frustrate champions. |
|
Hey folks, thanks for all the comments. Sorry I haven't gotten to them all yet. I am currently on sick leave. I will address them all before the next meeting, feel free to keep giving feedback. |
This sounds great to me -- should i fold this in directly? |
|
@codehag If you have an idea for how you want to fold the text in, then please go ahead. If you prefer that I make a PR to fold it in, please let me know. |
Sorry for the delay, this fell off my radar. Thanks for addressing my concerns for limiting earlier stage blockers here, I like what the current wording says, with the exception of "any well stated reason". I'm not sure of the intention of well stated. If someone states an objection eloquently but all other delegates strongly disagree with the objection, is that "well stated"? And that segues into my underlying concern, which @littledan and @wycats have hit on already, about the benefit of capturing what discourages progress in the process document as opposed to capturing what encourages progress. Firstly, I am very invested in having TC39's mission be encouraging progress as the default. (If you all will indulge me, a brief rant. I know that there are delegates that feel strongly in the other direction: that TC39 is best when it acts like a conservator or steward. I feel oppositely, because standards bodies are on-going agreements by stakeholders that continued cooperation is in everyone's interest. The stakeholders here are mostly companies that want the web or other JS ecosystems to flourish. We may individually want that to happen for non-economic reasons, but stakeholders-as-corporate-entities want it for economic reasons. I think encouraging non-progress as the conservative default will, in time, weaken the desire for continued participation or attracting new participants. Businesses don't prosper standing still.) For the goal of encouraging progress, I am very much in favor of explicitly calling out acceptable blockers when criteria are largely objective, like the Stage 3 -> 4 qualifications. For the earlier stages, I'm fairly wary of spelling out blockers in the process document. Historically, we've had many a time in plenary where, when there is existing contention whether a proposal should advance, we debate and interpret the process document on whether a proposal meets the criteria for a particular stage. I fear that if what we record in the document is only what qualifies as things that may block or things that may delay, it might encourage a culture where, when there is already contention, we reach for a process debate about if the objection is "well stated" enough to block. That is, I think it's the wrong default, and is susceptible to exegesis as a way to throw around stop energy. As an alternative, I like @littledan's suggestion for writing out suggestions for constructively addressing concerns. Also, our consensus model is an uncomfortable topic of discussion. In practice, ours is sometimes lack of sustained objection, and other times lone blocker. To put it lightly, I believe the lone blocker model promotes dysfunction, and that if we amend the process document, we should try to tackle the problem of improving our decision making process to be more robust. |
|
While I'm fully on board with limiting the kinds of objections to stage 3 or 4, I think that the ability of a single individual to prevent irrevocable mistakes from shipping is a critical piece of TC39's process, and would be a huge loss if it were removed. Is there perhaps a way we could move this PR forward that:
… and then we could iterate in future venues on concerns around stages 0-2, and also around what the committee's default should be considered? (acknowledging that the latter has many different camps that in many ways are diametrically opposed, and it may not be worth the energy for us to debate it) |
|
To @syg
Thanks for the question. I think @wycats demonstrated what I was trying to put into words. Something along the lines of "I would like you to address these issues before this proposal advances to Stage 3", or the block to the new directives that I recently made, which was along the lines of "I can't see this moving forward to stage 3 because when we initially entered stage 2, it was under the impression that this proposal would have more benefit and have a different use, that has since changed and we are no longer convinced that it should move forward in this present form". As a first stab at defining this, I would say "well stated reason" is an articulated reason as to why the proposal is being blocked. We shouldn't be recording things like "it just isn't a good idea". We should record "why". Similarly we shouldn't record "this is not advancing in this meeting", we should record "why". We already do this, it just isn't written down in our process document and there has been some confusion. That's what thee goal of this change is anyway. Perhaps this needs some expansion? @ljharb regarding your comment:
The restricted requirement is for proposals moving from stage 3 to stage 4. Blocking entrance to stage 3 is not limited, so long as there is a well stated reason (which needs clarification as per shu's comment). This is very important, we should not move to the implementation phase if we do not have consensus on the design. If we get to the point that implementer have completed their implementations, and a single dissenter blocks consensus with no reason given, or a reason that has already been discussed by the committee and the committee has come to a consensus on it previously, then it undermines thee committee as a decision body if we allow that block to stand. In case we run into this issue, where the reality of the situation has changed but the two previous things mentioned are still true: we do have text here about eliding the process, that is an escape valve should something go horribly wrong. We can add text to this effect if that's necessary? I might not be super responsive. I can't really do much until Sept. 7 due to being out on sick leave. I would like to get to @littledan's comments but it's likely that it wont be until then. Feel free to also just make changes. |
Co-authored-by: Leo Balter <[email protected]>
Co-authored-by: Leo Balter <[email protected]>
Co-authored-by: Leo Balter <[email protected]>
Co-authored-by: Leo Balter <[email protected]>
Co-authored-by: Leo Balter <[email protected]>
Elaborating a bit more: I've had the most success (both as a champion and someone with concerns about a feature), when delegates have used the language of "constraints" rather than the language of "blocking". It's very common for people (myself included) to express their constraints in terms of a very concrete suggestion. The language of "blocking" tends to shut down the conversation, while the language of constraints tends to get the champions more engaged with the constraint. Very often, the champion comes up with ideas that the concerned delegate didn't think of. I also believe, on the basis of painful experience, that our process should focus more on getting constraints and concerns out in the open ahead of the meeting in which a champion proposes a feature for advancement. This gives champions an opportunity to overtly address the concerns, vet the solutions with the relevant delegates ahead of time, and lowers the stakes of the proposal to advance. To be concrete, with language like this:
I prefer something more like this:
In my time on the committee, emphasizing constraints and collaboration has tended to produce better proposals and more progress, while emphasizing blocking has tended to produce gridlock, even in situations where all of the participants agree that progress is appropriate. |
|
+1 to @wycats's suggestion. |
@codehag i totally agree! +1 as well to @wycat's suggestion. |
|
+1 to everyone here (where are the emoji reacts?). Waiting until the second week of September for the updates sounds fine to me. |
|
@littledan conversations that are locked, even locked to collaborators, apparently prevent any emoji reactions, even from collaborators. |
index.html
Outdated
|
|
||
| <p>When a champion proposes a feature, a delegate may suggest additional constraints and ask that the champion incorporate them into the proposal. The delegate raising a constraint should expect to spend time working with the champion to help flesh out the constraint and learn about other constraints that went into the proposal. The delegate should expect to spend time working with the champion to help flesh out the constraint and learn about other constraints that went into the proposal, and to consider different possible tradeoffs. | ||
|
|
||
| <p>A delegate may pose a constraint as necessary for advancement to a future stage before it is being considered for advancement to that stage. 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. In general, the earlier a constraint is raised, the better. |
There was a problem hiding this comment.
Along the same line of thinking, while we are laying out an idealized working mode here, I'd like for us to encourage both raising constraints asynchronously (e.g. on GitHub or emails) or via incubator calls where possible. Resolution, similarly, where possible, should also ideally happen async or in between plenary meetings.
index.html
Outdated
|
|
||
| <p>Champions (or, frequently "champion groups" of several members) are authors and editors of proposals. The champion is responsible for the evolution of the proposal from Stage 0 through Stage 4, at which point maintenance transfers to the editor group. Champions have admin permissions in the proposal repository and can freely make changes within this repository. Periodically, champions may bring their proposal to TC39 to ask for consensus on stage advancement. | ||
|
|
||
| <p>When asking for advancement, the champion is expected to make the whole proposal accessible for review by the committee, by explaining its contents, providing supporting documentation, etc. Major changes should be presented explicitly, but small, insiginficant changes ("<em>nits</em>") may be resolved on the issue tracker without bringing the whole committee in. Examples of <em>nits</em> are issues of taste such as minor naming adjustments. Reviewers and editors are expected to look over these details and raise concerns if they have any. |
There was a problem hiding this comment.
I'd remove elaboration on what constitutes significance, and leave it at "Material changes should be presented explicitly."
|
The language and tone of this proposal is making me very uncomfortable. This proposal is described as a "process document clarification". It's not; it's a major change of how we work. I gave feedback several times but my comments have not been addressed: the proposal still mandates us to let a stage 1 proposal proceed even if it's clear that it won't ever pass stage 2. The bigger problem here is loaded, negative language throughout the proposal. The emphasis of this document is on "withholding" and "blocking". That's inherently divisive. If consensus is mandatory unless someone blocks it, then a proposal that few others in the committee are enthusiastic about will make it into the language unless someone becomes the bad guy and blocks it or creates constraints that it can't satisfy. Soon we'll be stuck with a mess of vague and overlapping constraints. This situation does not lead to a healthy working environment. A much healthier emphasis in this document would be to describe what it takes to advance, not what it takes to block. |
Co-authored-by: Shu-yu Guo <[email protected]>
Can you elaborate on how the text does this? There have been changes based on your comments, and I would like to understand where they are insufficient. |
|
Hi @waldemarhorwat, thanks for your comments.
The line regarding stage 1 has been removed. Is there elsewhere in the document that gives you concern regarding this? Also I only received one comment from you, but you say that you have given feedback several times. Perhaps those were missed somehow or not posted in this github thread. I am happy to incorporate any feedback you have, as I have done with other delegates.
The "blocking" language has been removed from the current version of the document, aside from acknowledging that they happen and that they should be avoided unless necessary. We switched to withholding consensus everywhere. We also avoid using that, per yehuda's comments, and recommend introducing "constraints" instead.
I am curious what your thoughts are on this segment: https://github.com/tc39/process-document/pull/29/files#diff-eacf331f0ffc35d4b482f1d15a887d3bR196 and this one: https://github.com/tc39/process-document/pull/29/files#diff-eacf331f0ffc35d4b482f1d15a887d3bR198 -- the goal of these sections was to encourage open discussion of hesitations. At present, we haven't had a practice of enthusiastic support -- I think this would be beneficial. It might be something to be worked on outside of the scope of this and added later?
This is indeed what happens with our current process, as noted by the decorators presentation last meeting. I believe the resolution there to address this overlapping was a positive one. Perhaps this is something that should be written down. @littledan since you were the champion involved, do you have thoughts on this?
This is already part of the document as "entrance criterea". However last meeting the issue was around withholding consensus. That is why this document is introducing guidelines on withholding consensus.
I tried to write down an idealized version of our process. It started from my perspective but has been corrected and improved upon by the delegates participating in this review. One thing that may be thought of as a major change (from my perspective anyway) is the introduction of "conditional advancement". This is indeed new, but something I observed in committee as sometimes occurring, which is why I included it. If it makes you feel more comfortable I can update the agenda to say "Process update" instead of "Process clarification". I also understand that we may have different views on the process. I am very happy to incorporate or change this document as necessary. |
|
Conditional advancement is definitely part of our practice, so it is good to document it. About documenting the idea of raising constraints: the process document describes some requirements of proposals to advance, but in practice, it takes more than meeting neutral requirements. Constraints are reasoned rationales which are necessarily asserted by committee members, and they end up playing a large role the proposal development process. There is ultimately a value judgement at play that the constraint is important, and we validate those judgements through our consensus process. By documenting this reality, we can help all participants navigate the situation. I don't see this as a change. |
It's still there: "Concerns related to future stages are not sufficient grounds for withholding consensus."
I already mentioned "withholding". The "withholding consensus" wording which appears throughout the proposal is still loaded language due to its divisive and negative connotation.
I find it frustrating to see responses like this, claiming that we need to do it this way because some decision has already been made at the last meeting, when I was present at the meeting and don't recall having consensus about that. We should have guidelines about achieving consensus, not withholding consensus. |
Ok, I see what you mean there. It was intended to reflect the phrase that we use "is this a stage X concern" and "this is not a stage X concern" which has been used to move some proposals in the lower stages. I hadn't realized that it could be read in the way of "you can't block stage 1". We can either remove it for now, or change it to something along the lines of "In some cases, a concern related to a later stage may be discussed. A proposal may still advance, but must address this concern before moving into the following stage". Or something to this effect? Regarding
and
Withholding consensus is an important part of what we do, and it should be done in a constructive way. Additionally, switching to "achieving consensus" focuses on the champion, not on the committee members giving feedback (see my final comments for more details). I personally find this language to be fairly neutral given the subject matter but I am open to suggestions. Do you have suggestions?
Regarding what we have recorded (which unfortunately doesn't give a clear picture) please see the notes I introduced the initial draft of this document and read the basic structure out to the committee in the section that starts with "YSV: (resumes presenting slides at “Addendum: Clarifying the process”)". Unfortunately, my comments and much of the context on the related slide are not recorded. I will relate it as best I can, and if you doubt my recollection you can verify with other members of the thread. Hax had introduced a constraint for a proposal going from stage 2 to stage 3. It was overruled initially. I, along with several other members found this to be disturbing, myself, @michaelficarra and @bakkot in particular spoke out about it in the chat. The committee corrected itself and said that the constraint was valid. As part of my presentation on invariants, at the very end I presented an early version of this document. I asked if we should iterate and introduce guidelines that could be referenced for withholding consensus. The conclusion was yes and several delegates, including Hax, spoke in support of such an effort. I maintain that this is an important clarification. This is not resolved by introducing more language about achieving consensus. If a constraint is reasonable, especially when transitioning to stage 3, we should take time and investigate it. Additionally, tensions between delegates can sometimes make it difficult to recognize what is happening and something like this may go unnoticed especially in late meeting. By having it written down carefully, we can reference our behaviour as a committee to ensure we are being fair to all delegates. We also want to make sure that we focus on giving actionable feedback to champions, rather than stopping progress arbitrarily. This is a difficult balance to achieve, which is where documentation can be useful. This of course, doesn't mean that our documentation of achieving consensus is necessarily sufficient. We can certainly iterate on that, separately. |
|
(To clarify; it's not that the objection was overruled - it's that the objector had connection issues and we didn't realize they still wanted to object. That was clarified later in IRC, and a few members found it disturbing if the advancement would hold in light of that, and we all agreed to respect the objection and withdraw the advancement) |
It's best to just remove it. I don't want to get into situations where we must keep advancing a proposal that we know will harm implementation efficiency up to stage 2 just because that's a stage 3 concern.
I do not find identifying and requiring committee members to formally "withhold consensus" neutral at all. It has a negative and harmful connotation. I'm not comfortable with doing that, and I suspect other delegates may be even less comfortable with that even if they disagree with a proposal. This proposal is raising serious inclusivity questions. A more neutral wording would be that the "committee did not reach consensus to proceed". |
…/process-document into process-changes-blocking
|
Ok, I tried to reword things where I could. I need to think a bit more of how to word things and probably it won't be finished for the update next week, but we can continue this discussion in plenary and after. Also addressed Shu's comments. |
Co-authored-by: Jordan Harband <[email protected]>
…/process-document into process-changes-blocking
codehag
force-pushed
the
process-changes-blocking
branch
from
345dadd to
4d752a2
Compare
|
Following the conclusion from today's meeting, this is being merged with two follow on issues:
|
|
@leobalter wrote on irc that he approves these changes |
This introduces prose to describe our blocking process / consensus building process. I have added a comment there to get further feedback on the precise prose there.
CC'ing @michaelficarra @waldemarhorwat @ljharb @erights @syg @bakkot to get some early feedback, as you folks had comments