Maths on vote majority

Hi,

I see different rules for votes in the governance PEPs:

  • More +1 than -1, other votes are ignored: “50%+1”
  • Four fifths: 80%
  • 2/3: ~66.6%

I don’t know what these numbers means. So I wrote a Python script to count the minimum number of -1 votes needed to reject a vote.

import math

ratios = (
    ('50%+1', lambda like, dislike: like > dislike),
    ('>= 2/3', lambda like, dislike: (like / (like + dislike)) >= 2/3),
    ('> 2/3', lambda like, dislike: (like / (like + dislike)) > 2/3),
    ('>= 4/5', lambda like, dislike: (like / (like + dislike)) >= 4/5),
    ('> 4/5', lambda like, dislike: (like / (like + dislike)) > 4/5),
)

for n in (5, 10, 25):
    print("%s voters:" % n)
    for text, approved_ratio in ratios:
        def approved(dislike):
            like = n - dislike
            res = approved_ratio(like, dislike)
            return res

        dislike = 1
        while approved(dislike):
            dislike += 1

        assert not approved(dislike)
        assert approved(dislike - 1)
        assert not approved(dislike + 1)

        text = text.replace(">", r"\>")
        print('* %s: need %s "-1" on %s votes to reject' % (text, dislike, n))
    print()

5 voters:

  • 50%+1: need 3 “-1” on 5 votes to reject
  • >= 2/3: need 2 “-1” on 5 votes to reject
  • > 2/3: need 2 “-1” on 5 votes to reject
  • >= 4/5: need 2 “-1” on 5 votes to reject
  • > 4/5: need 1 “-1” on 5 votes to reject

10 voters:

  • 50%+1: need 5 “-1” on 10 votes to reject
  • >= 2/3: need 4 “-1” on 10 votes to reject
  • > 2/3: need 4 “-1” on 10 votes to reject
  • >= 4/5: need 3 “-1” on 10 votes to reject
  • > 4/5: need 2 “-1” on 10 votes to reject

25 voters:

  • 50%+1: need 13 “-1” on 25 votes to reject
  • >= 2/3: need 9 “-1” on 25 votes to reject
  • > 2/3: need 9 “-1” on 25 votes to reject
  • >= 4/5: need 6 “-1” on 25 votes to reject
  • > 4/5: need 5 “-1” on 25 votes to reject

There are different kinds of vote:

  • Elect a council / board / committee
  • Promote a contributor as core developer
  • Vote on a PEP
  • Modify the governance PEP

For voting on a PEP, in the worst case, we are exactly 50%+1 core developers who like the PEP (+1). It means that “50%-1” core developers dislike the PEP: almost 50%. Hum, is it really something that we want? Do we want a PEP to be approved if almost the half dislike (or maybe “strongly dislike”) the PEP? On a 10 people, the PEP is approved if 4 votes -1, but rejected if 5 votes -1.

In my PEP 8015, I used 50%+1 for all votes, value coming from PHP on their RFC. Maybe this ratio should be changed?

I read 2/3 as “we need a majority, but it’s ok if some people dislike, we can handle it”.

I read 4/5 as “we need everybody to agree” (it’s impossible to get 100%, there is always someone who reject an idea just for a specific point ;-)). This kind of vote should be used for conservative change, to prevent too frequent changes and get a kind of stability.

What if a contributor is promoted with almost 50% of other core developers who tried to block the promotion. That’s not really a warm welcome… Maybe it’s better to wait until more core developers approve the promotion?

For me PEP 8015, I propose to change votes:

  • Promote a contributor as core developer: majority (2/3)
  • Vote on a PEP: majority (2/3)
  • Modify the governance PEP: “everybody has to agree” (4/5)

For the “Elect a council / board / committee” vote, I chose to use Condorcet voting method which doesn’t use ratio. By the way, I propose to specify the exact method: use the Schulze method. I heard that many communities use it, so it should be good for Python :slight_smile: And it should reduce (avoid) the risk of having two candidates at the same rank.

I proposed a PR to change votes in my PEP 8015:
https://github.com/python/peps/pull/828/files

I added “Annex: Summary on votes” to have a quick overview on voting methods.

1 Like

Schulze is well-regarded in general, but it was intended to be used to pick a single winner. While it creates a total ordering as a by-product of how it works, it was not intended to be used as “and if you want K winners, pick the first K in that total ordering”. Tideman’s “Ranked Pairs” method is equally well-regarded, but was designed to produce “the best” (in some technical senses) total ordering, not just “the best” single winner. Curiously, in simulations I’ve seen, Ranked Pairs tends to pick “a better” top winner than Schulze anyway (in the small set of cases where they differ on the top choice).

It overlooks that any reasonably robust (which Schulze and Ranked Pairs are) Condorcet method is very much harder to understand than alternatives like range voting (e.g., each voter gives each candidate a score in 1 through 10, and the K candidates with the highest total scores win - I’ll give you 10 times as many words to explain how Schulze or Ranked Pairs picks its ordering, and you’ll run out before you even finish the preliminary definitions :wink:).

And all that ignores something else: none of these methods takes “diversity” into account at all, but when picking a council/board/committee it’s likely that some form of “proportional representation” is socially desirable. There are, e.g., principled variations of multi-winner range voting that at least re-weight a given voter’s scores lower each time one of their most-preferred candidates makes the “top K” cut. So, e.g., if I only give old white guys top scores, the more of those make it to the top K, the less my scores for the others count (and so the more “losing-so-far” voters’ scores count).

I do care of diversity, but if you use women as a metric: we only have 4 women on around 90 core developers. I chose to not require to have the parity in my PEP 8015, because I think that don’t have enough women candidates. Moreover, my PEP 8015 requires that all candidates are core developers and limit mandates to 2.

I prefer to work on the first issue of having more people from underrepresented groups in core developers (using mentoring). Maybe soon we will have enough potential candidates to modify the vote conditions and require “proportional representation”.

Is it an online service implementation this voting method? What is the service used by the PSF? The PSF also elects N members for its board every year, no? Can’t we just reuse the same service?

I’m not even sure that my PEP must specify specific a voting method right now. It seems like the topic is heavily discussed in other threads :slight_smile: Maybe I should remain vague and just express requirements.

I have no interest at all in requiring proportional representation, regardless of what does or doesn’t happen.

I am interested in picking a voting method that’s intended to work well for multi-winner elections, and it’s a big bonus if (like the example system I linked to) it arranges that a voter whose top choices are winning “a lot” is counted less than loser-so-far voters for slots remaining to fill. Even for single-winner elections, Condorcet methods are much harder to understand than some well-regarded alternatives. Any method gets more complicated when trying to reweight voters in such ways in multi-winner elections, but again it’s much simpler to arrange for this in range-voting schemes than in Condorcet schemes.

Such reweighting doesn’t guarantee that minority interests won’t be excluded, but it does ensure they get more weight than in unaltered Ranked Pairs (or Schulze - which, again, wasn’t intended for multi-winner elections to begin with).

Don’t know about online services. The PSF uses Helios, which supports the Approval voting PSF Board elections use. That’s the simplest form of “range voting” (effectively, each voter can give a score of 0 or 1 to each candidate). I have no idea why all these PEPs are leaping to demand other voting methods seemingly off the top of their heads.

It’s a rat hole for sure :wink:. If you’re not married to some particular voting system, ya, if I were you I’d leave the voting method outside the scope of the PEP, and concentrate on what you do care about most.

I’m all in favor of reusing what is already used, so I’m interested by Helios.

Hum, does the approval method work if you need 3 candidates? Or does it need 3 votes?

If possible, it would help to bootstrap the committee to order winners, to solve a tie and corner cases, like two winners working for the same company (which is disallowed by my PEP). I understand that the order is the number of votes per candidate.

Yes. Basically in an Approval scenario you simply vote for all the candidates you would be okay with winning. Then you tally up the total votes for each person, sort them, and then choose the top 3 people with the most votes.

Yup, in Approval candidates are scored by total number of “yup, I approve” votes each gets.

Helios won’t help a bit with ties, or with any other constraints you want to impose. It’s about supplying secure, private, and verifiable ballots over the web, not about picking an election method. It supports things like Plurality and Approval because they’ve worked out all the hairy crypto theory for dealing with “one choice” and “multiple choice” ballots. Last I saw, they don’t really naturally support IRV or Condorcet or “for real” range methods because they don’t support the forms of ballots those methods require. Although that may have changed.

There are many different ways ties and/or additional constraints could be handled, but Helios is irrelevant to those. They “just” give us secure, private, and verifiable completed ballots. Helios doesn’t score an election - we do.

For example, if two candidates from the same company are in the top K approval results, the obvious way to proceed is to say “sorry!” to the lower scoring one, remove them, and add the K+1 top scorer to replace them. But if those two had the same score, that’s just another form of tie

There are many ways ties can occur, not only at the end of an election, but in some methods during the process of computing a ranking. For example, in each round of an IRV election, “the” candidate with the fewest number of first-place votes is eliminated. But what if there’s more than one lowest scorer? Then you have multiple versions of IRV, depending on which answer is picked. Which can really matter in IRV - which candidate is eliminated first can change the final election outcome.

We probably need a different thread here to talk about ties. All non-insane methods can suffer from ties, and we’ve so far ignored the possibility in practice for PSF elections,

Very true. Though it’s unclear to me a good way to address that within the voting context.

I am trusting that whatever governance is chosen that inclusion and diversifying the core developer basis will be key objectives.

1 Like

They do not, there are some issues asking them to support some alternate methods:

For Condorcet there is also https://civs.cs.cornell.edu/ which is not “secure” in the same way that Helios is, though I believe it generally uses a secret ballot and tries to protect anonymity. I believe the main difference is you’re relying on the server itself to implement that, rather than using a bunch of hairy crypto stuff. I believe the outcome of the election is also not publicly verifiable. There is http://www.cs.cornell.edu/projects/civitas/ which is meant to be like a Helios, but for Condorcet systems.

I’m not aware of anything like Helios or Civitas that is implemented for any of the more esoteric voting mechanisms. Although it’s also possible to say that we don’t need public verifiability and then that opens up a lot more possibility for having a secret ballot and using one of the more esoteric systems. It would ultimately come down to either trusting some election administrator or installing/developing/using some software and trusting it.

There are some multi-winner election mechanisms that try to account for this with varying degrees of success. I’ll be honest I’m not nearly as familiar with multi-winner elections, the ones I know of are:

  • Cumulative Voting - If there are 3 seats available, each voter gets 3 votes, they can “spend” these votes however they like (e.g. 1 per person, 2 for 1 person and 1 for another, or all 3 for one person). The idea being that voters who want to ensure that a candidate that may not have as much general support has a better chance of getting in, they can use all of their votes to weight that candidate higher.
  • Sequential Proportional Approval Voting - Basically you vote like approval, and there are multiple rounds. For each round you select the person with the highest approval, then you remove that person from the list, and anyone who approved of that person has the value of their approvals reduced (if you assume an approval has a natural value of 1, then each round will reduce that value). The effect is that if you assume people from different backgrounds are likely to vote for different candidates, then this helps make it more likely that someone from each group of people get someone elected that they approve of, even if they’re not a majority. I believe this is the one @tim.one was alluding to.

As far as I’m aware, none of these multi-winner methods have any real, already developed software for them (much less ones that have the security properties of Helios) so I’d be loathe to suggest them, but that may just be because I’m not very familiar with them and what problems they solve over extending something like Approval or Ranked Pairs to select the top N winners.

1 Like

Carol, yup, no argument. The notion of “diversity” I have in mind here is extremely general, so I probably should have used a different word. But can’t think of one :wink:.

Here’s the problem: suppose there are two parties, P and Q. There are 100 voters, 60 P, 40 Q, and everyone votes along party lines. Now in any one-on-one election pitting a P against a Q, any non-insane voting method is going to pick the P.

What happens in a multi-winner election? It’s actually pretty obvious, but it catches people by surprise because they never thought about it and just seem to assume that “fair enough for one winner, fair enough for many”.

Say there are 10 seats to fill on a board, and 20 Ps and 20 Qs run. Let’s pick Approval voting, just because it’s the simplest multi-winner method. Every P gets a score of 60, and every Q a score of 40. So all 10 seats go to Ps, and would continue to go to Ps until we got to the highest-ranking Q in 21st place.

The same remains true if, say, the population had 51 Ps and 49 Qs. Ps win every seat, every time.

It’s “unfair” on the face of it, but it’s tricky to understand exactly why. The heart of it is that picking K winners in a single election is fundamentally different than picking one winner in each of K consecutive elections.

I don’t know of a coherent theory that compellingly explains “what to do about it”, but re-weighting votes is an approach that works well in simulations. “Hey, Ps! You already got your top pick! You’re already happy. There’s more aggregate social utility now in saying that a marginal increase in your happiness is less valuable than a marginal increase in the happiness of those haven’t had any cause to be happy yet. So we’re going to give your votes less weight now. And if a Q wins next, we’ll similarly give their next votes less weight. Everyone is treated the same this way.”

This isn’t affirmatively trying to redress a grievance, just trying to remove a systematic barrier to a minority getting any wins at all - even a 49.9999% minority.

1 Like

Nope, but related. I’ll leave the previous link bare here, so it’s easier to notice :wink:

Proportional STAR Voting, (STAR-PR) is a voting method that can elect multiple candidates in elections where more than one seat is available. STAR-PR is based almost entirely on re-weighted range voting with the addition of a runoff between the two highest scoring candidates for each seat.

So, if you like STAR (and you do), its pedigree alone should make it attractive to you :smile:.

Ah nice, it seems like basically how you’d implement SPAV with STAR. That’s really interesting.

I modified my PEP 8015 exactly like that, see Annex: Summary on votes.