The Python Software Foundation has published the ballot for the body that will
govern Python packaging, and it is a crowded one: 17 nominees are standing for
5 open seats, with candidates announced on Thursday, Aug. 13 after nominations
closed on Aug. 11, according to
Python Insider.
The seat count hides a detail that changes how the ballot should be read. This
election fills all five seats at once, so the terms are staggered by result
rather than by cycle: the two candidates with the highest vote totals become
Cohort A and serve two years, while the next three form Cohort B and serve one,
Python Insider explains.
Each cohort is elected to a full two-year term in alternating years after that,
so roughly half the council turns over every cycle. Ranking a candidate highly
does not only put them on the council; it decides whether they get one year of
runway or two.
What voting members must do before Aug. 25
Membership alone does not produce a ballot. Every PSF voting member —
Supporting, Contributing, or Fellow — has to affirm an intention to vote no
later than Tuesday, Aug. 25 at 2:00 pm UTC, and voting then opens Sept. 1 at
2:00 pm UTC and closes Sept. 15 at the same hour,
per the PSF’s election post.
Every cut-off is quoted in UTC, so members should convert before trusting a
date on their own calendar; the PSF points readers to a
UTC converter for exactly that reason.
Ballots go out by email through OpaVote on the day voting opens, from a noreply
address that is easy to lose in a spam folder. The PSF asks anyone who does not
receive one to check spam first, then write to pc-elections@python.org so the
address on file can be corrected.
Who is on the ballot
The full slate, with candidate statements, sits on the PSF’s
nominees page.
Because the council does not exist yet, every entry is listed as a new member
rather than an incumbent, which leaves those statements as the only comparable
record voters have.
One of them shows what is actually being contested. Axel Obermeier — known on
GitHub and the Discuss forum as h-vetinari, and affiliated with conda-forge,
Quansight, and QuantStack — runs on years of conda-forge maintenance and argues
in his statement that the divide between conda packages and wheels “doesn’t
have to exist,” with native Python packaging capable of reducing the need for
conda packages in the first place, per the
nominees page.
What the first council will have to settle
Whoever wins inherits a dispute older than the council itself: whether Python’s
own packaging tooling should absorb the jobs developers currently reach for
conda to solve, or whether the two ecosystems stay separate and merely
interoperate. Obermeier’s statement puts that question on the ballot directly,
and the cohort split decides how much time the winners get to act on it.
zBrandco reported the
election calendar when it was published,
and nothing in the schedule has slipped since. For maintainers who care which
way that argument goes, the immediate task is procedural rather than political:
affirm before the deadline, or sit the vote out.
