I’m nominating myself for the Steering Council (2021 term).
For those who don’t know me (@nedbat likes to call me “the most famous pythonista no one has ever heard of”, although I hope that isn’t true among core developers):
- I’ve been a core developer since 2000.
- I am currently serving on the 2020 SC – my 2020 self-nomination: Steering Council nomination: Thomas Wouters (2020 term).
- I’m currently serving on the PSF Board of Directors as well (2020-2023 term, also 2001-2004 and 2017-2019).
- I work at Google on the (internal) Python team.
- I frequent (as
Yhg1s) the #python IRC channel on Freenode. - I’m also on Twitter as
Yhg1s.
I wrote a blog post a couple days ago, describing the work of the Steering Council, and what I feel we achieved: https://pyrandom.blogspot.com/2020/11/my-view-of-python-steering-council.html
I also sent an email to python-dev to elaborate on my views on the Structural Pattern Matching proposal (PEP 634/635/636), on which the SC will defer its decision until the 2021 SC is seated and which I imagine might be a voting issue for some. The bottom line is that I’m thinking very hard about what the proposal will do to future Python development, not just the next Python version. I believe it’s pretty indicative of how I approach most Python design questions.
As mentioned in the blog post linked above my priorities for the next SC are:
- PEP management. Specifically, handing PEPs which require domain knowledge or which have select interested parties to appropriate PEP delegates, keeping the difficult ones for ourselves, and keeping an eye on PEP and development progress. That includes the difficult choice that will have to be made regarding the Structural Pattern Matching proposal.
- Spending money on improving the life of core developers, and the robustness of the project. Right now our main focus is on long-term maintenance and reducing the burden of that on our volunteers. Also, spending money means facilitating donations, from individuals and companies. I’m not willing to engage in pay-to-play or to let large donations dictate changes to Python, but we do want to make sure we listen to, for example, the needs of companies even when they don’t have core developers as employees.
- Code of Conduct enforcement and any work we need to do to make core development as open and welcoming as we can make it. This is difficult work and we’ve learned a lot in the past year about things we have to look out for, but it’s the kind of work that never ends. We always have to be ready to listen and improve. That said, I believe the SC made the right choices regarding CoC enforcement this year, painful as they might have been, and I fully stand behind them.
- The GitHub Issues migration, which I expect to have a significant impact in how we work, impact we very much want to be positive. As mentioned in the blog post we’ve hired a project manager (Ezio) to run this for us, but that does not absolve the SC from involvement or responsibility.
- Communication, which is the primary improvement I want to see in the next SC over what the current SC has done: communicating with the rest of the core developers and with the broader Python community. It’s been difficult, especially considering the situation the world is currently facing where in-person meetings are much rarer. I don’t have a firm idea yet of how we should approach this, but I hope we can leverage some of the work being done around virtual conferences and the virtual core dev sprints to create a more open, collaborative virtual environment for Python core development.