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

[Process] Consensus mechanisms in subgroups #1422

Open
penzn opened this issue Nov 6, 2023 · 5 comments
Open

[Process] Consensus mechanisms in subgroups #1422

penzn opened this issue Nov 6, 2023 · 5 comments
Labels
process Issues concerning the documents in the process directory.

Comments

@penzn
Copy link
Contributor

penzn commented Nov 6, 2023

Can subgroups define own approaches to consensus? In SIMD we have been using the same polling mechanism CG uses (5 options, chair to determine consensus), while at least WASI uses unanimous consent exclusively, and I obviously don't attend all subgroups' and proposals' meetings. There are pros and cons to either approach as well as to whether or not all meetings should follow the same process.

(Edit) Also, there seems to be a usual SF-F-N-A-SA poll for another item in the same WASI meeting, so maybe WASI is moving to that style as well.

@jeffparsons
Copy link

Comment/question from the peanut gallery:

As an outsider, it can be hard to understand the outcome of a vote, even with minutes recorded. In particular, sometimes when an objection is raised (thereby blocking unanimous consent) there doesn't appear to be any record of what the objection actually was.

Are objections recorded separately to meeting minutes? Or maybe it's a feature that objectors aren't actually required to formally substantiate their objection?

I'm not suggesting any change here — rather seeking understanding of the process.

@conrad-watt
Copy link
Contributor

conrad-watt commented Nov 7, 2023

Notionally all subgroups are inheriting definitions like this from the process of the main group, unless their charter says otherwise - the WASI subgroup's decision to hold mainly unanimous consent polls falls within the CG's process (which also allows unanimous consent polls).

To some extent it's at a subgroup chair's discretion whether or not a full poll is called - if the WASI subgroup prefers not to call full polls often, that's for subjective reasons (e.g. wanting to reach a "high bar" of agreement) rather than because they're following a "different" process.

@jeffparsons

In particular, sometimes when an objection is raised (thereby blocking unanimous consent) there doesn't appear to be any record of what the objection actually was.

Are objections recorded separately to meeting minutes? Or maybe it's a feature that objectors aren't actually required to formally substantiate their objection?

Unanimous consent can normally be blocked without setting any bar on how "valid" the reason is, but in any subsequent full vote participants would normally be expected to substantiate their objection, so that the chair can judge the character of the objection as part of deciding whether consensus has been reached (which can include disagreeing opinions depending on their strength and diversity).

EDIT: and any substantial dissenting opinions should be recorded in the notes

@jeffparsons
Copy link

Unanimous consent can normally be blocked without setting any bar on how "valid" the reason is [...]

Oh, for sure, that makes sense. I certainly wouldn't advocate for that, either.

[...] in any subsequent full vote participants would normally be expected to substantiate their objection, so that the chair can judge the character of the objection as part of deciding whether consensus has been reached (which can include disagreeing opinions depending on their strength and diversity).

EDIT: and any substantial dissenting opinions should be recorded in the notes

Got it. Thanks for explaining that. I can see the value in starting with the lightest-weight-possible unanimous consent vote and then only moving to a heavier process if and when necessary.

I think my only unresolved surprise/confusion is that sometimes I see a proposal discussed openly for a relatively long time, and then the first objection happens at a vote. But I guess that is more an issue for how a subgroup communicates informally leading up to a vote than an issue for formal process — e.g. if this effect ends up unnecessarily holding things up because some members are not up-to-speed, maybe members of the group proposing a vote could informally but explicitly circulate request for comment to all other members a week or more before the vote, or something like that. 🤷‍♂️

Thanks again from this observer for the explanation! You're all doing amazing stuff here, and it's a real treat to be able to follow along.

@penzn
Copy link
Contributor Author

penzn commented Nov 10, 2023

Notionally all subgroups are inheriting definitions like this from the process of the main group, unless their charter says otherwise - the WASI subgroup's decision to hold mainly unanimous consent polls falls within the CG's process (which also allows unanimous consent polls).

Can you expand on this a bit - is this because process docs just say 'consensus' and we don't have current CG polling mechanism codified anywhere?

IMO consensus vs full poll sets the bar differently: while consensus allows a single person to veto, it would also pass without participants actively voting 'in favor'. It is not necessarily that one is better than the other, but I think it would do us good to understand why we pick what we pick.

@conrad-watt
Copy link
Contributor

Can you expand on this a bit - is this because process docs just say 'consensus' and we don't have current CG polling mechanism codified anywhere?

Without getting into the weeds on how the full CG defines consensus (considering the clarifications in-flight in #1418), it should be assumed that subgroups aren't redefining what "consensus" means in the absence of anything to the contrary.

IMO consensus vs full poll sets the bar differently: while consensus allows a single person to veto, it would also pass without participants actively voting 'in favor'.

I'm assuming you mean "unanimous consent" instead of "consensus" here. You're right that "unanimous consent by apathy" is a concern, but anyone who's worried about this can object to the unanimous consent poll and request that a full poll be held instead. All of this falls within our current process. I think of this as just as much a social issue as a process issue, since the arguments around whether to hold a full poll as opposed to a unanimous consent poll are somewhat subjective - if you think the WASI subgroup would benefit from holding more full polls, you could talk to the subgroup chairs about this, and they could choose to shift the way the group handles polls without requiring any changes to our process. I'd emphasise in particular that WASI subgroup's choice to hold a full poll in an upcoming meeting doesn't require any change of process, even if it is different from the subgroup's normal mode of operating.

It is not necessarily that one is better than the other, but I think it would do us good to understand why we pick what we pick.

I think there is a space of reasonable choices that chairs and participants could make in deciding how they prefer to hold polls and judge/accept consensus (e.g. biasing more or less towards unanimous consent polls), all of which fall within our process. Asking why one is chosen over another may at least partially come down to an individual chair's taste, the expectations and preferences of the (sub)group, and inertia. It's always possible to repeatedly ask "why not something else" given this space of reasonable choices, but I think our main focus should be on ensuring that no (sub)group is doing anything unreasonable.

@sunfishcode sunfishcode added the process Issues concerning the documents in the process directory. label Mar 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
process Issues concerning the documents in the process directory.
Projects
None yet
Development

No branches or pull requests

4 participants