-
Notifications
You must be signed in to change notification settings - Fork 25
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
Consensus procedure #122
base: main
Are you sure you want to change the base?
Consensus procedure #122
Conversation
From prior discussion in tc39/Reflector#360; to discuss at the November 2022 TC39 meeting to determine whether we adopt it.
how-to-participate-in-meetings.md
Outdated
1. One TC39 attendee states, “I nominate $xyz for consensus.” | ||
1. Another states, “I second $xyz for consensus.” |
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.
requiring at least one explicit "yes" seems reasonable, but two, and the formalism, seems a bit overblown to me
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.
About formality: people in committee seem to have fun with formal language sometimes, so this proposal goes a little camp/extra with it all. I would be fine to tone that down.
The main element of this proposal is to say, two people in committee besides the champion should say, "I want this proposal to go forward" before we call for objections. I think that is quite a low bar, and would give more people a chance to constructively participate as well as say the reason they support it. This is just an idea to improve engagement in committee.
What if we said, one is technically enough if it came down to it, but two is encouraged?
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.
That seems fine; i certainly agree that ideally, there’s a multitude of explicit supporters.
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.
OK, I've edited the text to require just a minimum of one, and reduce the formality. Thanks for the approval! We'll discuss this in TC39 before it lands.
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.
Happy to discuss this in in TC39, but I think the original text requiring two people to explicitly support a proposal is a good idea and presents a very low bar, when we often have 50 or 60 people present in committee. I'm happy to see we're trying to increase engagement and move away from proposals getting consensus through lack of objections rather than explicit support.
Make the support-gathering less formal and require only one person at a minimum (but encourage multiple)
Maybe the framing should be tweaked a little bit, but this was a suggestion from Yulia which I liked.
Co-authored-by: Jordan Harband <ljharb@gmail.com>
how-to-participate-in-meetings.md
Outdated
|
||
Objections to consensus need to be accompanied by a rationale which is appropriately related to the proposition under consideration. For example, for stage advancement, an objection must relate to the qualifications/maturity/acceptance criteria of that stage. It is not meaningful to “object” to established consensus (e.g., around prior stage advancement), as it would take a new consensus decision to overturn it. | ||
|
||
The only exception where consensus may be “undone” soon after it was made is due to inappropriate exclusion of someone from the discussion, e.g., if the item hadn’t been placed on the agenda by the deadline, leading a delegate to not attend a meeting where they would have objected to the consensus. Self-exclusion does not qualify, e.g. people choosing not to attend or not reading the agenda ahead of time. |
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.
Ideally -- a blocking constraint can be raised async, before the proposal goes to committee. but maybe this section should be integrated in the process document.
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 didn't get around to discussing this in plenary, so I'd prefer to leave it out for now.
We discussed this in TC39 and agreed on the two-person minimum, without the ceremony of "nominating/seconding"; text about objections will be replaced by a link to the appropriate part of the process document. |
If a proposition does not reach consensus, note that the committee may revisit it at any time in the future, given that this procedure is followed appropriately. At the same time, once the committee has reached consensus on a proposition, it is considered to have established the consensus, and it would take consensus in a different direction to change course. For example, advancing a proposal to a further stage requires consensus, as does retracting it to the previous stage–a single objection is not enough to undo consensus after it is established. | ||
|
||
It is not meaningful to “object” to established consensus (e.g., around prior stage advancement), as it would take a new consensus decision to overturn it. The only exception where consensus may be “undone” soon after it was made is due to inappropriate exclusion of someone from the discussion, e.g., if the item hadn’t been placed on the agenda by the deadline, leading a delegate to not attend a meeting where they would have objected to the consensus. Self-exclusion does not qualify, e.g. people choosing not to attend or not reading the agenda ahead of time. |
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.
Should these paragraphs be deleted, or moved to the process document?
From prior discussion in https://github.com/tc39/Reflector/issues/360; to discuss at the November 2022 TC39 meeting to determine whether we adopt it.