Hello,
I’d like to nominate myself for the Steering Council for a second term.
You can read about me in the previous topic.
Not that much has changed since last year, but I now have a better understanding of the Steering Council’s powers and limitations. So, this nomination post will focus on what I’d do with my SC hat, if y’all trust me with your votes.
Developer in Residence
The SC’s powers are limited. The main “steering” tool the Council itself has is the power to say “no”. Or “not yet”. It’s a powerful tool, but it’s not a pleasant one to use.
Any positive action – solving bugs, process changes, communicating, driving consensus – usually falls to volunteers (including companies that volunteer their employees’ time).
When there’s work no one volunteers for, the SC can ask the Developer in Residence, who then gets to grind on PR/PEP review, setting up buildbots, and other mundane tasks. This is a very good use of the PSF’s resources, and we should do more of those.
Mentoring
Teaching others as a great investment, despite the risks and up-front costs.
We should use the PSF’s resources to make mentoring (in all its forms) easier and more common.
The SC should do less – but its members shouldn’t
The SC should use its powers as little as possible. Ideally, it should do little more than find and bless community consensus.
In practice this doesn’t always happen – for example the SC is doing technical reviews on PEPs. It’s hard to avoid that – we don’t live in an ideal world where each PEP is reviewed appropriately, and negative comments are easier to write as a black-box comittee than as an individual.
Still, I believe that SC members should use their own, personal voice for technical reviews, adding their voice to the community consensus. I have been doing that, I plan to continue if I’m elected, and I’d like to encourage all SC members to do so.
The SC should be more transparent
Currently, communicating with the SC is slow. The SC is all volunteers, it meets once a week, and it doesn’t publish official communication unless all the members agree (or are outvoted, which rarely happens). Asking a clarifying question on behalf of the SC effectively means a week of delay.
A related problem is lack of transparency. I can only imagine the frustration of someone writes a PEP, submits it, waits a month for SC deliberations, and gets back a “no” (and little more, since additional details need to be approfved as official SC communication).
It’s hard to avoid that sometimes – discussions in a small private group have their own advantages – but we should do better.
I recommend that the next SC switches to weekly updates, which include any unresolved points (if possible). The greater community should get some “feel” for how long SC discussions are going.
The 2022 SC members rotated weekly in a “scribe” role, taking internal notes, and volunteered for compiling the monthly updates. IMO, the weekly scribe should write the public summary, and publish it at most a few days after a meeting.
If the SC members can’t handle it themselves, they should consider an external scribe.
Review of my 2022 agenda
For my 2022 SC term, I set some priorities for myself. How did I do?
-
Stability. Not so good. Python 3.11 saw an influx of full-time core devs
who focus on performance rather than stability. I believe that Python 3.12
will be better, now that we know what to expect and that there’s a better
understanding of the backwards compatibility policy.Otherwise, I’ll quote myself from last year:
My opinion, however unpopular, is that we should put stability first.
This adds a constraint to each technical puzzle we solve: if I have my way,
new features and improvements will be harder for us to add, but easier for
users to use.
I’m not saying we can’t have breaking changes, but that we should think long and hard about each one.As one specific point: the backwards compatibility policy sets a minimum length of a deprecation period. I’d like to see a longer default length for cruft that doesn’t need to be removed quickly.
-
Documentation. I’m happy with the progress here: the Docs community has a
Discord chat, monthly social meetings, it organized a Diátaxis workshop, and I feel more people are empowered to make changes where they matter.I can’t claim much credit for actual work, but I’ve been showing the way and opening doors.
Incidentally, I no longer consider this a Steering Council matter. Anyone can do this (though percieved authority does help).
I’ll continue to work in these areas whether or not I’m elected.
2023
I see several areas that could use more “showing the way and opening doors”.
I don’t have solutions, but I’ll look for people who can put in the time – and if I’m elected I’ll consider it part of my duties:
-
Mobile: As BeeWare plans to start contributing support for iOS & Android,
I’ll look at removing any roadblocks. -
Diversity: Core Devs are all too similar to each other, and so are members
of the Steering Council. How can we do better? -
Packaging: PyPA has made amazing progress ending the hegemony of
Setuptools, and moving to an array of interoperable tools.
But, that’s not a good end goal for Python packaging.
What’s the next step? -
Type checking: IMO, type hints should be closer to Python core,
while still remaining strictly optional.
Development
Whether or not I’m elected, I’ll focus on C API – specifically, making the Limited API more complete, more usable for non-C languages, and friendlier to other implementations.
Even if it ends up as stepping stone on the way to HPy or a “
Hypothetical Future Perfect API 
”, fixing its issues brings us forward.