Given that some SC nominees have indicated they may not run next year to make space for new faces, what happens if it drops to five or even below five next year? There’s nothing in PEP 13 about this scenario. I assume there’s no point in even running an election if all nominees automatically win.
It might be a good idea to prepare for this case and amend PEP 13 before the next elections. Also worth looking if there is anything the community and the SC can do over the next year to seek out more nominees.
You raise good points, which I agree with. Just pushing back on the idea that there’s “no point” if we already know who will win (which applies to many elections of all kinds in real life).
“Special cases aren’t special enough to break the rules.” Keeping the machinery oiled reduces friction of all kinds for the next election that “could matter”.
Keeps voters marked as active on the voter roles.
Gives the candidates opportunities to actively engage with the electorate about high-order issues. Nomination statements are sometimes the only things some of us hear about aspirations and disappointments, and discuss them before a wide audience. Introspection about the Council’s role is something that’s almost never on display outside of the election context. It’s of value to the candidates too to be “forced” into stepping back from crushing daily duties to think about, and articulate, their visions.
STAR voting gives a much clearer picture of individuals’ relative approval/disapproval levels than Approval voting did. The number of stars each gets is valuable feedback for everyone.
That said, I think a practical change with several good aspects would be to move to 2-year terms, with only “about half” up for election each year. If someone doesn’t want to sign up for a full 2 years, PEP 13 already allows for that a member can resign at any time. And leaving details beyond that unspecified for now. If it’s attractive, it belongs in a different topic.
Outreach campaign to the community (to encourage people to run for the SC, or to encourage core team to nominate people for the SC) would be worthwhile effort and doesn’t need PEP 13 changes. But usually such effort needs more coordination than simply hoping that it would just happen.
I’d guess because, since Python is so widely used and important, being on the SC comes with a lot of responsibility, and most people aren’t prepared to take on that work.
I strongly disagree, all six nominees are excellent candidates and I’ll be happy with whichever five is elected. It’s going to be hard to choose how to vote.
Perhaps because most potential candidates take the SC role seriously and think they lack the time necessary to do a good job at it.
I’m not sure I understand that sentence. If you imply that SC candidates should be less “technical” then you’re wrong: the SC makes decisions on difficult technical topics. Doing so adequately requires technically proficient people. These are not management positions.
I think the process is quite opaque. I follow DPO pretty closely, but I wasn’t aware that nominations had opened, for example. In recent years, there were at least announcements to that effect. But realistically, the announcement would need to come well before nominations open, so that people have time to prepare their candidacy.
I have absolutely zero doubts that there are many highly talented and capable people in the wider Python ecosystem that would do an excellent job on the steering council. But we’d need to open the door more explicitly to attract people from outside the inner-most core developer circle.
I’m happy to “threaten” to put my hat into the ring, if only as an absolute lower bound to motivate more people to self-nominate.
The nominations always open mid to late November (except for the very first election). It’s defined in PEP 13 that a new council is elected after each feature release, which in turn is defined in PEP 602 to come out in October. So I don’t think the nomination period came as a surprise to (potential) candidates. Consider this a headsup that the next nominations will open in November 2026
The process shouldn’t really be that opaque. It’s the same every year. At the same time every year. Triggered by the release of the latest major version of Python. Described in PEP 13, documented in yearly PEPs (this year’s is PEP 8107.) There was an announcement of the upcoming timeline, and there was an announcement when nominations opened (although that one seems to be hidden now, probably to avoid confusion.) There’s of course a whole separate category you can set as many alerts or notifications on as you like.
But realistically, the elections are only ever a year away. Given that candidacy from non-core-team members need a nomination from a core team member, not to mention fairly broad support to be electable (even with only 6 candidates ;p), any time is a good time to start preparing your candidacy.
(I do regret not pushing more people to run this year. I was expecting the same last-minute flurry as previous years, and also more hesitant to push people since I’m not on the SC myself right now. That said, I’m perfectly happy with any combination of the current candidates, including the one that doesn’t involve me, so I’m not that regretful. I will be pushing more people again in the future, though.)
Even more than the small number of candidates, I’ve been surprised that every one seems to be a professional software engineer.
Python is probably the most popular language among people who write code as a small part of their job, rather than their main focus: scientists, finance workers etc. I think the language would benefit from having that perspective represented as well. Has there ever been a member of the Steering Council whose primary role wasn’t software development?
No. Alas, it would be tough for someone in that situation to get elected.
But also, 5 people can’t have all the necessary perspectives, and the SC is (or definitely should be) structured with that in mind.
If you know someone like that who’d enjoy steering (you?), I’m convinced that the SC would love to listen to what they have to say. Essentially, they can get the influence without a formal voting right.
A good way to get started would be booking an office hour.
I’m not sure that it’s realistic to expect too many people who aren’t professional software engineers on the steering council - historically it’s mainly been made of up of the core developers (and realistically, those who are paid to work on Python and so who’s employer will give them time to do the steering council with).
I suspect if a maintainer of a library like Numpy/Scipy/matplotlib/similar (i.e. the things that make Python attractive to scientists) wanted to stand, then they probably would be able to get a nomination and maybe votes. However, even those people are professional software engineers - just slightly more science-focused ones.
As an aside - I think at least one of the candidates has a “science background” so it probably won’t be completely unrepresented.
I agree that at a high level, this would be a good change to make. PEP 772’s Packaging Council proposal starts off with 2-year terms.
I’d personally really like to hear from folks who considered running but ultimately decided not to. If we can better understand what keeps people from running, we can try to address those issues.
Same! No matter how it turns out, Python will be in great hands for 2026.
Something that may not be obvious, but in every year I’ve served, the makeup has been incredibly diverse, in terms of experience, opinions, and thought processes. And they have all been kind, respectful, compassionate, and eager to give back to the community and the language. It will be true again this year.
There’s no shortage of folks prominent in the Python community who also have all those qualities, plus the technical depth that I think is undeniably necessary (take a look at the PEPs that were approved for Python 3.14). What would it take for more folks to throw their hats into the ring for next year?
I served on the Steering Council for three terms. I have a depth of experience in Science and Data Science, including as a core team member for Jupyter and napari. I believe the core team and triagers represent the different domains well.
The different domains may take advantage of office hours, serve on workgroups, participate in the PSF, and reach out informally to the core team at events.
While I may primarily consider myself a Scientific Python developer, including CPython, I also have a background in industry, electrical engineering, and scientific research.
I’m confident that all of the candidates up for nomination would be highly capable Steering Council members.
