Skip to content
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

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Consensus procedure #122

wants to merge 5 commits into from

Conversation

littledan
Copy link
Member

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.

From prior discussion in tc39/Reflector#360; to discuss at the November 2022 TC39 meeting to determine whether we adopt it.
Comment on lines 37 to 38
1. One TC39 attendee states, “I nominate $xyz for consensus.”
1. Another states, “I second $xyz for consensus.”
Copy link
Member

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

Copy link
Member Author

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?

Copy link
Member

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.

Copy link
Member Author

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.

Copy link

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>

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.
Copy link
Contributor

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.

Copy link
Member Author

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.

@littledan
Copy link
Member Author

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.

Comment on lines +46 to +48
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.
Copy link
Member Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants