Steering Council Nomination: Thomas Wouters (2026 term)

Core Development Steering Council Nominations
1

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

The usual recap:

Last year I mentioned I wasn’t sure if I should run, given that I’d already served five years (making room for others is good!) and also that my new job at Meta let me spend more time on the technical side, which I was (and still am) eager to do. I am wholeheartedly running this year. It’s not because I think any of the current SC members have done a bad job – how could I, they accepted both big PEPs I was part of :grin: but I also have the greatest of respect for @gpshead, @pablogsal, @corona10, @barry and @emily. It’s because I know I have the ability to contribute, I know I have the time and support to do a good job of it, and we have STAR voting this election, which I hope will let the electorate choose a good balance between old hands and new friends.

In my previous self-nominations I recapped the SC work I’d been a part of, and I’ll just refer you to those, linked above, if you haven’t read them before or would like a refresher. Instead I’ll just say I strongly believe in more communication (between everyone, not just the SC), planning for long-term sustainability, and being the change you want to see. Python is an established project, the base and basis for a lot of other projects, and we need to ensure that base remains stable in the short and long term. That’s why I’m in favour of multi-year, overlapping SC terms, and why I harp on about avoiding breaking changes, and why I care about having an open, welcoming, inclusive community.

I want a community I want to be part of, and that I can be proud of, and that keeps working to improve itself and grow, to keep that important base stable for decades to come. That means being forward-looking and introspective, both technically and socially. It means I support ideas like free-threading, evolving a new C API and using Rust in CPython, and also Code of Conduct enforcement on multiple levels, outreach and mentorship efforts. It means trying many things and constantly evaluating what does or doesn’t work, and why.

One very concrete thing I think we should improve is the visibility of changes to Python. Not just to the outside world, which keeps being a problem, but also between ourselves. It’s clear that PEPs, despite their original intent, have turned into very heavy-weight efforts. Writing a PEP is easy, but the discussion around them can be extremely time- and energy-consuming, not to mention a pretty negative experience even for PEPs that are viewed extremely positively. Partly as a result of that, a lot of more minor decisions on the design and implementation of Python and the standard library are made without PEPs, often even without discussing them on discuss.python.org at all, making them less visible and involving fewer people in the decision. We also have a decision process that involves the SC “finding consensus” without a clear idea what that means, even when the SC puts out a poll to gauge the consensus.

I would very much like to figure out a way to make discussing changes easier, keeping more people involved, and get a clearer idea of consensus without opening each discussion to a deluge of comments, suggestions and questions. Maybe this means more formalization: work groups, delegation and distinct areas of responsibility. Or maybe we really need a forum with an explicit intent to keep discussions focused, on point and short, possibly with explicit up/down-votes, and probably with strong moderation to set the right expectations for all participants (e.g. no asking questions that are already answered, and continued discussion should be taken elsewhere, or at least separated out.) This is as much a social problem as a technical one, and we should keep both in mind.

Just to be clear, while we’ve traditionally done these kinds of process developments organically, I think given the scale of the community and the processes we have, the SC is the right group to try and drive the efforts to find a good solution to those problems. The SC has the authority, the insight (hopefully! So far, anyway :slight_smile: ) and definitely the responsibility to set us all up for success.

29 Likes
2

Edited to add I also have the greatest respect for Barry :sweat_smile: (That’s what I get for not copy-pasting the list of SC members :joy:)

Thanks, @hugovk, for pointing that out :slight_smile:

3 Likes
3

Can you give examples that are significant to you of being introspective, both technically and socially?

1 Like
4

Sure! Since you brought it up on another thread, how about when we tried and failed to make zulip work for us, and decided to try discord instead (which is still going). Or the discussion, decision and implementation to switch to STAR voting, and the occasional discussion to switch to multi-year overlapping SC terms, which I mentioned in my post. On the technical side, I think the discussion on how to handle compatibility in the new stack protections in 3.14 is an example that takes a good look at both the problem and how it got there.

I think there are plenty of examples where we all ask each other and ourselves questions that challenge our preconceptions, our assumptions and our past decisions, and I think that’s both healthy and good.

3 Likes
5

How does this topic reflect on you? I’ve followed these in detail (I ran the poll to update PEP 13) and I don’t recall you participating at all – maybe I’m missing some context?

1 Like
6

I’m not sure I understand your question. They don’t reflect on me, and they weren’t meant to. The quote Antoine asked about was about the community, and that’s how I answered the question. These are examples of the community being forward-looking and introspective.

3 Likes