Maybe controversial opinion, but one change I’m wishing to see is allowing non committers to vote for the SC.
The decisions made by SC impact the wider Python users and Python community members, I think more people should be allowed to at least vote or share their voice in addition to the 120+ committers (currently). I’m not suggesting we should let everyone in the world to vote, but I personally would be open to something like giving voting privilege to the Triagers team or other active contributors/3rd party library/package maintainers.
The fact that decisions impact the wider community is par for the course in any open source project. I have not seen any precedent in other open source projects for giving voter rights to people outside the core developer group, do you have any pointers to that?
I wouldn’t mind triagers or frequent contributors, though if they are involved and trusted enough, perhaps they should simply be made core developers?
I would definitely mind people who have not shown activity in the project, as they do not have the same information that core developers do for evaluating each candidate to the SC.
In any case, it seems like this should be a separate discussion thread. Time to split the thread perhaps?
The OpenStack Technical Committee (TC) has a role similar to Python’s SC. Members of the TC are elected by “active contributors” to any official OpenStack sub-project. The simplest way to become a contributor is to have a patch merged, but it is also possible for someone to be listed as a contributor based on other work they do to help the project. The Triagers team fits that description pretty well. Maintainers of 3rd party libraries might be more of a stretch.
This feels like asking for trouble. I would be concerned that a project being chosen gets viewed as an endorsement by us w/o having to vet them regularly for things that we may decide is critical (e.g., has a code of conduct). And that’s not without tackling the definition of “active” (we don’t even have such a definition ourselves as you just self-certify you want to vote).
That might be a bit controversial as it means the PSF has a way to influence elections. As it stands, the PSF and the core team are pretty well separated with the only way to influence each other when someone happens to be a member of both.
One way to think about that is that both core developers and folks on the path to core developership would get a vote. It wouldn’t necessarily change the structure of SC elections, but expands the definition of core team member.
The other aspect of this expanded definition would be the nomination process. SC members do not have to be core developers themselves, but they must be nominated by a “core team member” [1].
IMHO, it’s not that controversial at all. There are many people who aren’t Python core developers who have a very significant interest in the evolution of the language. Exactly who does get voting rights might be mildly controversial, but I think the voting pool could be substantially expanded without exposing the future of the language to substantial risk.
Adding triagers at the very least seems entirely uncontroversial to me - the idea that we’d trust someone to perform non-trivial community management, but not trust them to have an informed opinion on the SC seems inconsistent.
One data point: The Django Steering Council is elected by the full DSF membership. DSF membership isn’t as open as PSF membership - it is by nomination, for “substantial or sustained contributions”, but with a caveat that membership discussions explicitly err on the side of saying “yes”.
To some extent, isn’t that their mandate? The PSF mission is to “promote, protect and advance the Python Programming language”; providing some input to the group of people who will select the council that shepherds the language seems entirely in-scope for that mandate.
I concur with expanding voters to triager members when considering that expanding too much scope can make the SC vote a popularity vote.
Sometimes, steering committee members have to make decisions that go against the wishes of community users for the sustainability of the project.
I believe that consideration should be given to setting a minimum range to prevent steering committee members from being disadvantaged in the next election due to such decisions.
PEP 13 currently says only “active” core team members can vote:
Those who haven’t made any non-trivial contribution in two years may be asked to move themselves to this category, and moved there if they don’t respond. […] While someone is in inactive status, though, they lose their active privileges like voting or nominating for the steering council, and commit access.
And each election begins with generating a voter roll from active core members. Last election, 87 active of some 115 core members were active (see PEP 8105).
Would expanding the voter pool add a similar “active” requirement to be able to vote? How would we define being active for them? Self-declaring could work, but I wouldn’t expect PSF Fellows to commit to CPython, and perhaps not triagers either.
Or would we remove the active requirement entirely?
IMO, the “active” status should only be relevant for the commit bit to help with keeping our repo secure.
The additional overloading for the purpose of voting and nomination is not really necessary. In fact, I find it somewhat contrived, since all past committers, including currently inactive ones, have a stake in Python and should be allowed to influence the future direction of Python.
Additionally, there are lots of ways a core member can be active which does not involve committing to the repo. PEP 13 has a long list of such activities.
I’m not sure I have a strong opinion about this topic, but the question of active status gave me a way to think about it. I have been an inactive core developer for several years, and I’m recently re-engaged a bit. I have always felt a strong connection to Python because of my earlier work, but I don’t think I would have been an informed voter on SC issues. If I had voted in earlier elections, I would have known a lot about candidates I had personally work with years ago. I would have known very little about candidates who joined more recently. It doesn’t seem like I would have been a useful contributor to the vote.
I think the SC serves to organize the active development of Python, and I think it makes a lot of sense for the voters to be actively engaged in core Python development. Triagers have been mentioned, and that makes sense. If you expand the voter pool to include people who aren’t contributing to core development, I worry that they have different goals and levels of information and the SC might be less grounded in the day-to-day development work that they shepherd.
Perhaps there’s a discussion to be had about how the SC and the core development team engage with the wider community. There’s no doubt that a robust engagement with the larger community is important–and surely happens already. Would it be worth writing down some thoughts about how that engagement works today and how it could be improved?
I think you have to differentiate between the voters and the possible SC candidates.
PEP 13 mandates that candidates must be nominated by core team members. This should guarantee that they are indeed “grounded in the day-to-day development work that they shepherd”.
Just to clarify and make sure we’re discussing the same things:
As I understand, the topic we’re discussing here is to expand the voter pool for the SC, not what PEP 13 calls the “core team members”, so it’s well possible to have the “core team member” criteria stay the same, while we add an additional set of stakeholders to the set of voters currently defined by PEP 13, e.g.
triagers
expand the set to all core team members not just the one who commit to the repo
possibly other stakeholders as well
Some additional notes:
PEP 13 does not define quorum criteria, so having more voters won’t get us into trouble if only a subset actually do vote.
Whatever we define as voter should be easily verifiable before a vote by looking at a static public list in a repo. Not only to simplify the voting process from the current very dynamic one, but also to make things more transparent for the Python community. At the moment, this list is only created a few weeks before the vote and it takes a longer while to complete the process.
And on the topic of voting in general, I’d like to suggest:
PEP 13 should be expanded to also allow for voting to happen on other topics, not just SC elections, PEP 13 changes and votes of no confidence. This may make things easier for the SC in situations where a proposal is made, which doesn’t have a clear backing in the community. In such a case, the SC may opt to call for a vote on the topic.
I was thinking primarily of the voters FWIW. I worry that a large number of voters who are not actively involved in core development would be less informed about the candidates. I agree that a voter population that includes people active in a variety of ways (not just committers) makes sense.
With my core dev hat on, that’s their mandate, not ours. Just because the PSF says that’s their goals doesn’t mean it should grant them voting. It’s like if the DSF tacked on, “and also promote, protect and advance the Python Programming language” to its mandate and that somehow means DSF members should also now get to vote just because of what’s in the mandate. I don’t think that’s strictly what you mean, but it can be interpreted that way.
There’s a bit of history here over concern that the PSF would have an outsized influence on core development. Up to now there’s been friendly support both ways, but no direct way for one to influence the other. Bringing in 411 new voters via the Fellows list is a bit of a shift in terms of the voter roll such that core developers lose control over who sets project policy.
I’ll also say that because a large chunk of us were given their fellowships due to being grandfathered in, it isn’t quite as clean as the DSF might have it in their program. For instance, I don’t think ESR should get to vote for the SC.
I think a bigger question is why do people want to vote for the SC? For me, it’s because they direct the CPython project which I actively contribute to. I suspect people who aren’t core devs want a vote because the SC also manage the language’s semantics via the PEP process. But because the same council handles both aspects it leads this tension between core devs not wanting non-team members potentially messing w/ the dev process but others wanting an indirect seat at the table for language influence. I’m sure people will suggest splitting the responsibilities, but that’s a separate, complicated discussion.
Indeed, and PEP 13 currently allows core members to self-declare as active for these important activities. It’s not limited to those committing to a single repo (and I don’t think anyone is suggesting it should).
That’s definitely fair for the DSF (or any other organisation) case. However, the PSF is a bit of a special case here because it was essentially given that mandate by the core team, by virtue of divesting IP rights to that organisation.
I agree that’s a reasonable concern, and the provenance of the complete Fellows list means it may not necessarily be the best source of a voting roll. Picking a new voting pool is a necessary, but separate question to whether should we do this at all.
I think your analysis is correct - there’s 2 roles here. As core team members, we’re picking leaders and spokespeople. In that context, keeping the voting roll does narrow makes sense, as we’re picking who speaks for us all. But in terms of the project, we’re also shaping the future technical direction of the language. I’m interested in having a wider range of voices have a say in the future of the language.
Of the two, I see the latter (technical direction) to be more significant. We could try to split the two roles; but honestly, I’m not sure that’s worth it. In the unlikely case that the broader electorate picks a SC that the core doesn’t feel is representative of core’s opinion on some issue, individual core developers can still avail themselves of whatever platforms they have, or groups of core developers (or even the entire core) could publish an open letter or similar expressing whatever contrary opinion needs to be expressed.
The SC almost never directly initiates or drives technical changes for the language. It always seeks consensus whenever possible and in fact reaches out when that consensus can’t easily be discerned. It also quite often delegates final decision making to experts in a particular domain. I do think there are lots of avenues for the wider Python community of users and developers to be heard, and hopefully when it comes to technical decisions, e.g. should this or that PEP be accepted or rejected, SC is for the most part channeling those voices and their consensus. If that isn’t the case, I for one would really like to know!
Maybe, but the PSF predates me so I don’t know the motivation. My guess is the IP had to be held somewhere that could hire lawyers, so a non-profit made sense. But once again, that’s specific to the IP and not the running of the project.
Ah, see, this is where it gets tricky as, once again, I think people outside the core team think that while I personally don’t. I think the language’s evolution is slowing (especially if you leave out typing), so it’s becoming less of a point of focus. As an example, when I came back from parental leave I felt like I was catching up more on C API stuff than anything language related. Going back through the What’s New from 3.13 I had to get to 3.11 for except * for a non-typing language change that wasn’t some gritty detail like PEP 667 that I expect almost no one but a very select group of people to care about.
But, assuming I’m wrong and the technical direction is significant, that makes your “separate question” way more important to me:
I don’t think it is a separate question at that point. For me at least, who is going to be given voting rights over deciding who controls how the CPython project functions matters. So it’s not a “yes” or a “no” for me as to whether we should period, but “it depends” based on who you are suggesting gains the vote.
Completely understood and agreed; and FWIW, I think the SC has been doing a great job at this.
However, the corollary of what you’re saying here is that it shouldn’t matter who is on the SC, because any SC would always make same consensus-driven decisions. That’s definitely an aspirational goal, and I’m sure that past and current SCs have done/are doing their best to reach that goal; but humans being humans, it won’t always be possible. The circles in which people move alters the voices they hear, which alters the perception of what constitutes consensus.
And even if the SC were a perfect distillation of a universal consensus finding, there’s power in the symbol of leadership. I’d also argue there’s value in having a clear (and wider) community consensus that the consensus-finders are actually trusted to find that consensus
