PEP 8107 - Python Steering Council Election - 2026 Term

[ewdurbin]

Initialize the 2026 term. I would appreciate specific review on the new voting system/configuration.

---

📚 Documentation preview 📚: https://pep-previews--4664.org.readthedocs.build/pep-8107/

[hugovk]

Re:

The voting period will be: November 28, 2025 through `December 12, 2025 AoE
<https://www.timeanddate.com/worldclock/fixedtime.html?msg=Python+Steering+Council+voting+closes&iso=20251213T00&p1=3399>`_ [#note-aoe]_.

And:

Time Zone: ``Midway Island, Samoa``

Start Date: ``11/28/2025, 01:00 AM``

End Date: ``12/13/2025, 01:00 AM``

To use AoE, we want to start the window at the first place on Earth to start the 28th Nov, and end the window at the last place on Earth to finish 12th Dec.

• The first place to start the day is Kiribati at UTC+14.

• The last place to end the day is Baker Island at UTC-12, not Midway at UTC-11.

Those Midway times end on time, but start 26 hours late.

Rather than trying to express both of these in terms of UTC-12 or UTC-14, let's use UTC.

• The start of Fri 28th November on Kiribati (UTC+14) -> Thu 27th November, 10:00 UTC (compare)

• The end of Fri 12th December on Baker Island (UTC-12) -> Sat 13th December at 12:00 noon UTC (compare)

---

I wish we could ditch AoE and just use something like 12:00 noon UTC, November 28, 2025 to 12:00 noon UTC December 12, 2025 (or some hour that suitable for the election administrator).

PEP 13 only says "Each phase lasts one to two weeks".

AoE makes it two weeks, two days, two hours, and too complicated.

[ewdurbin]

For what it is worth, the PEP document here is only communicating the end in AoE.

The configuration written is to meet that end time exactly and the start ends up being during Nov 28.

(Those are US/Eastern, Yes. Bettervoting "helpfully" updated them to my localized timezone after saving)

Communicating deadline in AoE seems "fair enough" but is always a cause of confusion and frustration. Under specifying the starts (as we have for all of these election PEPs) seems ideal :)

I wish we could ditch AoE and just use something like 12:00 noon UTC, November 28, 2025 to 12:00 noon UTC December 12, 2025 (or some hour that suitable for the election administrator).

Same. But no one is ever going to be happy no matter what we pick :) I'm in favor of fixing my bad time math for AoE and just leaving this as is.

[warsaw]

Approved, and thanks! with one question regarding whether voters will be required to log into, or otherwise validate their email address on bettervoting.com in order to cast their ballot. If so, the PEP should mention this workflow.

[hugovk]

For what it is worth, the PEP document here is only communicating the end in AoE.

Ah yes, thanks, that's what I missed and assumed the start was also AoE.

Then the numbers in the PEP are fine:

Time Zone: ``Midway Island, Samoa``

Start Date: ``11/28/2025, 01:00 AM``

End Date: ``12/13/2025, 01:00 AM``

That is: start noon UTC on Friday 28th Nov, and end AoE Friday 13th Dec => noon UTC Saturday 14th Dec (15 days, but ok).

I suggest though, put the timezone as UTC and adjust times.

Same. But no one is ever going to be happy no matter what we pick :) I'm in favor of fixing my bad time math for AoE and just leaving this as is.

Indeed :) Another benefit of UTC-to-UTC is it's much easier to verify a 14-day gap for next time. Although once we have it here, it's a copy/paste/edit next year, so not too hard to diff.

Thank you!

[willingc]

Thanks @ewdurbin for putting this together and to all who have reviewed the PEP.

[AA-Turner]

Note for future, please edit the default commit message before merging to curate better Git history.

A

[merwok]

About that (messy commit message):

• the Refined Github extension helps with it
• there is a setting per repo, maybe even per org: https://github.blog/changelog/2022-08-23-new-options-for-controlling-the-default-commit-message-when-merging-a-pull-request/

[ArendPeter]

Sorry for the late feedback

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 https://bettervoting.com/ties

@tim-one had some recommendations in case a random tie breaker was necessary, and I still want to implement that in the future but for this election it's probably easiest to go with the default tiebreaker from bettervoting.

[tim-one]

Tie-breaking should be spelled out in PEP 13 instead (which applies to all SC elections).

https://peps.python.org/pep-0013/

What's there now is unrealistic:

If a tie occurs, it may be resolved by mutual agreement among the candidates, or else the winner will be chosen at random

Luckily, there won't be a tie 😉. I agree we should follow the official STAR tie-breaking protocol instead.

[willingc]

Thanks for the thoughtful post (and all the help) on ties @ArendPeter. I agree with @tim-one, and I believe the process for ties outlined in the Better Voting guide makes good sense.

To adopt this language, the Steering Council voting to amend the tie breaker language is likely all that is needed to change PEP 13.

[zware]

To adopt this language, the Steering Council voting to amend the tie breaker language is likely all that is needed to change PEP 13.

The SC cannot change PEP-13, it takes a vote of the whole core team.

[hugovk]

The vote needs to be open for two weeks, so there's still time to do it before the vote opens on 28th November (just over five weeks from now).

If you want to change it, would you like to open a draft PR with suggested wording? We can then briefly bikeshed the wording, then open a poll in the committers category of d.p.o.

For example, in https://discuss.python.org/t/pep-13-add-deadline-for-seconding-vote-of-no-confidence/72293 I used these poll settings, which can be modified to something like "Yes, make the change"/"No, keep the status quo" and I think min=1 max=1:

[poll type=multiple results=on_close min=1 max=3 public=false chartType=bar groups=committers close=2024-12-09T12:00:00.000Z]
* Status quo
* One week deadline
* Two week deadline
[/poll]

[willingc]

True @zware. What I was thinking is the following: It could be added as a note block in the short term to PEP 13 by the SC to clarify tiebreakers as a first step. As a second step, vote by the whole core team to add to the full text.

[tim-one]

Suggested replacement text to get this started:

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.

[tim-one]

Note that @ArendPeter added an AoE time zone to the STAR voting service:

"""

AoE Timezone

I’ve added Baker Island as an option in the timezone list.
"""