PEP 8001: Python Governance Voting Process

Committers
21

Yes, naturally.

22

Yesterday I was thinking that we could just use gpg -c, commit (and possibly change) vote.gpg during the two weeks, then commit key.txt on December 1st. I’d prefer that for simplicity (and for not involving the PSF).

There’s a lot to digest in this PEP, primarily because I’ve no experience with IRV at all. I assumed we’d aim for a super-majority for a single PEP.

The original suggestion with open 2 week voting is also susceptible to thought leaders posting an early vote. I don’t know if that’s good or bad. At least it’s very valuable to have one vote that’s not influenced at all.

One factor to consider is that most discussion will probably happen last minute. I think several PEPs still omit crucial details, so I’d have a hard time ranking all of them at this point.

1 Like
23

Absolutely right. Part of why PEP 8001 specifies the date and everything is that we need to start herding the cats. I know I have a laundry list with PEP 8012 myself.

24

Oh, I just understood now that what you mean is that everybody holds onto their own private key until December 1st? That has both the pros and the cons of any distributed system:

  • now you need everybody to come back on December 1st and commit again, otherwise we are stalling the counts;
  • during the vote, we have no way of checking if votes are valid (if Ewa holds onto a single private key, she could verify if ballots are correct; @barry was concerned about mistakenly invalid votes).

What is the problem with the Python Software Foundation being involved?

25

I just understood now that what you mean is that everybody holds onto their own private key until December 1st?

Yes, the encryption is really easy (no private/public keys, just a single symmetric key).

What is the problem with the Python Software Foundation being involved?

I guess I still have the idealistic notion of CPython being developed by a bunch of individuals who feel like contributing code, so I’m concerned about gradually involving the PSF in an increasing number of areas.

1 Like
26

They already host and run all of our infrastructure so I think the time of total isolation is gone. But I would say that the PSF isn’t mandating here, we would simply be asking for them to help us as a neutral party (much like we ask them to host our infrastructure without mandating that we use it).

1 Like
27

So are you officially proposing we use STAR instead of IRV? We aren’t voting experts but when discussing this we did want something that’s:

  1. Easy to explain
  2. Easy to manage
  3. Would lead to a result in a single vote
  4. Didn’t lead to vote splitting like first-past-the-post

I was familiar with IRV/ranked ballot because the party in power was proposing it for Canadian federal elections and I knew that it satisfied those cases. Obviously it isn’t perfect, but everyone’s suspicions is most people will be leaning towards one thing (or theme in the case of team/WG solutions), so we wanted to make sure that was considered.

I know I’m personally open to hearing about other possible voting systems as long as they meet those requirements above.

1 Like
28

Yea I am, and STAR satisfies all of those things. For voters it’s as simple as “score these options from 0 to N, where 0 is you absolutely hate it and N is you absolutely love it”. For tallying the final result there are two basic ways of doing it, and which one you do doesn’t really matter, but you:

  1. Derive an average score for each option (e.g. a score of 5 and a score of 3 would come up with a score of 4) OR sum all of the scores (e.g. a score of 5 and a score of 3 would come up with a score of 8).
  2. Take the two highest scoring options, and you generate a run off ballot between them. This is not a second vote, but rather you look at the ballot where each person scored the choices, and whichever one of the two final options they scored higher is the one that ballot is treated as a vote for. If they scored both of the two highest options the same, then that ballot is excluded from the run off portion (or if you like, it can be considered as a vote for both options, effectively you have no preference between those two).

There is only two rounds of run off versus IRV where you can have many rounds until one item has a majority of the support.

Ultimately the two different systems optimize for two different things. IRV optimizes for trying to get a majority of people their most ideal option, without regard for minimizing the number of people who get their least favorite option. Whereas STAR voting optimizes for finding the option that is the most palatable to the most number of people.

Effectively STAR voting says “if option B is everyone’s second favorite and they all rate it roughly the same, then it’s a better outcome to choose option B, than option A which is 60% of the people’s absolute favorite, but 40% of the people absolutely despise it”.

That’s because in STAR voting, an option that has 60% of the people scoring it as a 5 (in a 0-5 system) and 40% scoring it as a 0, then it’s final score would be 3, whereas if everyone liked option B well enough and scored it as a 4 (it’s not my favorite, but I’m pretty happy with it), then it would get a score of 4. (In this particular example A would still win if there were only two options because both IRV and STAR devolve to what is effectively FTP in an election with only two choices).

You can simplify this by not doing the run off portion, and just doing a simple scored vote, basically you’d just do step 1. There’s no vote splitting involved but it still has tactical voting in the sense of voting everything every the maximum or the minimum instead of honestly scoring them (aka “bullet” voting) will inflate/deflate the scores relative to each other and push your first choice higher than if you honestly scored them. STAR method uses the run-off ballot at the end to counter act that effect.

For our purposes, I think either STAR voting or a simple score based voting comes up with a better answer than IRV because I think trying to maximize the number of people who are happy enough with the final choice is a better outcome than trying to maximize the number of people who get their first choice.

It also utilizes more information in the “algorithm”, whereas IRV the input is only the relative ordering (A > C > B for instance), you know that I’d prefer A over C and B, and C over B, but you don’t know if I’d be (roughly) equally happy with all of them, or maybe I’d be happy with A and C, but I really really hate B, or maybe I’m really only actually happy with A, and I think C and B both suck.

Further more, IRV doesn’t actually eliminate vote splitting, it just makes it less likely, I’d reference again the 2009 Burlington Mayoral election the link there goes into a lot of details why IRV ended up with a poor outcome (although not the worst outcome, a plurality/first-past-the-post system would have done that) compared to other systems. In the 2009 election in Burlington, candidate Kiss won the election, but Wright acted as a spoiler-- if the people who had picked Wright but preferred Montroll over Kiss had instead ranked Montroll first before Wright, they would have gotten the candidate they preferred over the winner more rather than than the one they preferred the least.

The site https://www.rangevoting.org/ has a bunch of good information for score voting (score voting and STAR voting are similiar as I said, STAR voting just adds the run-off election in step 2). https://www.equal.vote has more information specific to the STAR voting form of scored voting, which has a page dedicated to STAR vs IRV

3 Likes
29

It seems the two systems have interesting properties. I agree STAR seems a bit more desirable for the present purpose, but no strong preference either.

1 Like
30

I think we need @njs to share his view on the matter, I remember him being also well informed about this.

1 Like
31

I’m not familiar with STAR. It sounds like a variant of Borda count methods?

If you really want to go down the rabbit hole on voting systems, well, it’s a very deep rabbit hole. And it’s chock full of nerd-snipe problems. Also, it ultimately doesn’t matter that much. Therefore, I think our main goal should be to avoid getting hung up on bike-shedding.

Therefore, my suggestion is that our voting mechanism should be: "Copy whatever Debian does."

In practice, this means:

  • Voters rank their preferences in order: A > B > C > …
  • “Further discussion” is included as an option on the ballot
  • If a voter leaves some options off of their ballot, then that’s fine; all the missing options are treated as if they were ranked equally at the very bottom of their list.
  • The winner is selected by the “Condorcet method”, which sounds fancy but is actually very simple: If you have a bunch of ranked ballots, you can see how people would vote in any possible two-way race. So, we use a computer to run all the two-way races, and whichever option wins every possible two-way vote is our overall winner.
  • Condorcet by itself has one limitation, which is that theoretically you can get a pathological situation where there is no unique Condorcet winner. This is stupendously rare (as in: people have spent decades trying to find real-world examples). Basically it’s just a kind of tied vote, which can happen in any system. But, see above re: voting being a deep rabbit hole, nerd sniping, etc. Anyway, there are solutions, Debian picks one, those who are curious can read about it, but it’s not going to matter.

Here’s an example ballot and voting instructions for a contentious vote with lots of options, and here’s the results.

The advantages are:

  • It’s an easy choice for those who don’t really care, because it’s already been bikeshedded to death by the Debian developers, and it has solid precedent since it’s used successfully by Debian, and also Gentoo, KDE, and others.
  • It’s actually very solid theoretically, so the folks who do care about all the obscure voting theory stuff will be able to live with it. IRV is … much more dubious.
  • Having a “Further discussion” option on the ballot is handy. AFAIK in all of Debian’s dozens of votes it has never won, but it gives people a way to express that they hate an option (by ranking it below “Further discussion”), and it increases the legitimacy of the final choice if you can say “not only is this better than the other options that were presented, but people actually like it in an absolute sense”.

I suggested this to Raymond at the sprint, and his objection was “oh no please don’t open the which-voting-system-is-best can of worms, we’ll be bikeshedding forever”. From the thread I think it’s clear that the can-of-worms has been opened, so this is my best suggestion for how to close it again and move on.

5 Likes
32

Oh, and regarding the worry that people might change their votes based on how they see other people voting: I guess that could happen, but… is that a problem? People will also change their votes based on seeing people they respect making public statements like “I think X is the best, because …”. And that’s a good thing! Discussions and consensus-building and people changing their mind when they get new information are good things.

3 Likes
33

Both Borda and STAR (or scored) fail the majority criterion and tend to reflect consensus rather than majority rule, but the two aren’t really related and STAR is not a variant of it. Borda uses a ranked choice ballot, whereas STAR uses a scored ballot.

To be clear, you’re suggesting using the Schulze method since a “Condorcet method” isn’t actually a thing, but a class of things and I believe Debian uses the Schulze method.

I think this is probably a better option than IRV, since if you’re going to go with a method that tends to create majority rule, then one that doesn’t have the pathological case of failing to actually choose the option that the majority would prefer. I still personally feel that for our own case here, a system that trends towards consensus to avoid a tyranny of the majority is a better fit.

Changing your vote because another person has convinced you to vote that way is generally a good thing sure. However, changing your vote because you’re looking at how other people have voted, and your new vote isn’t an “honest” vote, but rather a tactical vote is generally something to be avoided. The two situations are entirely unlike and I don’t think painting tactical voting using public ballots is anything like discussion and consensus building and people changing their mind.

1 Like
34

Oh, and while cycles in a method that satisfies the Condorcet criterion are very rare, you still do have the problem of good old fashion actual ties (which really any of these systems would have), so we should probably have some form of a tie breaker.

1 Like
35

The big take away I had from the summit 8001 discussion was that we did not want this to turn into a nerdshed over voting methods and technologies. Keep it simple.

Anyone worried about protecting their vote from prying eyes/bots before the result can aim to push their vote to GitHub near the deadline.

We decided that we’re all adults who should have a level of trust and respect for one another. If we believe we are composed significantly of assholes who will vote tactically, why be here at all?

As for GitHub committers vs everyone on python-committers ever, we figured this took care of the retired emeritus folks. Anyone who will actually be interested in the outcome has an easy option: show yourself by activating your GitHub status instead of lurking. Anyone unwilling to show that level of activity does not make sense as a decider.

We should not be writing custom software to collect votes. Using helios like software is extremely overblown - not worth it for a one time ultimately public ballot with a small pool of voters on one project with multiple good outcomes.

6 Likes
36

I think that this is a very poor take on tactical voting. Is someone an “asshole” for voting for their second favorite candidate instead of their favorite candidate in a first-past-the-post election, thus ensuring that their least favorite candidate will win? If not, why is someone an asshole for ranking their second favorite candidate as their first ranked candidate, so that their least preferred candidate won’t win?

2 Likes
37

Ah, I get what you’re saying now. And score-based and IRV methods are both notorious for rewarding tactical voting, so if you’re advocating one of those then I can see why you might worry about it. But Condorcet-based systems are essentially immune to tactical voting, so this wouldn’t be an issue…

1 Like
38

That’s not actually true though, all voting systems are vulnerable to tactical voting. Specifically the Schultz method that Debian uses, it’s vulnerable to burying and bullet voting. It also has the property that people can actually help their candidate win, by not voting at all and make them lose by voting honestly.

That’s not to say that the Schulz method is bad because it allows tactical voting, because there is no voting method that is not vulnerable to tactical voting when you’re not dealing with a binary choice. The best you can do is try to minimize the tactical voting (or at least how mandatory it is, i.e. don’t use FPTP) and attempt to limit the information provided prior to the vote being over so that nobody has the information provided to tactically vote (that or just decide you don’t care if people tactically vote).

The desire to have the ballot be public is supposedly “transparency”, but I think in this case that word doesn’t have a whole lot of meaning. Or rather, transparency to what end? In my eye there are really two reasons where you’d want a vote to be transparent:

  1. Verifiability
  2. Accountability

I think that for any such case, verifiability is an extremely important trait, and we probably do not want to select a system without that. Now one way of implementing that is to make all ballots public, so that everyone can see who voted for one, and can more or less independently audit the votes by checking with people to see if they voted the way they said they did, and doing their own tallying. Another way is to use a voting system that is designed to provide verifiability, without sacrificing the secrecy of the ballot (such as Helios).

The other important situation where you’d want transparency is when you want accountability. Earlier @ambv likened it to Parliament. Now I’m not entirely familiar with the way Parliament works in other countries, but assuming it’s at least a little bit like congress in the US, the reason ballots need to be public there, is due to the need for the people to hold their representatives accountable for their voting. The idea being of course that if your representative is not accurately reflecting your values in the way they vote, that you can apply some form of pressure to try and get them to vote the way you up (up and and including replacement).

However, this is entirely unlikely the situation that the core developers are in. No larger body elected us to act as their representative, and there is nobody that can (or should) be able to hold us accountable for how we’re voting. This could be as mundane as people being disappointed that a friend didn’t rank their own proposal (or one they favored) highly (or of course, feeling pressured to rank a proposal you wouldn’t otherwise high or low). A real world example, is a family member acting like they’re going to vote for one person, even though they really vote for another, in order to keep their social circle harmonious.

All in all, while I agree that verifiability is an extremely important and good trait for this vote to have, I see absolutely no reason why we would want to open up developers to accountability for the way they voted. We should feel free to vote honestly, without having to worry about blowback if someone votes for an unpopular opinion. I do not see any benefit what so ever to act as the reason to make that trade off.

2 Likes
39

Very impressed by the depth of knowledge this group has re: voting systems.

To clarify a bit on @gpshead’s comment, I believe that my biggest concern during the in-person meeting was that the voting method should be transparent and easily explained (to both core team and the greater community). These two things will be important when communicating the new governance and how it was determined to Python developers and users.

I completely agree with @dstufft’s view of transparency:

  1. Verifiability
  2. Accountability
2 Likes
40

Thanks to the many people that worked on this proposal! Good to see!

I strongly favor IRV over STAR voting.

What I don’t like so much about STAR voting and other forms of score voting is that scoring / voting for your second or lower choices works to defeat your first choice. So it ties voters’ hands.

IRV and other runoff forms ensure that your vote only counts towards your top remaining choice at any point in time.

Some side notes on this fun topic: I happen to live in San Franciso, California where we use IRV to elect our Mayor and Board of Supervisors, etc. I also serve on San Francisco’s Elections Commission, which oversees the San Francisco Department of Elections. (Incidentally, San Francisco is also starting work on a project to build the country’s first open source paper-ballot voting system, which I’ve been shepherding as a Commissioner. More info here: https://osvtac.github.io ) Also, in 2005 I drafted Oakland, California’s IRV Charter amendment that Oakland voters passed in 2006 with 69% support.

2 Likes