Should we expand the voter pool for the SC?

While expanding the voter pool sounds nice, I’m curious if people have theories for outcomes that might have been different… In particular, if any Steering Councils have received feedback to suggest that they haven’t been able to represent parts of the Python community well?

I do think a well informed, highly engaged and clearly defined voter pool is important. So while ± a few people seems unobjectionable (though like pitrou says, maybe we should be nominating them as core devs), I’m hesitant about a significant change.

I’ll take a contrary position here. The process for basically any specific decision is already open for people to participate in. And this is wonderful! On any given decision, I feel people are more able to directly and productively influence it by participating in discussion / user feedback / development, than by having indirectly voted for a set of people a year ago. Past Steering Councils have engaged in direct democracy at various points in time (e.g. polls for PEP 649). And as far as symbolism goes, we famously no longer have a BDFL :wink:

7 Likes

While the language spec (outside typing) has been stable for the last couple of years, between the JIT, subinterpreters, and free threading there have been substantial reference implementation changes. The release cadence PEPs also come to mind as a significant development with implications well beyond the core dev community. Assuming improved DSL support lands in some form for 3.14, that’s also likely to have major ripple effects.

That said (and despite my earlier comment about the PSF Fellow list), I’m personally more in line with Brett’s position: I see the SC’s primary role as being able to authoritatively represent the core dev team as a whole. Everything else (e.g working with the PSF and PSF sponsors; the standing delegations to groups like the PyPA, typing council, docs editorial board, etc) flows from that.

From that view, expanding the voting pool to triagers makes sense, since the SC ultimately manage their work flows along with other core development processes (it’s also going to be a better fit in terms of target levels of responsibility for some folks in core-dev-adjacent groups like the PyPA that would like to be able to vote for the SC).

Between the PSF Board, PSF staff, the SC members, the core dev team, and folks actively participating in the various delegated areas and the open discussion forums, that already brings quite a few different perspectives to bear on significant language and ecosystem design decisions.

I can potentially see a governance role for a “Python user representatives” group that helps both the PSF and the core dev team assess the possible impact of various decisions on different segments of the wider Python community, but I’m not sure such an arrangement would offer enough concrete benefits over the status quo to justify the overhead of formally setting up and maintaining the group (especially until after we see the outcome of the PSFs recent investments in helping the SC to improve its ongoing transparency).

12 Likes

Some SCs have. Though on occasion in the form of a misunderstanding of what the steering council powers actually are and differing interpretations of what “the Python community” is (good luck agreeing on a definition of that). I don’t know if changing who votes can resolve such tension, but enfranchising people who I expect we’d all agree are heavily involved, such as triagers, feels like a good idea to me.

4 Likes

I think the biggest downside to giving voting rights to triagers is that it further ties in access with political goals, which will give core devs the incentive to make people triagers to further their agendas (subconsciously or not). If this happens (or people feel it is happening), people will start demanding more process around joining the triage team, which would further discourage growth of the core dev team (many of us think it’s already too hard to become a core dev).

This is a Goodhart’s law type situation: right now the barrier to entry for being a triager is pretty low and it tends to be a selected group of high quality individuals partially because the main thing you get for being a triager is that you can do maintenance tasks on the CPython repo (which you would only care about if you actually want to maintain CPython). We probably would all be willing to extend voting rights to the people who are triagers now, because the people who are triagers now joined before being a triager gave you voting rights.

I’d say the biggest upside to giving triagers voting rights is symbolic (I don’t know that triagers are going to systematically vote differently than core devs unless the rolls are expanded in response to this change). It is definitely a good thing to send the signal to triagers that their work is valued, but practically speaking I am not sure that triagers are really a long-term disenfranchised group within Python dev, are they? What is the average time that someone spends as a triager before becoming a core dev? If there are people who became triagers and want to become core devs but haven’t been promoted for a long time (multiple election cycles), is that an indictment of our promotion practices (which I’d rather remedy by fixing those processes rather than carving out a niche for “long-term triagers” or something)?

27 Likes

@pganssle’s post made me realise I should make my earlier PyPA comment clearer: the main case where I’ve seen the topic of the SC voter pool come up is in PyPA governance discussions, where it doesn’t sit well with some contributors that the standing delegations for the packaging PEP process come from a group that only the PyPA contributors who are also CPython core devs can vote for.

So if we were going to do something about that, it would probably be better to address it directly.

7 Likes