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

Ambiguity in many voting rules #933

Open
martinthomson opened this issue Oct 18, 2024 · 3 comments
Open

Ambiguity in many voting rules #933

martinthomson opened this issue Oct 18, 2024 · 3 comments

Comments

@martinthomson
Copy link
Member

Voting is used in number of places. A lot of these set a threshold (majority, 2/3, 3/4). But very few of these establish what the denominator is.

Rather than have point solutions, it would be useful to have a general rule. My suggestion is that the denominator in any such vote is
the set of people who are eligible to cast a vote.

For bodies like the AB and TAG and councils, where we expect the people involved to be engaged, I'd argue that this approach is superior.

In particular, I have observed a trend where people who organize a vote do not set a deadline for votes. In that case, a threshold based on the number of people who vote gives the vote organizer the power to disenfranchise people. That's obviously not happening, but it would be better not to have that option. (Moving to an all-eligible rule doesn't prevent someone from setting a deadline, just that it removes that sharp edge.)

Obviously, specific cases would override that general rule. And maybe it makes sense for AC votes (where the turnout is often very low) to rely on the established quorum rules, making an all-AC vote a general exception to a general rule.

@frivoal
Copy link
Collaborator

frivoal commented Oct 18, 2024

I think we did have a lot of ambiguities in how voting was defined, but I think #838 solved those I was aware of.

I could be wrong, but I don't think there's any case left where we define the vote as passing if we meet x%, where we don't know x% of what.

However I think we do have cases where a vote is defined as "at least (twice) as many for as against", which doesn't leave ambiguity as to the numerator or denominator, but may fail to set a quorum. I suspect the appropriate quorum will be different for different types of votes. For instance, a reasonably high quorum for Council votes seems appropriate and practical, but Working Groups often have a large number of passive members. Even fairly low quorum could be challenging to meet. For instance, as of today, the CSS-WG has 178 participants, but a meeting with 30 people present is considered well attended.

As for generalities, I think votes should be held:

  • asynchronously, until a pre-determined date (or until everyone has voted, whichever comes soonest)
  • in a duly announced synchronous meeting where it is clearly established that decision making will happen

@TallTed
Copy link
Member

TallTed commented Oct 18, 2024

It seems to me that we should be able to find all such ambiguous voting scenarios, and add text to remove the ambiguity.

I think that "the set of people who are eligible to cast a vote" is unlikely to be the appropriate denominator in most if not all cases, unless that eligibility typically starts with "in attendance at the meeting where the vote is taken."

@frivoal's point about undefined quorums is also important, and should probably be addressed with some general guidelines as well as some "escape" clause (e.g., "the Chair can override the general quorum requirements when they feel it is justified and appropriate" which would be, as with all Chair decisions, subject to Formal Objections).

@fantasai
Copy link
Collaborator

fantasai commented Dec 6, 2024

@martinthomson I think Florian has explained well why this cannot be a general rule for all votes throughout the Process. That leaves the question of, are there specific cases remaining where this is underdefined that need fixing?

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

No branches or pull requests

4 participants