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
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).
