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.