Yes, every time some core developer requests being added in the commiters group I added them almost immediately. For example, I added @nas some minutes ago after he requested admission. The other members of the commiters group can do it as well, but I am specially vigilant to add people as quickly as possible.
3 Likes
To clarify the instructions, people that want to be added to the commiters group need to go to:
https://discuss.python.org/groups
and click the “Request” button in the “membership” column.
1 Like
FWIW, I don’t see the point of all this energy being spent on choosing a voting method for this one-off vote. The voting method isn’t that critical here. Are we worried about legitimacy? Is there any core developer that is realistically going to be less than okay with any of the proposals?
I’ll reiterate the concern that we’re unnecessarily dragging things out. That said, if there are problems to address here then let’s do so. I don’t mean to discount the possibility. I just haven’t heard anything that applies to our one-off case specifically.
-eric
1 Like
I don’t think we’re dragging anything out here. Stopping this discussion won’t make the governance vote happen any sooner 
1 Like
Maybe but kind of voting system you use does impact on the outcomes you get. Plurality is awful and thankfully there seems to be no debate here about that. This is probably our best chance to pick a good system. Once it is established, it will be hard to change.
I have long advocated for approval voting. It has two good properties. First, it is extremely simple. For people who don’t care about the nerdy details, they can understand how it works and how to compute the results of the election.
Second, it forces people to make compromises. Being able to rank options from best to worst sounds better. However, for a well functioning organization, we usually want the option that is acceptable to the largest number of people. That’s what approval voting does. It forces you to make the hard choice when there are some options you don’t like as much.
I haven’t heard of the 3-2-1 system before. Given that Tim thinks its okay and that voting simulations show it works well, I like that option too. It matches the informal +1/0/-1 voting that we have been doing for years. It would be less likely than approval voting to create ties, I think.
I hope we don’t choose IRV but I guess I can live with it. It leads to some really weird outcomes in corner cases. It sounds simple and nice when you explain it to people but sometimes the behavior of these things is non-intuitive. Better than plurality but worse than all the other options discussed here, IMHO.
Schulze/Condorcet would be fine too. They have the disadvantage of being complicated and hard to compute the election result. Debian has been using the system for years though and it works well enough for them.
2 Likes
I voted for all the options in the poll, because I really don’t care all that much for a one-shot vote.
But if it’s done once, that will be “a precedent” cited for the next vote, and on & on. Since I really dislike IRV (despite that I can live with it once), I’d rather nip it in the bud right now.
There’s apparently no infrastructure in place anticipating IRV, so the only real cost to switching is rewriting part of PEP 8001.
I don’t particularly like the idea of legitimacy, because there’s no actual standard for what is legitimate other than it’s what we’ve agreed on. Throwing darts at the proposals until a dart hits one is no less legitimate of a way to choose something, if that’s how people want to choose. Instead I prefer to think of it as maximizing voter happiness.
IRV is most likely to produce a “poor” outcome when there are competing options that are all “strong”, and in cases like that it’s most likely going to produce a result that does not represent the option that most people prefer over the other options. IRVs main benefit over plurality, is that it makes it safe to vote for an option that is almost certainly not going to win (third parties in most elections) but one of it’s main drawbacks is that it is not safe to vote for a strong, but otherwise not strong enough to win, candidate over one that is stronger.
This to me seems like the most like situation we are in? We have a number of proposals and there are probably more than two of them that are strong candidates, which is the case that IRV performs the worst in. It seems counterproductive to choose IRV when it seems to me that our situation is likely to fall squarely in IRVs worst case.
1 Like
In case it helps, Condorcet methods do have this property in the subset of elections where there’s no weird non-transitive preference cycle.
I didn’t intend the poll to be any kind of binding election, and anyway yeah like you say, I’m just some guy, so I can’t start a binding election anyway. All I meant was as an organized way of gathering people’s answers to the questions: “If we used this system, would you feel comfortable filling out your ballot, and would you feel comfortable that the final result would be legitimate?” Of course, the reason I’m asking that is that I think it would be good if our actual PEP 8001-sanctioned election used a method where a lot of people can answer “yes” to those questions, and bad if we use a method where a lot of people answer “no”, but it’s still just data to inform the discussion.
Tie breaking
Since I wrote the poll options, let me say that I didn’t mean that that tie-breaker was the only option; I just copied that part from the current PEP 8001 draft. See above about this being an informational poll :-).
I also feel like this ought to be something we can resolve ourselves. But, from discussions at the summit it seems like there’s an overwhelming supermajority of core devs who want to get this resolved in a single round, so there’s a strong desire for some kind of tie-breaking mechanism beyond “go back and restart the whole discussion from scratch”.
Has anyone asked the PSF board if they’re willing to act as a tie-breaker? I can imagine them coming back with “okay, we voted and the resolution that won is: you all need to figure it out instead of putting this on us”…
Given that we’ll all be able to see the votes while the election progresses, I guess if there is a tie going into the 11th hour, some people may just switch their votes to break the tie… though if 2 people do this it might just recreate the tie :-).
Given that some people think that we should sort out ties ourselves, and others want to make sure the voting doesn’t go on indefinitely, maybe a good compromise would be:
- If there’s a tie (or if we use “pure Condorcet”, a cycle) at the end of the voting period, then extend the voting period for 1 week, to give us a chance for discussion and for people to change their votes and hopefully resolve it.
- If even that doesn’t work, then [ask the PSF board / use
random.choiceon the top contenders / …]
My honest opinion is that trying to sort out tie-breaking ahead of time is probably a waste of time, because if we actually end up in the situation where it matters and isn’t resolved trivially, then it will mean something weird is going on, and we’ll actually want to do something unpredictable, like edit some proposal’s text to resolve the disagreement. But since so many people seem to want to have a tiebreaker selected ahead of time, I’m trying to figure out what would make them happy…
2 Likes
It’s important to note, that this potentially isn’t just for a one-shot vote.
PEP 8010 uses the voting process, as defined by this PEP, to select the new “GUIDO” every 3 releases.
PEP 8011 uses the voting process, as defined by this PEP, to further refine PEP 8011 itself as we get experience with the governing model.
So depending on what the ultimate outcome of the election is, at least two of the proposals will continue to use whatever voting mechanism is enshrined in PEP 8001, so it’s not actually accurate to say that this is a one-shot vote, because whether this is a one-shot vote or not depends entirely on which proposal ultimately wins.
1 Like
Ah! Thank you - I missed that 
In that case, I’m going to retract my “approval” for IRV in the poll.
That seems like a reasonable compromise to me.
Another option would be to change the last step to a second vote that must conclude within a month of the last vote where we hold a plurality/first-past-the-post vote for those involved in the tie/cycle. If we tie even in that instance then we are a very special group of individuals.
@guido, I was wrong. Donald Stuft points out that other PEPs point back to PEP 8001 to define the voting method they have to use. So I’m retracting my “OK” poll vote for IRV. I was only willing to endure that for a one-shot.
Back in 2015, for a few months we had an Elections Working Group that was active. David Mertz and I (with input from others) worked out a tie-breaking scheme that was random, but reproducible, verifiable, and impossible to manipulate or out-guess in advance. The key is to use some unpredictable public info that can’t be known before the election ends.
I liked using the next trading day’s open, high, low, and closing values of SPY, expressed in pennies. That’s an ETF tracking the theoretical value of the S&P 500 large-cap equity index. It’s the most heavily traded equity on the planet, with billions of dollars worth trading every day. Nobody in the PSF has enough money to influence it a tad. Giant players and hedge funds trading in it watch each other like hawks to make sure their peers aren’t manipulating it either (notwithstanding that they may collude with each other to influence it). In addition, SPY price statistics are freely available from many sources, and archived forever. And if these statistics were in fact predictable, the world would have a bunch of triillionaires who cashed in before trading in SPY was halted
Anyway, use that to seed a standard crypto hash, and use the latter in CTR mode in a deterministic way to associate a “random” bytestring (the hash’s digest) with each candidate. Whoever of the tied candidates gets the lexicographically smallest associated string “wins”. Or largest. Doesn’t matter one whit, just so long as which is defined in advance.
In its original context, we actually wanted to impose a “random” total ordering on candidates, in case, e.g., there was a 12-way tie for the last 7 seats open on the PSF board. What we’re trying to do here is easier than that.
The Python code I wrote for that still works today, and delivers exactly the same results as it did then. That’s one reason for using a standardized crypto-hash (its output is defined, in a platform-independent way, forever):
https://mail.python.org/pipermail/elections-wg/2015-June/000211.html
So if people really want to solve this, it’s already been solved. Or maybe they want to argue instead. Surprise me .
I like approval voting. However, if the number of voters is small, that could be a reason to use a ranked system. On Ka-Ping Yee’s simulation plots, approval voting produces essentially the same regions as Condorcet but the boundaries are fuzzy. If there are tens of thousands of people voting, I think approval voting is better because it is so simple. However, for a small number of voters, I can imagine the approval voting boundaries get fuzzier yet and diverging from the more “ideal” Condorcet result. So, maybe we should give voters the ability to rank options.
I don’t like Condorcet methods because you need a computer program to compute the election result. So, for a small number of voters, I’d favour the 3-2-1 method. The fact that it mimics our +1/0/-1 python-dev informal voting system is a nice bonus. 
I’d be interested to see Ka-Ping’s models with 3-2-1 thrown into the mix. Maybe I’ll take a crack at trying to re-create them.
1 Like
Bah ha ha. Guido is complaining about this topic being “nerdery excessive”. Now you pull out using SPY as a random number generator. I’m not sure if you are trolling him. I think the idea is fine. If you want a way to break ties that cannot be gamed, that’s certainly one way.
Nope! People do want a way to resolve ties. If Guido butts in to say “but I personally don’t care”, he’d be the one trolling :<0.3 wink>.
I suspect this is harder than you may think at first glance. The message I linked to was the tail end of a verrrrrry long discussion. Which I expect to see replicated here, in every ultimately doomed detail .
FYI, there are more “Yee Pictures” here, and a link to the C code used to produce them. I haven’t tried it.
One thing I’m cautious about with respect to 3-2-1: for 2 candidates, it just counts whichever is favored most. For 3, the same after throwing out the one with most Bad ratings. So it would be astonishing if it displayed any “weird” behavior in those cases.
Going higher than 3, it only retains the 3 with the most Good ratings, which again must weed out a whole universe of pathologies. But in cases where there are more than 3 strong candidates? Then just keeping the 3 with the most Good ratings seems pretty arbitrary. I suspect that’s “why” it doesn’t get the very best VSE scores in the graph Donald Stuft reproduced before. And also why STAR does better (it uses range voting rules to whittle its candidates down to the top two scorers, which is potentially a lot more nuanced).
I’d risk it just based on simulation results, but I understand (and secretly approve of) being reluctant to try something so new. This article sure makes it appear to still be a work-in-progress, adding various tentative complications. Although, offhand, I kind of like that its “Undelegated 3-2-1” variant allows an unrated candidate to act more like a -0 vote than a +0 vote in some cases. Against that, I don’t think I understand its “Delegated 3-2-1” variant at all 
I don’t know why you are insisting so much on a tie break
method. If we have a tie, this is a clear indication that
we have to continue discussions.
I’d even go as far as requiring a 2/3 approval for acceptance
of a particular model to make the vote valid in order to avoid
losing larger fractions of the core developers in the process
or creating problems with parts of the core devs not accepting
the new approach and ignoring or working against it.
1 Like
I accidentally brushed my phone and seem to have registered a vote!
1 Like
I believe that in the current incarnation of how our vote is structured a super majority is unlikely unless there is clear and away a highly preferred option. If there isn’t one, than I’m not sure that repeated rounds of voting will make there be one (except that people are more likely to compromise and vote dishonestly in order to get a decision made and push whatever proposal is closest to the threshold over the edge). I think we’d be more likely to be able to work towards a super majority if there was a single proposal, and we had rounds of voting between rounds of discussion and compromise-- but that’s not how we’ve structured our decision making process.
I’ve personally been waffling back and forth on a tie breaker, which includes whether we should use a “Pure” Condorcet method, or something like Shulze that includes in it what is effectively a tie breaker for the pathological case where there isn’t a Condorcet winner (The basic example example is candidates, Rock, Paper, Scissors, where there is no single answer that beats all the other answers). On one hand I think it sounds really nice that we say unless there is an option that is preferred by all, that we’d do “something” until there is. On the other hand, the number of people we have voting is low enough, that I’m not entirely sure that the difference between an arbitrary tiebreak and a dsicuss + revote exists in practice.
For example, for an actual tie, where you have two options with exactly the same number of votes, you’d change the outcome of the election if a single voter changed their preference. Even in the case of a Condorcet cycle where you have the Rock, Paper, Scissors scenario, you’re likely talking about a very low number of people who need to alter their votes to “break” the cycle and resolve the election.
Worse, I think with the low number of people we actually have voting, that the result isn’t likely to be stable and if we re-run the election immediately there’s a reasonable chance we get a different, non tie result (even if we re-run it without even tallying the votes first).
With all of that, any of the methods (including re-running the vote) seem like they’d produce at least somewhat of an arbitrary result, and if we’re producing an arbitrary result either way then it seems like we might as well produce one during the first round of voting.
3 Likes