Steering Council nomination: Thomas Wouters (2023 term)

I’m again nominating myself for the Steering Council (2023 term).

A quick recap:

  • I’ve been a core developer since 2000.
  • I’ve served on the SC since 2020 (my previous nominations: 2020, 2021, 2022).
  • I’m the Release Manager for Python 3.12 and 3.13.
  • I’m currently serving on the PSF Board of Directors as well (2020-2023 term) as the Chair. (I do not intend to run for re-election next year.)
  • I work at Google on the (internal) Python team.
  • I’m a denizen (as Yhg1s ) of the #python IRC channel on Libera .
  • I also exist on Mastodon as (and also on Twitter).

As per last year, I don’t have specific goals in mind for the next Steering Council, or particular things I want to achieve as SC member, but I do have things I consider priorities: funding (and expanding!) the Developer-in-Residence program, Code of Conduct enforcement (thankfully less of an issue the past year), communication and openness. @pablogsal and I gave a keynote at PyCon US 2022 where we got to talk about this a bit. (Petr, Greg and Brett unfortunately couldn’t make it to PyCon US.)

For what it’s worth, I’m proud of the work the Steering Council has done in the last year (and before then), and @brettcannon, @gpshead, @encukou and @pablogsal are all superb SC members and you should vote for them all. I also think we have a great working relationship with the PSF (@Deb in particular.)

One thing I’ve realised over the last two years is how valuable it has been to have @pablogsal, the 3.10/3.11 Release Manager, on the SC. Quite besides the fact that Pablo as a person is great to have on the SC, the frequent communication between the Steering Council and the Release Manager on issues surrounding the release has been incredibly useful. That doesn’t mean the RM has to be on the SC, however: the current SC already discussed having regular meetings with the Release Manager of the next release (me, for the next two years) should they not be on the SC.

I also have a list of things I would consider doing if I weren’t on the SC. We’ve had the Steering Council for four years now, and I feel like we’ve found our stride fairly well. I think it’s time to re-evaluate PEP 13 and some its provisions: the exact mandate of the SC (people frequently think the SC has, or should have, more authority than it has), the scheduling of the SC term (elections after beta 1, rather than the final release, might make more sense), and having multi-year overlapping terms and possibly term limits. I mentioned some of this in the Q&A section of the PyCon US 2022 keynote. (The idea of term limits is also why I’m not planning on running for re-election for the PSF Board: I’ve served 5 of the last 6 years, and it’s time to make room for someone else – especially considering I was the Interim General Manager of the PSF for six months as well.) However, I don’t want to make concrete proposals or advocate for any of these things while on the SC myself, because 1) it might seem self-serving, and 2) I expect to be too busy :slight_smile: .


I would say we word this with caution, I would push for a more collaborative model with the core team so that they dont seem like they have no more power i.e SC is deciding for them in everything (actually I have also mentioned this with PSF and mandates we seem to push on that side to communities every now and then), rather than using words like “more authority”. We need to preserve some autonomy with a collaborative model.

1 Like

That’s exactly why I said “re-evaluate the exact mandate of the SC”. I’m not taking a stance on whether the SC should have more or less authority than what people think, I’m just pointing out that the expectations of the SC are not always in line with the mandate. The SC can work with less or with more authority, as long as it’s clear to everyone (on the SC and among the Core Devs) what the SC can and should do. I would like to see some discussion around what people expect of the SC.


Thanks @thomas I agree with you on this. I would like to see more discussions around this too.