[VOTE] Changing PEP 13 to clarify tiebreaking for SC elections

Committers
,
1

The text about tiebreaking, in SC elections, was created when Block Approval was in use. When we voted to adopt Bloc STAR instead, Guido left that text alone, thinking it was “clear enough” as is. But people have disputed what it means, and explicit is better than implicit.

So @zware opened a pull request to clarify the text:

 * 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
+  modified to use the `Multi-winner Bloc STAR ... approach. If a tie that is not
+ automatically resolved by the election software occurs, it may
   be resolved by mutual agreement among the candidates, or else the
   winner will be chosen at random.

The thrust is that a voting service may fully automate tiebreaking, and allow no possibility for candidates to negotiate among themselves. This wasn’t a problem under Block Approval, because it only had one step. But under Bloc STAR, a K-winner election may tie internally as often as 2*K times, and voting services generally don’t allow for pausing the scoring process waiting for manual instructions on how each tie is to be resolved.

Time to put it to a vote:

From PEP 13:

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.

Since the next SC election is coming up ooon, time is of the essence. Here’s the poll:

Adopt or not?
  • Adopt the proposed changes to PEP 13
  • Do not adopt
0 voters

@gpshead, could you please work your bcc email magic to alert voters about this poll?

EDIT: the poll is configured to close at 2025-11-12T06:00:00.000Z. Why? “About two weeks” from its posting date. If people want to dispute that, please supply the precise string you’d like to see instead. Note that results won’t be visible (not even to me) until the poll closes.

EDIT: this is an anonymous poll, although voting is restricted to committers. Nobody will see how you voted, or even that you voted. Although my understanding is that Discourse admins (not “just” moderators) can access that data, if they want to.

5 Likes
2

For those who haven’t been following along closely, related discussion can be found in the Finding a Bloc STAR provider thread around and beyond message #87, which includes some links to other relevant messages on the PR that created PEP-8107 for this years SC election.

5 Likes
3

Is the tiebreaking protocol that the software uses delegated to the implementation, or is it specified in advance? According to this page (linked in the other thread), it seems like BetterVoting has a tiebreaking protocol that falls back to random choice. It is not clear if that counts as the software automatically resolving the tie or if the fallback clause in the PEP itself (where the candidates are given an opportunity to negociate a solution) kicks in before the software’s random selection algorithm comes into play.

2 Likes
4

The PEP specifies the voting method to be used (Bloc STAR), but that’s all. It so happens that the service we’ll be using for the upcoming SC election does resolve ties all on its own, so the “not automatically” part of the new wording doesn’t apply at all in this case . Under a different service, or it we scored ballots ourselves, then it may apply. The PEP intentionally doesn’t commit to any specific way of how scoring will be done.

I suggested more words for this at the start, but was persuaded it was “too much information” to bother people with :smile:.

STAR’s tiebreaking protocols are almost[1] wholly specified. “At random” is its last resort among 4 tiebreaking criteria, but the PEP makes no distinctions among what the criteria a service may use are.

The time to worry about such “quality of implementation” issues is when picking a service to begin with, and the PEP doesn’t intend to address that.

  1. it doesn’t specify the precise mechanics of how randomness is approximated ↩︎

5

A quick bump to remind committers that this vote closes in less than 2 days. Thanks to all who already voted - and nags to those haven’t yet :wink:.

4 Likes
6

The vote has passed with 97% of 38 voting to adopt the change.

Edit: PEP PR merged: Poll required: PEP 13: Clarify tie resolution by zware · Pull Request #4672 · python/peps · GitHub

4 Likes
7

Or, for those who don’t trust floating point calculations :wink:,

>>> from fractions import Fraction as F
>>> F(37, 38) >= F(2, 3)
True

Thanks to all for getting this done!

10 Likes