I’m self nominating myself for re-election. Y’all granted me the pleasure of serving my first term on the Python Steering Council during 2022. I’ve been doing the active Python committer thing for 20 years. 
You may know me as @gpshead on various platforms. Or just as the one wearing a colorful shirt. 
What do I want to accomplish?
Refresh one’s memory of our mandate & powers in PEP 13 every cycle. Our role on the steering council is fundamentally to serve you, the committers.
You choose us to be the release cycle decider anytime something in need of a major decision maker comes up. That does not mean council members are know it all experts. Far from it! What it means is that we’re looking to see that the real experts (you 
) provide enough reasoned contextual input for us to be able to make rational decisions. Which can and should include us delegating specific decision powers to others at times so that we’re not the bottleneck.
Priorities
These are mostly guided by you.
When our plate is full, the first thing I encourage us to prioritize are people issues as those impact the health and progress of all of us on the project. Followed by things that we can find quick consensus on an unblock. The longer term larger topics remain on our agenda but we mustn’t go down the rabbit hole with no resolution on them forever.
When something has been on our agenda for ages without a resolution, the default is “the status quo continues”. Which may not be a bad thing, but indicates that we really need to communicate back better about what is missing and why we haven’t decided. Including realizing if we should declare the status quo to be the answer with an explanation as to why.
A slow decision example: PEPs 563 & 649 on runtime access to annotations. That was already on the council plate and being discussed before the 2022 term. A question I’ll always ask myself: was that status quo delay really good for our users? (the answer to that could be “yes”. It is not a rhetorical question)
Security focus
I picked up a focus on improving our Security report response story a bit this past year after learning via the SC that we had been neglecting an issue for years. I expect to continue some focus on that but consider this tangential to my steering council duties.
People
One people need I’d like to see us address in the future, regardless of how (PSF funded or otherwise), is project management on the Python security response team. I believe there is a pending OpenSSF donation in the works that might be used to help make this happen.
One success: I would like to see us work to continue is a paid developer in residence type role(s), funding permitting (which I believe we expect to remain true through 2023). As the steering council during this past cycle we’ve met regularly with our current dev-in-res, @ambv 
, for bidirectional feedback on challenges and priorities. We should continue that. We were able to tap Łukasz to help see final work to land our migration off of BPO and onto Github Issues through.
Internal SC process, efficiency, & expectations
Looking back, finishing up my first term: When I arrived as one of two 2022 newbies, I pretty much just went with the existing processes that were in place. How we meet, how we wrangle notes, how we manage action items and send out community updates (which all of us agree is “um, yeah, too slowly”). It is clear to me that we’re a group of five engineering-first folks doing this. We could use a better process for tracking action items and follow-thru (or… at least I know I certainly could). If re-elected, this will be on our longer term agenda. Advice for those elected: Do this.
One thing we did do well: Communicate with the release manager frequently. This was obviously easy because Pablo (3.10 & 3.11) was elected to the steering council. 
If our new SC does not contain the 3.12 release manager @thomas, I simply advise our new SC to setup a regular release manager check-in, especially as feature freeze beta and releases approach. You’re the SC for 3.12 making decisions, and they as the RM have a responsibility to manage the consequences of decisions.
Stablity
API stability remains core to my decision making. While I want to see performance and threading improvement work land, we must continue first and foremost to not throw users metaphorically under the bus by breaking vast swaths of existing code upon each release (3.12 in this term’s case). There will always be people who have to deal with required changes, but the ideal I want us to strive for is to see existing code tested and updated for the new release long before the release is actually cut. This is more of a public relations and helping hand issue. The Python folks over at Redhat and Fedora did a lot of thankless work for Python 3.11 with their outreach to all sorts of projects offering fixes or at least getting them to fix things before 3.11 shipped. (so… thanks!) I want to foster more of that and encourage PEP authors to have doing as much of this as possible be part of any PEP changing or deprecating existing APIs plan.
Helping reduce new version testability friction
We need to pay attention to the Python ecosystem and understand what the core fundamental widely used transitive deps packages are. Focusing on ensuring they are compatible with the next release (3.12) early in the process as changes land enables others higher up in the dependency stack to test and prepare their own code. If people can’t test their applications on 3.12 because their deps are not ready, that is not good for confidence in the release.
Diversity
I encourage people to think strategically about how they vote. If you find yourself wanting to vote yes on most of the candidates because we attract a talented set of nominees, lets be frank: in our process, voting for everybody is the same as voting for nobody. Consider who you specifically want to win more so than everybody you are happy to accept.
How can we address this? We may need to change our election process or council terms for it to be any other way. I like what Emily said 
about our somewhat awkward SC lifecycle in her own nomination. That isn’t something the steering council itself can make happen. Per our PEP-13 change requirements we’ll need a concrete proposal for what the change would be and a 2/3 in favor committers vote. I suggest spawning a separate Discuss topic on this if you’ve got a proposal and rationale.
Employer
I have been working for Google for the past 15 years. The past 11 of which have been on our internal Python language team as a Tech Lead helping wrangle our runtime and ecosystem (ie: not GCP). Thomas Wouters - also running for re-election - is a teammate.
Disco Ball
Thanks for reading this far! -Greg
You can also see my past 2022 term nomination.