PEP 8001: Python Governance Voting Process

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: ) Also, in 2005 I drafted Oakland, California’s IRV Charter amendment that Oakland voters passed in 2006 with 69% support.


Of course, IRV means that voting for your first choice over your second choice, can mean that you get your least favorite choice instead.

I think the moral of this discussion is that every voting system sucks in its own way, and there is no system that will make everybody happy. The real issue here is not “what is the best system to use”, but rather “is the system specified in the PEP acceptable enough to just get on with it?” Or in other words, would using the system as laid out in the PEP cause the results, whatever they are, to be illegitimate? If not, I think we should just go with what’s already specified and not drag out a discussion that has no perfect end.


Illegitimate is I think the wrong word, because there is no standard for what a legitimate result is. If we all agree to just have random.choice pick an option is that “illegitimate”? We’ve agreed to it so it of course can’t be but that doesn’t make it a good way to decide.

Beyond the secret ballot thing, what I’m trying to push back on is the question of whether we want something that provides consensus or majority wins. If literally everyone has option B as their 2nd favorite option, but 60% of the people have option A as their most favorite and 40% has it as something they aboslutely loathe, do we want to go with majority rule and select Option A even though it means that 40% of the developers are going to be very unhappy with the choice? Do we want to go with option B which means everyone is somewhat happy, but 60% of the people got their second choice instead of their first choice?

Talking about specific voting systems is probably the wrong way to go about it (and I started that, I’m sorry for that!) but rather what properties we want out of the voting system. Brett listed 4 options:

The first two are not really specific voting criteria, so I’m going to ignore them for a minute.

Thus I’m going to say at the moment the defined criteria is:

  1. Single Winner (This is obvious, we can only select a single winner).
  2. Independency of clones. (This is effectively Brett’s 4th thing, but abstracted beyond first-past-the-post).

I’m going to personally add Resolvable to the list, which basically just states that a winner should be able to be selected in the majority of cases without resorting to randomness such as a coin flip.

There are roughly 4-5 criterion that are related specifically to individual voter behavior rather than the election as a whole. Those are:

  1. Later No Harm - Does ranking a less preferred candidate after the preferred candidate ever hurt the preferred candidate.
  2. Later No Help - Basically the same thing as the first, but in reverse. Does voting for a candidate later in the election ever help an already voted for candidate.
  3. No favorite betrayal - Can voters be sure that they do not need to rank any other candidate above their favorite in order to obtain a result they prefer.
  4. Participation - Does a voter ever hurt their preferred result by voting honestly instead of not voting at all?
  5. Consistency - Basically, if you take a set of ballots where A wins, can you add another set of ballots where A also wins, and still have A winning?

When evaluating these, I’d suggest possibly ignoring no-later-help. In most cases no-later-help will be Yes/No depending on whether no-later-harm or no-favorite-betrayal is Yes or No (and you generally can’t have both of them Yes unless you’re not using a resolvable method). I would also suggest lumping consistency and participation together, because they’re closely related and they’re generally both always the same.

Which means generally you’ll need to decide which of the 3 properties is most important:

  1. Voting for a later candidate cannot hurt your primary candidates chances for winning.
  2. Can voters be sure they do not need to vote a less preferred candidate higher than their preferred candidate, to get their preferred outcome.
  3. Can voters be assured that honest voting is not going to hurt their preferred outcomes chances, or might they be better off not voting all together?

We can roughly suggest these 3 properties are mutually exclusive (they’re not, but they’re not reasonably possible to get more than one of them with the current constraints).

The other important question to ask is whether we want some form of the majority criterion satisfied. As I mentioned above, this basically boils down to whether we want to say that if a majority of people want A, then we must select A regardless of how the minority feels about A, or if the election can choose a less favorite of the majority, but an overall more evenly favorited option?

1 Like

In my PEP 8015, I decided to use the duration of 1 month for all votes since people can be away during 2 up to 3 weeks. But this PEP only leaves the vote open for 2 weeks, whereas deciding the Python governance is likely one of the most critical choice that we will make in the Python community.

Question: Am I really wrong in my PEP 8015 for the duration of the vote, or do you think that this PEP should leave the vote open longer? For example, should I reduce the duration of a vote to promote a contributor as a core developer? Currently, it’s also 1 month, same duration than votes for the Python Board or for a PEP (if the PEP is decided with a vote).

Note: In my PEP, the vote to elect Python Board members is open for 1 month but votes are private during the vote. They are only be made public once the vote ends. I would make sense to have a different duration if the votes are public or not during the vote.

Voting for the president is just one day and in many countries that’s not even a day off. The date of the vote is announced well in advance, a two-week-long window is enough to ensure everybody who wishes to vote has a chance to do so. Making votes longer increases churn and I’m afraid will make the voting period more heated.

To help try to wrap this up so we can consider this settled and still hit a Dec 1 resolution of at least which governance model we want, here is what I can tell is potentially an open issue.

Ballots private during voting?

I think the suggestion is to use public-key cryptography where a neutral third-party (i.e. Ewa) holds the private key and we all use a public key committed into the voting repo.

If we do this, I personally have no issue with Ewa holding the private key.

As for actually doing this, it will make voting harder if e.g. someone is on vacation during the voting period and can’t do any better than web access. With no encryption we can all at least do this through a GitHub’s web UI. Adding encryption will require an appropriate laptop or figuring out some web page that can handle the encryption on your behalf.

I personally prefer not bothering with encryption because:

  1. It’s simpler not to.
  2. I trust people not to peek.
  3. I personally don’t care even if people do peek. :slight_smile:


We have @dstufft advocating for STARS, but then we have @cjerdonek advocating for IRV. It seems it comes down to whether you prefer the winner to make the most people happy or the least people grumpy (i.e. do you maximize for cheering crowd or shoulder shrugs :wink:). There doesn’t seem to be a swell of support for STARS so I say that unless more folks come forward advocating for a voting system change we stick with what is already in the PEP and go with IRV.


Here’s a quick stab (assuming IRV and no encryption).

Please rank every choice starting at 1 and ending at 6 by entering your rankings between the square brackets
(e.g. `[1]`, with 1 being your most preferred choice and 6 being your least preferred).
You may run `XXX` against your ballot to verify it has been filled in appropriately.


[] PEP 8010: The BDFL Governance Model (Warsaw)
[] PEP 8011: Python Governance Model Lead by Trio of Pythonistas (Wijaya, Warsaw)
[] PEP 8012: The Community Governance Model (Langa)
[] PEP 8013: The External Council Governance Model (Dower)
[] PEP 8014: The Commons Governance Model (Jansen)
[] PEP 8015: Organization of the Python community (Stinner)

Ah right, a big difference is that the start of the vote is announced in advance here. Voting to nominate a new core developer or voting on a PEP is usually not scheduled, and starts as soon as someone opens the vote. So maybe it makes more sense to leave the vote open longer if the vote is not announced in advance.

Thanks for your explanation, it makes sense :slight_smile:

1 Like

Is there a deadline for modifications on this PEP? For example, I would prefer that this PEP is no longer modified while the vote is happening :slight_smile:

Good point. I added the following to PEP 8001:

+To ensure the vote is legitimate, the aforementioned PEPs must not be
+modified during the voting period.

I would recommend 48 hours prior to cutoff to be the target for last modifications.

I wonder if we should go into this much detail in the “consitution”? Perhaps details of the voting process should be delegated to a later PEP? Then only the ground rules for voting on that PEP and on membership of the supreme council need be nailed down in the constitutional PEP.

Note that @njs also suggested a third alternative, a Condorcet system which @dstufft calleed the Schulze method.

FWIW, after having taken considerable time to read this discussion and about voting systems, I am genuinely
troubled by the chaotic properties of IRV, and would greatly prefer something like the Schulze method.

1 Like

FWIW I agree.

So I will say that I’m still not worried about IRV even after this discussion and what research I’ve done as this isn’t your typical vote for public office, i.e. we are not voting in an individual who may be incentivized to game the system.

True. I too am not worried about tactical voting or “gaming the system” in this vote.

What I am worried about is that IRV leads to surprising results in many common cases; results of a kind that I find unsuitable for the decision we are making.

To clarify my worries, here is a relevant quote of @dstufft from the mailing list:

Over a decade ago, Ka-Ping Yee (who used to be very active in Python development) ran some visual voting simulations on 5 popular systems, which scared him (& me) away from IRV forever:

The following images visually demonstrate how Plurality penalizes centrist candidates and Borda favours them; how Approval and Condorcet yield nearly identical results; and how the Hare method yields extremely strange behaviour. Alarmingly, the Hare method (also known as “IRV”) is gaining momentum as the most popular type of election-method reform in the United States (in Berkeley, Oakland, and just last November in San Francisco, for example).

I recommend following the link to Ka-Ping Yee’s article, which is a concise and clear illustration of actual differences between various voting methods. The graphs are particularly fantastic.

1 Like

So what’s unsuitable? So far I have yet to hear anyone say “if this governance PEP is chosen I’m quitting” and no one has said that IRV is bonkers-horrible such that any vote with it will be considered invalid. And pretty much any voting system that isn’t first-past-the-post is potentially “surprising” simply because of the complexity of the system. IOW there is no unsurprising result unless we use FPTP and I think no one really wants that (especially when the commons-like model will get hit the hardest due to vote splitting and that seems unfair whether you prefer that governance model or not).

OK, so people want something that helps stop that. IRV/Hare – yes, I looked at Ping’s pretty pictures :wink: – made sense to us in the room as it’s easy enough to explain and enough of us were familiar with it. Obviously it isn’t perfect, but no voting system is. So we went with what we know and wouldn’t penalize the commons-like PEPs.

But people continue to debate this. The problem is that there seems to be the following situation:

  • @njs like Schulze/Condorcet with some tie-breaking rule developed by Debian
  • @dstufft likes STARS
  • @taleinat might like Borda (can’t tell where you actually fall beyond “not IRV” as the closest you said was you would “greatly prefer something like the Schulze method” without explicitly stating your preference)
  • @cjerdonek likes IRV
  • The rest of us who are fine with IRV because we don’t care or aren’t as worried about potentially odd results :smile:

IOW the detractors are still seemingly outnumbered by the silent majority. But more crucially, those against IRV seem split on an alternative to promote. So just like any other PEP we have passionate detractors, but as of right now there simply isn’t enough consensus among the detractors to have a groundswell of support to change the PEP. And as things currently stand we could potentially do a poll here on Discourse to see if there is enough support, but that’s FPTP, and right now the alternatives will vote split and it won’t go your way. :wink:

There’s also the point of trying to get this whole thing done. We need this locked down by Nov 1 so we can vote 15 days later and enough people are comfortable with the PEP as-is that moving that date for a debate we all know has no perfect solution and could go on forever doesn’t seem worth delaying a decision.

So here’s my suggestion to those who want a change away from IRV (and this is just me suggesting a potential way of getting what you want; I’m only one of nine co-authors on this PEP so no promises on my part this will even work):

  1. Agree among yourselves to an alternative (I personally would strongly suggest something simple to explain, e.g. Borda); you probably want this resolved ASAP
  2. Start a new topic with a poll between IRV/status-quo for the PEP, your proposed alternative, and “don’t care” with a deadline of no later than Monday, October 30 EOD to get results
  3. We can discuss the results of the poll on Tuesday
  4. If the discussion leads to the PEP needing an update then we can do so on Wednesday and have it locked down to announce on Nov 1 that it’s final and this is how we plan to vote starting Nov 16

Notice how I am not volunteering to do any of this as I fall into the “content/don’t care” camp for the PEP as-is and I’ve already done way more legwork than I should on this topic considering I’m still on my volunteer break (IOW please respect my time off, so no more private emails on this topic). :smile:

For the record I’m perfectly fine with Schulze/Condorcet. I think either range/score voting or STARS would produce a happy outcome for the maximal amount of people, but I think that Schulze (or another reasonable Condorcet method) is probably roughly close and is significantly better than IRV.

Schulze method is just as simple for voters (in both cases you’re just ranking your choice from highest to lowest). It’s a bit more complicated to actually run the election, but it’s not too bad and a quick search suggests there are multiple things written in Python that implement it anyways.

I don’t know how others feel about the Schulze method though, but I think it’s reasonable enough?

That’s a good idea. I’ll start the new topic to get this rolling and resolved in some manner ASAP.

For anyone else looking for it, the new topic is here: