Changing PEP 13 to adopt Bloc STAR voting

Committers
1

I am proposing to adopt STAR voting starting with the elections for the 2025 Steering Council term. Unlike my preceding post (Adopting STAR voting), which was about refining the proposed changes, this thread (topic) is the actual poll, so please pay attention. I’m also planning to send an email to all current core devs to alert them of this poll.

The voting method is fixed by PEP 13, which has a specific procedure for changes. After a Discourse poll about how to change PEP 13, I believe an anonymous Discourse poll with a two week voting period is sufficient to make this change. I am using a variant on the template that we’re using to accept new core devs.

Here are the proposed changes. (See also GitHub PR 3958.)

First and foremost, I propose to change the voting method. The voting is currently described by this bullet point (text to be deleted in italics):

  • Phase 2: Each core team member can vote for zero or more of the candidates. Voting is performed anonymously. Candidates are ranked by the total number of votes they receive. If a tie occurs, it may be resolved by mutual agreement among the candidates, or else the winner will be chosen at random.

My proposed change is this (replacement text in bold):

  • Phase 2: Each core team member can assign zero to five stars to each candidate. Voting is performed anonymously. The outcome of the vote is determined using the STAR voting system, modified to use the Multi-winner Bloc STAR approach. If a tie occurs, it may be resolved by mutual agreement among the candidates, or else the winner will be chosen at random.

In addition, I propose three more “mundane” changes, in diff format (sorry):

  1. A note about where to find the recommended Discourse template to run a poll for a new core developer:
@@ -270,6 +272,10 @@ It is granted by receiving at least two-thirds positive votes in a
 core team vote that is open for one week and is not vetoed by the
 steering council.
 
+.. note:: The devguide has a `suggested template
+   <https://devguide.python.org/core-developers/become-core-developer/#poll-template>`__
+   to use for such votes.
+
 Core team members are always looking for promising contributors,
 teaching them how the project is managed, and submitting their names
 to the core team's vote when they're ready.
  1. Allow changing notes and sections with historic information without a poll or vote:
@@ -301,6 +307,10 @@ Changing this document
 Changes to this document require at least a two-thirds majority of
 votes cast in a core team vote which should be open for two weeks.
 
+No vote is required to update note blocks and the "Current steering
+council" and "History of council elections" sections with current
+information.
+
 
 History
 =======
  1. An additional line in the History section:
@@ -343,6 +353,7 @@ History of amendments
 ---------------------
 
 2019-04-17: Added the vote length for core devs and changes to this document.
+2024-XX-XX: Adopted Multi-winner Bloc STAR voting for council elections.

(Obviously the actual date has to added once the change is approved).

Here’s the poll:

  • Adopt all the above changes to PEP 13
  • Do not adopt
0 voters

(Thanks to @hugovk for proofreading this message!)

9 Likes
2

FYI as discussed in another thread, I went ahead and emailed (via a mass bcc:) everyone in our voter roles list with a link to this poll earlier today in hopes of attracting the attention of any voters not monitoring this forum closely.

I have also heard from Tim Peters privately who I understand Guido and and several others in our community have discussed voting methods at length with as well. I asked if he had any message to pass on regarding this change and he said this:

“”“”
I wholeheartedly endorse moving to Bloc STAR. Like Donald Stufft, I
don’t expect it will make much difference to results, but the
possibility for voters to express more of what they believe will make
voters happier about the voting experience, and that’s also of real
value as an end itself. Bloc STAR will also remain robust and scale
well if adopted for other PSF elections.

The only change I’d make to the proposed text is to remove the older
words about how to resolve ties. Tie-breaking protocols are already
fully specified by

and Larry Hastings’s voting library already implements them.
“”" - Tim

4 Likes
3

The page linked to above describes the Official Tiebreaker Protocol for STAR Voting, which applies equally well to Bloc STAR. These are automatic protocols you can use to resolve ties in the two rounds of a STAR Voting round (and Bloc STAR uses one round of STAR Voting per seat filled). However, it’s possible for ties to survive these tiebreaker protocols, at which point the Official Tiebreaker Protocol Step 4 says

In the event that a tie can not be resolved as above, the tie will be broken randomly with a method such as a coin toss or by drawing a name out of a hat.

I talked to Tim about tiebreaking more than a little; I got the sense that tiebreaking is a dull subject for election scientists, because it never happens in practice. Computer programmers like us fret about boundary conditions–election scientists wave their hands and move on, because that’s not the interesting part of designing electoral systems.

As mentioned, I implemented the Official Tiebreaker Protocol in my starvote library. But I also handle the case of a tie surviving the predefined protocols. The user of my library has a couple of choices on how to resolve an unbreakable tie:

  • raise UnbreakableTieException
  • plug in your own function / class to handle breaking ties
  • rule in favor of the earliest candidate(s) specified in a list you pass in
  • randomly pick from the tied candidates, using functions in the random module

The default mechanism is a fifth choice, kind of a combination of the latter two choices. Before running the election, I shuffle the candidates and print that shuffled list. If there’s a tie, I rule in favor of the earliest tied candidate(s) to appear in the list. The point of printing the shuffled list first is to avoid any possible claims of letting the outcome of the election influence the tiebreaking.

The downside of all this is that it adds an element of randomness to the elections, which some folks find distressing. It can be annoying to run an election five times and get different results. I have a todo item to add one or two more variants to address that. Instead of seeding the random instance from the environment (the OS entropy pool), I would hash the sorted list of candidates themselves, then use that hash as the seed for the PRNG. This should make it difficult to externally influence the result of the tiebreaker–but would make the tiebreaking itself deterministic. You couldn’t predict before you ran the election how the tiebreaker would rule, but the tiebreaker would do the same thing every time. Seems like a best-of-both-worlds situation. I feel compelled to point out that a certain election expert friend of mine didn’t like this approach; it seems fine to me, but their negative feedback has reduced my impetus to implement it.

4 Likes
4

Just a detail: the link is broken (there’s an extra> after the slash). Thanks for all the work!

1 Like
5

Extra > removed!

2 Likes
6

I know. He told me too. My position is to use this only if the voting implementation doesn’t handle a tie. If that never happens, well, great. If it somehow happens, at least we have a solution.

(Plus, 29 people have already voted, and it would be tedious to scratch that sentence from the draft change and start the poll over.)

3 Likes
7

As a couple recipients pointed out to me, I emailed a wider list of people than just the current committers/voters who can vote here. Apologies for any unwanted email to those who are no longer active. (Our voter roll has both a joined= and left= date field and I forgot to filter those with a left= field)

I’ll fix my simple script that generates the bcc: list of voters and check it in, with a test, with the other voter roll maintenance code in the voters repo.

2 Likes
8

Thanks for getting this started @guido and for the tiebreaker elaboration @larry! I do also like the hash-seed approach for tiebreaking, but as long as we have something and it’s unlikely we’ll encounter a tie[1], I think we’re good.

One thing I would like to see in future PEP 13 changes is a link to a PR/commit that actually implements the change. I appreciate the descriptive text in the proposal, but I’d like to see the actual diff for the proposed changes.

  1. famous last words? ↩︎

3 Likes
9

That can be found here: PEP 13: Add STAR voting and misc tidbits by gvanrossum · Pull Request #3958 · python/peps · GitHub

3 Likes
10

Sorry, that should have been added to the proposal. Thanks for linking to it here.

Since we’re already voting, I won’t make new changes there (except updating the date in the History section), unless the vote gets canceled and we are bikeshedding more about the exact text of the changes.

3 Likes
11

4 posts were split to a new topic: Soliciting feedback from a suspended member

12

If there’s a tie between N people, and there are at least N seats left, do we assign those N people to seats and carry on?

So would a tie breaker only be needed in the case that there are not enough seats to go around?

2 Likes
13

I expect so, but I’d rather not over-specify this in PEP 13 without knowing the implementation cost, and I don’t know how bettervoting.com does this.

4 Likes
14

Moreover, that’s just an optimization; the outcome should be the same regardless.

1 Like
15

This is embarrassing. I thought I posted the vote on Monday Sept 23, in which case I could close it now. But the Discourse date suggests I posted in Tuesday Sept 24 6pm – or possibly that’s the date I last edited the top post? Does anyone recall? I don’t want to close the vote prematurely – I thought the vote would auto-close at the designated date/time, but that also seems to be set to tomorrow. @hugovk Do you remember when I asked you to review it?

If no-one knows I’ll just leave it open until 6pm tomorrow (Tuesday).

16

I received the email about the poll at 01:52 GMT on the 25th, if that’s any help as a bound. Discourse is saying that the topic was posted at 01:00 UTC on the same date, which seems to be what you’re seeing too (adjusted for timezones).

A

2 Likes
17

It was after the happy hour at the sprint, which was Tuesday at 4pm, so I’d estimate somewhere between 5pm and 6pm. So that tracks with Adam’s timestamps :slight_smile:

18

It passed!

11 Likes
19

Before I check this in, I’m waiting on the SC to suggest how to handle the plan that this should go into effect after the upcoming SC election, for practical reasons (we don’t have the time to research the right voting platform to implement this).

See the PR:

20

Okay, here’s my plan. I am going to delay checking in this PR until after the upcoming SC election is closed. That way we don’t have to mess with the text to indicate that it goes into effect next year.

Again, the reason for the delay is that the upcoming SC election is very soon (expected early December). We would need to have a definitive choice of election platform and operational experience with using it properly to set up our election, and there just isn’t time to do all that before December. (I’ve confirmed this with Ee – they need at least four weeks to set up an election using the current Helios system, which they have used for all previous SC elections.)

I realize I made a mistake in the first line of my initial post in this thread – I said “starting with the elections for the 2025 SC”, whereas I meant to say “starting with the SC election in 2025”. In my previous post on the topic I was ambiguous, writing “for the 2025 SC elections.” That could be read as the elections for the 2025 SC, or the election in 2025. I know that I intended the latter, but I have no direct proof.

So if anyone wants to hold me to what I wrote, please don’t be shy! Please speak up and we can discuss alternatives. But be quick, or the election might have to be postponed for technical reasons. Sorry about this.

16 Likes