Python Governance Electoral System

In the poll I voted Condorcet (since I trust everyone here who has concerns with IRV), 3-2-1 (Tim has a track record of good intuition when it comes to tweaks to well-established algorithms), and the original IRV suggestion.

Condorcet is a clear winner at the time of this comment, with 86% votes in favor. IRV turns out to be the least popular.

@njs, thanks for stepping up. You identified a clear problem with the original plan and as proven by the poll, you were absolutely right. Ultimately the voting process matters less than the feeling that it represents the will of the core group. I think that you, @dstufft, @tim.one and @taleinat should be included in the authors list on PEP 8001. Thanks all.

Now, getting back to my usual polizei self… how long do you plan to run the poll here, @njs? I would like to open a new topic to choose a new date for the Big Vote. I was pushing for getting it done in a timely fashion and this is not changing.

You can change your vote. “Hide results” and vote again.

2 Likes

Ah. I didn’t mean to vote either way.

Requiring a 2/3 supermajority was discussed when we first discussed this at the dev sprints, but we realized the margins didn’t warrant it. With a maximum of 95 voters at the moment, the difference between 2/5 and 1/2 of the voters is only 16. But we all know that not every individual is going to vote, so assuming a 50% turnout the difference drops to 9 (and I don’t know if we will get even 48 people to vote; that’s about how many people, core or not, who have gotten a PR merged into the CPython repo). What this means is that the difference between majority and supermajority acceptance does not seem staggering to me and worth blocking on.

This also means a small cadre of people could control whether we come to a conclusion or not. We all seem to working hard to make sure we can reach a conclusion that is as widely acceptable as possible by selecting a voting system that lets people basically express that, but my worry is if we do Approval w/ supermajority acceptance then it might come down to how many people are willing to dig in and not be willing to compromise to see how many others on the other side are willing to switch simply to finish this whole process. And then at that point it seems to me this will devolve into strategic voting and not really be a true supermajority acceptance.

BTW, I think discussing tie-breaker mechanisms should start having its own thread and we keep this thread to focusing on at the (at least initial) voting system.

2 Likes

Given @dstufft 's comments, I think we’ll have to accept the fact that 8001 is only for the vote on the constitution, and we’ll have to reevaluate the voting procedure for filling the roles defined in the winning constitution.

3 Likes

Not to dig another rathole :wink:, but I’ve never heard the term “supermajority” used outside the context of plurality voting. Even then it comes with many possible specific meanings. What could it mean in, e.g., a Condorcet method, or IRV? I don’t even want to think about that. For Approval, I suppose “at least N% approval” carries over naturally enough. Or in 3-2-1, “at least N% Good (or not Bad?)”.

I personally want “one vote and done”, even if it ends in a 6-way tie resolved by random.choice().

3 Likes

Agreed. Perhaps it makes sense to have a separate informational PEP about the different voting system options (and about the voting requirements of the core dev team). That way we don’t lose the good info from this (and other) threads.

Other PEPs could then refer to the particular system they’re using rather than having to go into much detail themselves. PEP 8001 could do likewise, but maybe later (so the vote doesn’t have to wait for the info PEP).

It would be very useful to have a summary PEP with this information written by Donald and Nathaniel… but I’m hearing they are already working on a different one.

I have zero interest in having the PSF board decide anything. If the first vote fails for whatever reason, we have a second vote.

2 Likes

Yeah, this puzzled me for a while too. My eventual conclusion was that the relevant definition of “supermajority” here would be “the winner has to beat the ‘Further discussion’ option by at least X%”. This follows from the intuition that the reason we might want a supermajority is to ensure that a large proportion of the voters are OK with going ahead (and is similar to requiring an X% supermajority in an approval vote).

I had a long discussion with Raymond about this in-person at the sprint – I was happy with the idea of doing multiple votes until converging on a supermajority (like how popes are elected!), while Raymond was strongly opposed. We eventually did a survey of the folks who were listening in, and it was like 9-to-1 in favor of going with a simple majority, in order to move on ASAP (and with the knowledge that we’ll probably need to adjust things later anyway). Which I can live with. So that’s why I haven’t brought up supermajority again :-). And this also makes me very confident that we’ll see a supermajority in favor of picking something and moving on, whether or not we require it :-).

My impression of the current status is:

  • We’re going to switch to “pure Condorcet”. I (or any admin) can close the poll whenever, but it seems pretty clear that’s where we’re going and people will generally be happy with it.
  • We should put “Further discussion” on the ballot, so everyone can vote against it and show the the world that we’re ready to move on.
  • There’s still substantive disagreement about how to handle potential ties. It sounds like everyone is OK with having the “first pass” tie-breaking method to be a time-boxed extension of the discussion/voting (e.g., “extend the voting period for 1 week”). If that still fails, then what? Some people want to keep extending the discussion until there’s a clear result, others want to switch to some other tie-breaking method, and for the latter there have been a bunch of suggestions (send to the PSF board, roll a die (possibly a cryptographically verifiable die), ask Guido, use a fallback voting system like plurality, …).

I guess we need to resolve the tie-breaking discussion somehow. Personally I’m happy with all the potential ways of handling ties listed above, so I’m probably not the best person to lead that :-). Maybe someone should open a new thread? Maybe with an informational poll?

I will make one comment: we don’t currently have any real way to “lock in” a decision. The PEP is only binding so long as everyone wants it to be binding. So if we say now that our 2nd-round tie-breaker is to flip a coin, but then when we get there a bunch of folks are like “hey wait, we’re having a productive discussion, we just need a few more days” then… we’re probably going to ignore what the PEP says and wait a few more days. Or the other way around, if we say now that we’ll keep extending discussion until there’s a result, but then when we get there everyone’s like “I don’t care, these last two options are both great, let’s flip a coin”, then we’ll flip a coin and it’ll be fine. And it’s very unlikely that we’ll not only have a tie, but also fail to resolve it in the first round of discussion. So maybe it’d be easiest to just leave the 2nd-round tiebreaker as “to be determined”?

2 Likes

That’s my impression too. And fine by me.

As to ties,

Less than 1.5% of real elections lead to a chance voting cycle when there are 21 voters or more.

in a Condorcet election. The fewer the voters, the higher the risk; the more, the lower. It probably won’t happen. If it does, fine by me too if we address it when it happens.

1 Like

The PSF board has just as much expertise as the coin tossed by a random non-Python person I walk up who is willing to have a video of their coin toss posted online that I would otherwise propose to break ties.

When its a tie, it really does not matter which one of the tied choices is chosen. All people are collectively equally pleased not matter what the outcome.

1 Like

The question of ties (and with a “Pure” Condorcet method, cycles like Candidates, Rock, Paper, and Scissors where there is no single preferred option) is both an interesting one, and probably largely useless to debate. In the case of an actual tie it would mean that the tied winners are all equally preferred, so any of them are good. In a cycle they may not be equally preferred but there’s no way to pick one that is preferred by everyone.

What’s somewhat interesting to me, is that Pure Condorcet seems to be favored by a significant margin over Schulze, where the only difference in outcomes between the two, is in the case of a cycle, Schulze has a built in mechanism for resolving that cycle. There are other Condorcet methods that have other ways of resolving that cycle, but a key defining characteristic of any Condorcet method is that if there is a Condorcet winner (as a “Pure” method would only be willing to elect).

I’m not really sure how to interpret that! It suggests that people aren’t ok with some semi arbitrary (Schulze isn’t specifically arbitrary, there’s rationale behind why it picks what it picks) pick… but I’m not sure why. Maybe folks prefer the idea of extending the vote out to let further debate and vote switching to occur? Maybe people didn’t realize that Schulze is basically Pure Condorcet plus a mechanism for resolving cycles?

I don’t really have an answer (and honestly, I think any method we pick in the rare likelihood we get a cycle is fine). I’m just mostly surprised Schulze isn’t basically tied with Pure Condorcet.

I’m not! But I may have contributed to it. Here’s the thing: everyone who’s given it any thought at all knows what “Condorcet winner” means, and knows they could find it if it exists with a very short & clear program.

But the Wikipedia page on Schulze (which everyone is likely to find first) is nearly impenetrable, drowning in notation, overly-busy masses of dense graphs, followed by “maximally clever” (pseudo)code implementing just part of the algorithm with a doubly-nested loop nest followed by a triply-nested loop nest - without a word explaining what they do, beyond that all together these nests implement “a variant of the Floyd–Warshall algorithm”.

Which people have complained about in the Talk section, but to no avail. As in other places too, Schulze himself appears opposed to making the exposition more accessible.

In contrast, e.g., the Wikipedia article on “Ranked Pairs” (another Condorcet method that’s probably just as good as Schulze’s - indeed, by Wikipedia’s account it satisfies all the formal properties Schulze’s does plus another - “local independence from irrelevant alternatives”) is much easier to follow. Although that one suffers some in the opposite direction by being too imprecise about some details, and by using an example so simple it has an easily found Condorcet winner (but RP doesn’t need there to be a Condorcet winner any more than Schulze’s does - they’re both usually able to pick a principled winner regardless, although they won’t always pick the same one - if they did, they’d both satisfy LIIA, or both not).

So, bottom line: it’s very easy to gain confidence about what “Condorcet winner” means; it’s something of a nightmare to fight to an understanding of what “Schulze winner” really means; it’s much easier to get an understanding of what “Ranked Pair winner” really means, but that method never got trendy so it may as well not exist :wink:. Lots of people don’t want to sign up to be ruled by something they don’t understand - and I expect that’s pretty much all there is to it.

2 Likes

An interesting bit of trivia, I happened across an AMA with Tideman (of Ranked Pairs fame), and his thoughts on RP vs Schulze:

Ranked Pairs and Schulze are so close that I would not fight for one instead of the other. You can ask Schulze why he thinks his mechanism is better. Hubert Bray, a mathematician at Duke University, has identified a property that Ranked Pairs has and Schulze does not, and he thinks that this makes Ranked Pairs more attractive. I do not recall the details.

2 Likes

Thanks! I’ll add some brief glosses from later on that page:

It’s rare for them to actually differ, so I think factors other than their electoral effectiveness would dominate the quality. Perhaps how explainable they are.

or how computable? I think RP wins one and Schulze wins the other, if I remember correctly.

They’re both very similar on both measures. I think if presented correctly, Schulze edges out on both counts, but by the way it’s explained on Wikipedia it loses on both.

Bingo. It’s Wikipedia’s fault :wink:.

This is a major part of why I’m much more a fan of schemes derived from range voting: they’re very easy to understand once someone gets over the prejudice that “merely counting the raw numbers of who ranks higher than who” is somehow a God-given requirement.

In the AMA, Tideman notes that range voting is more susceptible to strategic manipulation than some other methods, but schemes like STAR and 3-2-1 intentionally use range-scoring variants only to pick the two finalists, and then do “the one that merely ranks higher (regardless of score) on more ballots wins”. That’s to make pure range-voting tactics much less attractive (play them, and you’re likely to hurt your favorites if they make it to the final stage). They’re instances of what’s called “Score-Runoff Voting” in the AMA.

Tideman’s answers to all that read well, but keep going and it’s clear that he didn’t really understand what VSE simulations are doing (he appeared to think they were only looking at cases where all sides are 100% strategic) - and that simulation results contradict several of his claims.

He does make the good point that simulations are using computer-generated voter preferences, as opposed to real-life data. I’m uncomfortable about that too, but simulations have tried to become more realistic over time, and it’s simply not possible to get real-life data on millions of real-life elections.

As is, state-of-the-art simulations clearly show that the easy-but-not-trivial to explain and understand “Score-Runoff” methods are the most resistant to strategic manipulation, although Schulze/RP do slightly better when everyone is 100% honest. Curiously, in the graph you reproduced before, RP was significantly more resistant than Schulze to 1-sided strategic voting, and RP very slightly better than Schulze when everyone is honest. So, based on that, I’d prefer RP. But I’d like STAR best - too bad nobody has ever used it :wink:.

2 Likes

If no one beats me to it I can update the PEP to use Condorcet and a draft ballot tomorrow (and can lock the poll then).

I still don’t see the need as I think it’s pretty obvious we all want to move on. :slight_smile: But if people really want to have that field to almost automatically write the largest number (and thus the lowest ranking) on the ballot then fine by me.

I’ll plan to update the PEP to say we will hold weekly votes until the tie is broken which should be scary enough to get people to change on the first re-vote to break any tie/cycle. :wink: If someone wants to start a separate thread to discuss this and potentially hold another poll then that’s fine.

5 Likes

The beatings voting will continue until morale improves a winner is selected.

Seems fine to me, there’s only a 1.5% chance of hitting it if we have >= 21 voters, so we should probably be pretty unlikely to even hit that case anyways.

4 Likes

No one did, so I have closed the poll and updated PEP 8001 to use the Condorcet method and to re-open voting for a week at a time until no ties or cycles are found.

4 Likes

FYI I just adjusted “rules” of all votes in my PEP 8015, especially the most sensitive vote: elect members of the Steering Committee. I use a different voting method since voting for people is different than voting for a (governance PEP). I proposed that the vote to create the committee is organized by the PSF Board, but following votes will be organized by the current Steering Committee. Someone will have to provide a list of core developers to the PSF Board to organize the vote, since I proposed to not use GitHub but an online service like CIVS.

Well, I don’t really care of the exact service used to vote. The PEP 8001 doesn’t use secret ballots, but a Git repository where each vote will become public and clearly attached to a core developer. Again, voting on a PEP on voting on people are different :slight_smile:

But … I suspect 99.99% of the “real elections” referenced in that had no more than 3 viable candidates. We have a combination of a low number of voters with a high number of reasonable choices.

As a sanity check, I ran my own simulations using 100 voters each picking a full (no duplicate ranks) ranking of 7 candidates, picked uniformly at random from the 7! candidate permutations.

Slightly less than half(!) turned out to have a Condorcet winner. Worse, we won’t have 100 voters, and the fewer there are the worse the chances. Worse again, allowing rank duplicates also boosts the odds of not having a Condorcet winner.

Against that, rankings across voters in real life will doubtless be much more correlated than permutations picked at random, so “less than half” should be viewed as worst-case.

I don’t know how to model that, though. Cutting the number of candidates to 3 and voters to 21, about 92% had a Condorcet winner, far closer to the 98.5% cited in the quote. It’s easy to imagine that real-life ranking correlation closes that gap.

Heh - and going back to 7 candidates, changing the number of voters from 100 to either 99 or 101 boosts the Condorcet-winner rate to about 63%. When there are an odd number of voters, and equal rankings aren’t allowed, no one-on-one contest can tie. When there are an even number of voters, they can tie, and then there’s a substantial chance that “the best” candidate doesn’t lose any one-on-one contest, but does tie on at least one. Not a Condorcet winner then.

Another reason I like voting systems better when they’re not too clever for their own good :wink:.

Anyway, bottom line: best guess is that we’ve grossly overestimated the odds of getting a Condorcet winner on the first try, due to our unusual combination of relatively few voters faced with an unusually high number of viable alternatives. Still think we probably will, but it will no longer be a real surprise to me if we don’t.