Python Governance Electoral System

Which we also had for this particular sprint. Unfortunately, there were no notes from this discussion to share (since our volunteer notetaker wasn’t interested in four hours of voting discussion) and the PEP took longer than hoped to be published.

Ideally, this discussion would have been ongoing during September, so that our plan of “those who really care can decide for those of us who don’t” was on schedule. Better late than never, though with the participants changing over time I don’t see how we can possibly get consensus out of this working group.

While it would have been nice to have this ongoing since September, PEP 8001 was posted on Oct 15th, immediately met with some people (myself and @njs) expressing concerns declared Active by fiat on Oct 22nd, more concerns were raised both on python-commiters and here and now it’s being strongly suggested that we have to conclude this discussion today.

The messaging, as far as I saw, around PEP 8001 was that Raymond was going to write up a proposal and then it would be discussed. That’s fine, but by simply stating that, it meant that nobody was likely to undertake that effort otherwise, since it was already generally understood that a proposal would be forthcoming. Then that proposal wasn’t posted until 2 weeks prior to the “deadline”, and once people started raising concerns they were largely met with “well all systems have problem, and this is what we already wrote the PEP to be”, and then since there wasn’t much time left to meet the “deadline”, started being “You need to come up with consensus within a short period of time, even though there doesn’t exist consensus on IRV or we’re going with IRV”.

Thus while the decision wasn’t technically made at those sprints, the effect is that it practically was, because:

  1. Competing proposals were discouraged by stating that there was going to be a single PEP, and there’d be discussion around it.
  2. Discussion happened in a place where only a few people could be.
  3. The PEP was then not published until there was very little time to change it.
  4. Concerns were dismissed as not being serious enough to risk change this close to the “deadline”.

So far I’ve only seen one person who is actually pro-IRV (@cjerdonek), everyone else seems to either be against IRV or don’t care, but don’t want to change what was already decided at the sprints, but it’s hard to tell for sure since it’s a bit reading intentions into people’s posts.

1 Like

FWIW, I’d like to see the same voting mechanism used for electing
PSF board members. It’s not perfect either (no voting mechanism is),
but it’s known to be working and accepted in the Python world.

PS: This is the first time I’m using email to reply to discourse.
Let’s see how this comes up in the forum… :slight_smile:

Thanks,

Chris, I’ve also been careful to say “most”, with you being the unnamed exception :wink:.

Later-No-Harm (LNH) is just one of dozens of formal properties a given voting system may or may not satisfy. As you noted, it’s impossible for any system that statisfies the Condorcet criterion to satisfy LNH too, or vice versa. I think it’s fair to say that most people find the Condorcet criterion (“if some candidate beats all other candidates one-on-one, they’re the winner”) far more compelling.

Indeed, IRV is one of the only systems in actual use that satisfies LNH. Perhaps the only? Random Ballot satisfies LNH too, but that’s not exactly a good argument for it :wink:

And it’s not true that adding preferences to an IRV ballot can’t “hurt” you in other ways. You can’t hurt your favorite, but you can hurt your lesser preferences’ chances of winning.

To me, the essence of your complaint is that if you’re truthful about your preferences in other systems, that may cause your favorite to lose under other systems. The fundamental problem is that I see that as a good thing: if, overall, society prefers some other candidate to my favorite, they probably should win. If, e.g., I slightly prefer A to B and am truthful about that, and B wins “because” I was truthful about that, no, they didn’t: B won because the voters as a whole, including but not limited to me, preferred B overall.

IRV intentionally blinds itself to the totality of information voters give, dribbling it in to the process one round at a time. This allows it to satisfy LNH (your lower preferences are invisible to it until your favorite is eliminated), but at quite a cost.

That would be a preference for Approval voting then.

As an aside, this seems to have come through fine as far as I can tell!

1 Like

Just a nerdy gloss: part of the thinking is that if you contrive the rules to satisfy one of those, it’s likely it will fail the other one “badly”. Better to fail both “mildly” - minimize the worst-case harm across both, rather than eliminate all harm in just one case.

Probably no better than any of us. :wink:

My expectation would be they would choose another voting system that didn’t result in a tie and have that make the decision. Making the ballots public and requiring they be fully ranked means there are alternative voting systems that could be used to calculate another winner easily (e.g. anything in that poll except Approval, but Borda could also be added to that list). And we can have the PEP explicitly state we are turning to the board to choose an alternative voting system that doesn’t lead to a tie based on the already cast ballots.

I would suggest we choose the backup voting system ourselves, but based on how this conversation has gone I don’t think that’s a necessarily easy thing to do. :wink:

I say give the poll until end-of-day today in hopes of at least pushing to double digit voter count and to see if there’s a bit more clarity in the top preference. Based on the outcome of that we can update the PEP tomorrow and have this all squared away so we can consider the PEP finished for November 1.

@malemburg please do make sure to vote in the poll in this thread (not sure how it would have shown up via email).

Actually, we could just rank the voting systems that work with ranked ballot based on the poll and we just work our way down them until we get a clear winner.

I don’t think a voting system can help with ties for governance
systems. If half (or almost half) the developers don’t like a
model, there’s no basis for this being a viable working solution.

It’s a signal that the proposals are not ripe for voting yet.
We then need to go back to the drawing board in such a case and come
up with a compromise which gets enough votes to provide a work basis.

1 Like

FYI: The poll was not announced on the mailing list and the system
has not generated an invite for it either.

It’s probably better to point everyone to the poll on the mailing
list.

I had a look at the poll, but all entries say “with ties thrown to the
PSF board to resolve”. I would vote for “Approval voting”, but don’t
agree with getting the PSF board involved in core development or
having some other forced tie break mechanism.

As mentioned in my earlier reply, a tie means that we have to
resolve the issues with the competing PEPs and come up with
a compromise.

1 Like

Since we can see who voted for what options, I think it would be fair to vote the closest options, and then comment on where you differ from the actual voted option. IOW if we can tweak an option to be more satisfactory, then that seems reasonable to me. I don’t think the specific procedure there needs set in stone rather than giving us some direction into how people are generally feeling about the variety of options.

1 Like

Fine by me, but I’m still on my October break from volunteering so I will leave that up to someone else to post.

Done, here:

https://mail.python.org/pipermail/python-committers/2018-October/006326.html

1 Like

I really don’t care, and I find all this voting system nerdery excessive. But I have a question. Is this poll about the voting system we use to choose a “constitution” (one of PEP 8010-8015) or is it also about the voting system used to decide other things that the selected constitional PEP says need to be voted on? (I hope it’s the former.)

2 Likes

Then you should select every option in the poll. I did :wink: But, ya, I do think IRV is a relatively poor method.

My understanding is that this is specific to PEP 8001, which currently specifies that IRV will be used, “to choose which governance PEP should be implemented by the Python project”.

2 Likes

And now I’m getting private email from people who can’t vote. How can committers who never finished signing up for this site get approved “quickly”?

Thanks.

I voted and already left a note about the tie breaking option (there doesn’t appear to be a way to add a comment to a poll vote).

1 Like

I think Pablo can add new users to Discourse quickly. Right @pablogsal ?