I’m once again nominating myself for the Steering Council (2025 term).
The usual recap:
- I’ve been a core developer since 2000.
- I’ve served on the SC since 2020 (my previous self-nominations: 2020 , 2021 , 2022, 2023, 2024).
- I’m the Release Manager for Python 3.12 and 3.13 (which is less of a big deal now of course!)
- I served previously on the PSF Board of Directors, and as the PSF’s interim manager.
- As of last September, I work at Meta on one of the internal Python teams. Before that I worked at Google on the (internal) Python team, for 17 years.
- I’m a denizen (as
Yhg1s) of the #python IRC channel on Libera . - I also exist on Mastodon as
Yhg1s@social.coop, and on Bluesky as Yhg1s.bsky.social.
My priorities as I listed them in last year’s nomination post were: continuing the Developer-in-Residence program, communication and openness, and improving the Conduct side of things. At the time I didn’t expect we’d get the chance to hire more Developers-in-Residences just yet, but as it happens Bloomberg decided to sponsor a new Developer-in-Residence, as Meta continued its sponsorship as well. During the hiring process for the new DiR, the SC debated quite a bit about what problems or gaps we would want them to potentially address. After reviewing the many excellent candidates for the role, we thought that with the acceptance of PEP 703 (removing the GIL) and the continued work of the Microsoft Faster CPython team, it would be best for the project as a whole to focus on the technical C API support side of things. We also decided we could secure enough funds to hire a third Developer-in-Residence, and so we ended up hiring both Petr and Serhiy, and extending Łukasz’s contract. I think I can say we’re all happy with their work so far! I’m actually quite proud we managed to expand the DiR program to three Developers-in-Residence, which was the original plan back in 2019, and how much impact that’s had already.
On the communication side of things, it took us a little longer to get organised but we ended up hiring Velda Kiara as our Communications Liaison (see her introduction at the bottom of https://discuss.python.org/t/steering-council-updates-for-july-2024), and she’s been helping us get our monthly updates back on track. We still have a way to go to get this routine down better, and lots of other room for improvement, though.
On the Conduct side of things, we obviously had some challenges. It is safe to say community management is by far the most difficult part of the tasks the Steering Council assumes. However, I’m still fully supportive of the PSF Code of Conduct and consider it vitally important for the longevity of Python that we strive for an inclusive, welcoming, accessible community. As things stand, as things are worded in PEP 13, I do not see any individual or group of people better suited to enforce the Code of Conduct in Core Dev spaces, in particular because it cannot easily be divorced from the goal of building the accessible, inclusive, and sustainable community that PEP 13 explicitly mentions as part of the SC’s mandate. As the people in perceived authority, we need to show we can make the difficult decisions, and that our commitment to the Code of Conduct is not just empty words. That said, I recognise as much as anyone that this puts a heavy burden on serving on the Steering Council, and if the Core Team (as defined in PEP 13) decides to separate out community management from the technical leadership in PEP 13, I would be supportive of that. I do not think we can separate out Code of Conduct enforcement (for instance by delegating it to a separate group, or by accepting the CoC WG’s recommendations without critical review) on its own, without it encompassing the larger community building efforts. That would be abrogating our responsibility towards the community.
(And yes, this means that I disagree to some extent with Barry’s goal in his own nomination statement. We don’t often disagree 
and we’ve discussed this at quite some length already. I respect Barry’s opinion, however, and would be happy to see him serve on the SC again!)
I will also note that the decision to run for the SC again was a tough one. Not because of the pushback on CoC enforcement or the amount of work the SC has been over the last year, but because I’ve already served five years. I’m a strong believer in making room for others to step up and grow into new roles. (Jay Miller recently wrote a good piece on why it matters.) I’ve also been busier than usual with my new job, and eager to spend more time on the technical side of CPython, rather than the administrative side. (For what it’s worth, Meta is happy for me to do both.) The Steering Council work is important though, and the lack of overlapping terms in the SC (which I’ve harped on about before), the lack of formal process and documentation within the SC (which we’re still working on) and most notably the lack of candidates less than a day before the deadline made me decide to run for one more term. That’s not to say I will step down if we end up having more than five candidates (that feels a little unfair), but I will not regret losing to anyone 
I also want to say that I’ve greatly appreciated serving on the Steering Council with @emily, @gpshead, @pablogsal and @barry. They are compassionate, considerate, smart people who want the best for Python and have good ideas on how to make that happen. When any of them run again for the SC, this year or in the future, you should absolutely vote for them.