PEP 8107 - Python Steering Council Election - 2026 Term by ewdurbin · Pull Request #4664 · python/peps · GitHub has been opened, I would appreciate careful review of the election configuration by folks familiar with Bloc STAR and bettervoting 
6 Likes
@ArendPeter I do not seem to be able to add a hyperlink. Can you update on the status of this?
Sure thing. I was originally planning to include this with a bigger UI rework, but that’s been taking longer than expected. I just created a small PR for just the hyperlink feature. Our team will have it reviewed and merged in the coming days but in the mean time you can use the video in the PR description as a reference for what to expect.
PEP 8107 - Python Steering Council Election - 2026 Term by ewdurbin · Pull Request #4664 · python/peps · GitHub has been opened, I would appreciate careful review of the election configuration by folks familiar with Bloc STAR and bettervoting
Thank you for all the details, I left some comments 
Regarding Editable Ballots, we’re in the final stages of implementation. I’ll plan to leave another update on the thread later this week with more information in case you’d like to use it for the mock election.
1 Like
Has cost been resolved? Best I can tell, due to some potential voters being changed to “inactive” status, we may have fewer than 100 voters (as of right now, less than 90, although some of those slated to become “inactive” may become “active” again).
This doesn’t need (& probably wouldn’t benefit from) public discussion; just want to make sure everyone’s on the same page in advance, to prevent hard feelings later.
2 Likes
I doubt that the cost will be such that it will not be approved by the Steering Council and paid by the PSF.
4 Likes
No cost , I appreciate you all working with us and choosing Bloc-STAR. That may change in the future when the app is more fully released, but for this cycle we’re happy to offer it for free.
If the election exceeds 100 voters, then it will require an override but I can add that.
18 Likes
Thank you! That’s gracious of you, and appreciated 
.
I anticipate that this election will go smoothly, and that people will find it a much better voting experience all around than they’ve become used to. In which case, I’ll suggest that the PSF move to Bloc STAR for PSF Board elections too. Those attract on the order of 10x more voters.
Now we just have to discuss how much the PSF will charge you to mention that the PSF uses your service 
6 Likes
@tim.one Awesome! Yeah and it would be really exciting to see the board using Bloc STAR as well
@EWDurbin I have some follow up feedback on the PEP 8107 - Python Steering Council Election - 2026 Term by ewdurbin · Pull Request #4664 · python/peps · GitHub . None of it is particularly urgent, so feel free to wait until we have the editable ballots feature ready. I’ll keep the thread updated.
Tiebreaker
I think it would be good to include a section clarifying your tiebreaker protocol in case it becomes relevant. I’ve written up a description for the current tiebreaker at BetterVoting | Create elections & polls that don't spoil the vote .
I have this in a thread on the PR as well, PEP 8107 - Python Steering Council Election - 2026 Term by ewdurbin · Pull Request #4664 · python/peps · GitHub . Sounds like this will need to be a Pep 13 update.
Results Format
I’ve chatted with others at Equal Vote on the best way to display Bloc STAR results in a pep friendly way and we have a recommendation. Here’s an example for a 3 winner election with 5 candidates where the candidates elected doesn’t necessarily match the score order. This can be discussed further in the final PR publishing the results, but I wanted to have this out there while it was on my mind.
The 3 winners are:
- Andre
- Bella
- David
Candidates Total Score Andre 1002 Bella 998 Cedric 885 David 721 Ella 623
Round 1 (Andre wins)
Highest Scores: Andre (1002 stars) and Bella (998 stars)
Runoff: Andre (200 votes) > Bella (100 votes)Round 2 (Bella wins)
Highest Scores: Bella (998 stars) and Cedric (885 stars)
Runoff: Bella (180 votes) > Cedric (120 votes)Round 3 (David wins)
Highest Scores: Cedric (885 stars) and David (721 stars)
Runoff: Cedric (130 votes) < David (170 votes)
Candidate Hyperlinks
This feature is live, and the instructions can be updated in PEP 8107 if appropriate.
Editable Ballots
Still in progress, it’s in the final stages.
AoE Timezone
I’ve added Baker Island as an option in the timezone list.
3 Likes
Ya, the text there is probably left over from Block Approval:
If a tie occurs, it may be resolved by mutual agreement among the candidates, or else the winner will be chosen at random.
The problem, while ties are unlikely under STAR, there are ten opportunities for them in SC elections: 5 winners means 5 rounds of selection, and each round can theoretically ties in its “score” stage and/or in its “preference” stage. Ties have to be resolved before it can proceed to the next step.
Then again, playing lawyer here, we can read PEP 13 as meaning “any tie remaining after all the tie-breaking protocols in the STAR spec have been tried without success”. Those are the cases where the STAR spec falls back on “random” as a last resort.
But there are still theoretically 10 chances for that to happen in an SC election. There is no option in the software to put scoring on hold and wait for humans to “pick a winner” before moving on.
So, in reality, we accept what the software does, or suck eggs 
.
So it would be best to yield to reality, and clarify in the current doc that “random” will be used as a last resort for tie-breaking, and specifically the form of randomness BetterVoting already implements. Or just say we accept BetterVoting’s spec in full (which includes randomness as a last resort).
There are better ways to “do randomness”, toward which I’ve contributed code, but it’s not been a priority for anyone, and won’t be implemented for the current election.
2 Likes
2 Likes
Indeed, and I think common understanding under the previous voting method is that tie-breakers requiring mutual agreement are only those ties that remain at the end of the final election results. So if Alice and Bob are tied at the end, after all the dust settles, they would have to come to a mutual agreement or randomness would ensue.
Probably so, but timing is uncertain given the 2 week requirement for changes to PEP 13. In the meantime, PEP 8107 should mention the default bettervoting tie breaking scheme.
3 Likes
There’s plenty of time for a d.p.o. poll (open for 2 weeks) to vote on replacement text. To try to move this along, I suggested new text here:
I would prefer that someone else follow through, though. - people are likely sick to death of me typing about it all .
I believe the next steps would be to create a PR, then open a vote in Committers category on DPO. I don’t have the bandwidth to drive that.
1 Like
If someone else creates a PR for this in the peps repo I will send out the poll.
1 Like
I would rather see people argue about the text in full view rather than have it restricted to those who bother to follow comments on a PR. When the text settles down, then it’s time for a PR and a poll.
Current text (part of PEP 13’s account of Steering Council elections):
- 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.
Proposed text (new 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, if the voting service in use resolves ties on its own (typically by some form of randomness), the service’s choices will be accepted (in a multi-stage voting method, ties may occur more than once as the process proceeds). Else it may be resolved by mutual agreement among the candidates, or else the winner will be chosen at random.
But, again, I don’t want to drive this beyond getting it started. I see Guido volunteered to post the poll (when it’s time) - and thanks for that! Who’s willing to make a PR from the text that’s settled on?
2 Likes
What about just
diff --git a/peps/pep-0013.rst b/peps/pep-0013.rst
index 1d59dcb6..2f0c3e17 100644
--- a/peps/pep-0013.rst
+++ b/peps/pep-0013.rst
@@ -108,7 +108,7 @@ A council election consists of two phases:
candidate. Voting is performed anonymously. The outcome of the vote
is determined using the `STAR voting system <https://www.starvoting.org/>`__,
modified to use the `Multi-winner Bloc STAR <https://www.starvoting.org/multi_winner>`__)
- approach. If a tie occurs, it may
+ approach. If a tie occurs that is not automatically resolved by the election software, it may
be resolved by mutual agreement among the candidates, or else the
winner will be chosen at random.
4 Likes
That works for me too 
. If nobody objects, how about you create a PR from your local repo?
2 Likes
I’ve opened a draft PR, which should probably have an approval or two before we start the poll 
The PR currently also includes a minor cleanup[1] a line above the real change, which if we agree makes no actual change to the document can be split out and merged ahead of time to clean up the changes in the PR.
Removing an unpaired close parenthesis that was accidentally left during the conversion of a plain text link to a proper reST hyperlink ↩︎
1 Like
And from the referenced page:
In the event a random tiebreaker is needed, BetterVoting will shuffle the tied candidates using the number of voters as a seed.
We’re happy to accept whatever random tiebreaking method you use, but we do want to be able to reproduce your results using @larry’s STAR scoring package.
Toward that end, I’ve pushed for adopting “a standard” cross-platform shuffling algorithm. But we don’t really need that. For purposes of replication, we just need to know which permutation of candidates your software ended up picking.
So, can that be exposed when the election ends? Larry’s package supports specifying the tiebreaking permutation to be used, in which case we should be able to replicate your results exactly (and regardless of how your permutation is arrived at).
It’s not only replication we care about, we also want to score using “proportional representation” (PR) STAR (which Larry’s package also supports).
In the recently concluded PSF Board election, it turned out that the set of final winners would have changed a bit under several versions of PR block Approval voting, although just barely so.
So there’s always a background question of whether the PSF “should switch” to a PR scheme. I don’t think the PSF electorate is anywhere near being polarized enough for that to be justified, but as time goes on that’s a question for real-life results to decide.
I’m surprised nobody responded to this yet!
So I will . FWIW, it looks good to me.
1 Like
But that’s not really needed either. @larry’s package has gotten fancier since I last looked at it, and now supports supplying a custom tiehreaking function. It was easy to write one that pauses scoring in case of a tie needing randomness, waiting for me to tell it which winner the BetterVoting software picked. “Good enough” for this election!