I nominate myself for re-election to the Python Steering Council for the 2024 term.
I have been serving on the SC for the past two years. With your trust and permission, I’ll be happy to continue in this role for a third.
If elected, this will be my third Python Steering Council term. I have been a committer for over 20 years now (emoji_choice = “😲”). Thank you all for having me! Many of you have met me in person at CPython core dev sprints including autumn-2022 one I hosted at Google. You probably also know me as @gpshead on relevant platforms.
Stability
My guiding principle for the upcoming 2024 / 3.13 term aside from representing your own consensus: Focus on stability to enable the PEP-703 free-threading initial experimental phase to succeed at gaining broad community testing. This means I expect to lean towards being conservative on decisions around API changes in places where it seems likely to cause a burden for those who’ve gotten their code and all of their transitive deps working on 3.12 to get said code working on 3.13. The more we can help our users be able to try out free-threading, the greater useful experience information and chance of success it has.
Rereading the governance PEP-13 that defines the Steering Council to refresh in my mind on what our mandate is, here are some things it mentions that I feel particularly aligned with.
- “focus on quality and stability” – see above.
- “seek consensus among contributors and the core team before acting” - A guiding star. This is how y’all define what I and the rest of the council do.
- “delegate … to other subcommittees or processes” – this year could involve guidance to help smooth out operations of our newly approved Typing Council and C API Working Group.
- Last but not least, “maintain the relationship between the core team and the PSF” – this feels great to me today - in large part due to our regular meetings with Deb, the PSF director – so let’s keep this up.
SC Successes, 2023 edition 
One particular success I’d like to call out from the past year: PSF hiring. Two Python and PyPI software and infrastructure security residents (Seth and Mike) as well as our deputy developer in residence (Petr), with the possibility of another being worked out. A special thank you to our existing developer in residence Łukasz who did more interviews than all of us on the SC combined. Exciting times! This fits in the “relationship with the PSF” bucket. Going forward we want to help retain sustained funding for these roles. Being on a one year fixed contract without knowing if it’ll renew is stressful for our residents. We and the PSF agree on not wanting to overextend ourselves here and desire the ability to offer greater certainty and stability. It is unclear what 2024 will bring us.
The just approved new Typing Council and C-API Working Group have great potential.
Areas for SC improvement 
(todo list)
Public communication. More of it, more often. We have suggestions for the next council to try (see list at bottom) but this is an area I think all of us still need to work on and there’s a lot more to it than just more frequent meeting updates.
No matter who the SC is, it isn’t naturally easy: Here’s me quoting myself recently describing this to Jelle who was asking for insight on our experience to share regarding the new Typing Council:
- “There’s definitely a perceived ‘weight’ to any Steering Council member’s voice regardless of when and whether we want that treatment or not. So I do recommend that anyone try to be clear up front with some “Personal opinion hat:” or “The Hovercraft Full Of Eels speaks!” style of text on discussions if there is any chance that isn’t clear in Python spaces. Corollary: it’ll always be unclear to someone when you are representing only yourself, no matter what you do.” - me
I also feel like we occasionally have issues with PEPs in that contributors can understandably be eager to write a PEP (Caution: being able to make changes is addicting, does Open Source need a warning label?)… and thus submit it to the SC perhaps sooner than it should be. We’re not always ready for it or upon inspection find that the PEP could use more discussion, and by the time we make ourselves time to come to this realization that can mean a delayed reply that doesn’t please anyone (like our PEP-712 response and the feeling of limbo you I suspect some feel we left that in). If we can be more proactively involved in in-progress PEP discussions and more immediately say when it doesn’t “smell” ready to us rather than being seen as an aloof council who jumps in late only after being asked to, I think it’d help everybody. This requires more direct engagement time from all of the SC.
My assumption: Some feature proposal discussions understandably have a tendency towards being dominated by those in favor as they’re the most invested in the outcome, while others may be more “meh” rather than “no!” so they don’t speak up. The SC should probably be doing more outreach and informal polling like we did with the PEP-703 poll as a gauge of how committers feel about changes when we don’t have a clear deciding opinion ourselves.
Voting & Diversity
I’ll paraphrase my own words from my prior nomination: Think strategically about how you vote. If you find yourself wanting to vote yes on everyone, let’s be frank: in our process, voting for everybody is the same as voting for nobody. Consider who you specifically want represented more than everybody you are happy to accept.
Diversity can understandably be a loaded word to a lot of people. Our set of core devs, whether active or in whole, does not count as diverse unless we merely compare it to a dozen-ish years ago (not a great measuring stick). There are no fast solutions to this. I will personally be figuring out what I can do on the mentoring front this year, regardless of election outcome.
Tips from this lowly SC member to our future SCs:
- Prioritize keeping our PSF developers in residence programs healthy and productive. There is a great project and world wide impact to be had there.
- Any Steering Council should have a somewhat regular meeting with the next version Release Manager so that everyone stays in sync. Not dissimilar to what the SC has done with our existing dev-in-res Łukasz. In my SC terms so far the RM has happened to have been on the steering council, making no special consideration required.
- Look into hiring a note taker from among the core devs for our SC meetings to speed up and smooth our public communication. This was a suggestion coming out of our live Q&A at this year’s Brno sprint. We recommend that the next SC arrange this early in 2024.
Employer: Google since 2007 - on our internal Python language infrastructure team for the past dozen. Co-candidate Thomas Wouters is my teammate. Our management supports us spending significant time on upstream CPython, hooray!
Shiny object, imagine it spinning.
