For those unfamiliar with it, the voting privilege for the Python Steering Council elections is restricted to active Python core team member. As if today, there are 90 active Python core team members in the world who can cast a vote in the Python Steering Council election.
I’m curious if this we should expand this group of voters to a wider range of people, and who else should have the right to vote in the Python Steering Council elections.
My thread here is specifically to get input from non-committers, and I’m wondering about two things (so please focus your responses on these two things):
Would you like the privilege to vote in Python Steering council elections?
If yes, why? How does the election/the decisions of the SC impact you?
Please also state your affiliation/involvement in Core Python development. I.e: are you speaking as a user, as a maintainer of a third party, etc? You might end up stating this to answer question 2, but I wanted to be explicit about it.
Thank you.
EDIT: If you prefer to share these feedback privately, please write to mariatta @ python dot org
Yes, I would greatly appreciate the opportunity to vote in steering council elections, and have followed the nominations and voting results for the steering council every year since it was formed, including the initial PEP 8xxx governance proposals.
I feel that I have a personal stake and interest in the direction of the language as someone who: has written a PEP and follows many proposed PEPs; has contributed small fixes and improvements to Python on multiple occasions; supports thousands of users of Python as part of my daily job; is a team mate of multiple Python core devs; maintains a number of PyPI projects impacted by future Python language changes; helps organize local Python meetups and conferences; is a supporting member of the PSF and has voted in every election I’ve been eligible for.
For context/affiliation, I have:
been on the Python Language Foundation team at Meta for six years now, mostly supporting developer tools, third-party packages, and formatting/linting systems
contributed at least three commits to cpython itself, one of which was co-authored by a team mate
attended the Language Summit in 2023
regularly attended the Typing Summits going back to 2019
written one PEP, including the draft implementation, that was ultimately rejected
created and maintained dozens of projects on PyPI, including one in the top 300 packages list
joined the program committee for both North Bay Python and PyBay, and the organizer group for Pyninsula
I have considered taking steps towards becoming a core developer at times, mostly in the interest of having a larger voice in core team discussions as well as voting for SC, but I haven’t done so for various reasons, such as a lack of time to focus on CPython due to all of the other OSS efforts/projects I’ve been involved in, or not having a particular goal or idea of what to even work on that would qualify for being an “active” core team member.
As a person working with alongside the community on the organizing side and less on technical aspects of the language, personally I am more interested in getting more people to understand and have opportunities to get involved with core developers and ultimately understand what the SC does. From there we might get more people to be interested in contributing and move on as core developers themselves. If anything, this would be the most favourable outcome from my point of view if we open up the voter eligibility for the SC.
As of right now, we are still needed to do more work to get more of our community to understand what the PSF does and why it is important. So I think for the current discussion, spending more effort on narrowing down who will be eligible, like finding more people like Amethyst above and allowing them to vote feels like the best thing to do.
thanks for raising this topic. Here a few points about myself:
As part of my daily job, being an “active” contributor since last year
I’ve been using actively since 2006
I run an internal Python community of 1200 people where I work
Attending yearly conferences since 2010
said that, I’m not a triager nor a core dev (yet) and I would love to have voting rights for the SC. The reason is very simple: I care. I care about Python, its technical direction and its community.
Apart technical contribution, voting the SC represents another way for steering (no pun intended) its direction.
I feel there are a lot of other people who, like me, would love to participate in this important decision.
Replying due to a call for triagers input and not as a staff person, but I feel I do not have enough experience with core developers to know which ones should be sitting on council seats.
I doubt this would change much even after some months/years in this same position. It feels to me (I could be 100% wrong, and am happy to be) that core devs are uniquely suited to promote fellow core devs to a council seat because of their (much) closer working relationships.
With that being said, I think given last years candidates today I know who I would vote for and it would be purely off of who I have seen as most active / loudest (in a good way ) in the community and in spaces I frequent.
I may look back on this in one years time and say “boy I was dumb I should’ve advocated in favor of voting rights”
Thanks for extending the call for feedback, Mariatta.
As a triager (and someone aspiring to become a core developer), I’d love the opportunity to vote in the steering council elections. While I’m not yet a core developer, I believe that my work as a triager, combined with my contributions and passion for Python and its community, provides me with a clear understanding of ongoing projects, efforts, and challenges, and enables me to make an informed choice when voting.
More generally, I think that allowing triagers to participate in the SC elections could also foster a deeper sense of responsibility and ownership in Python’s future. I think it’d also be a great step toward further recognizing the important role of non-core developers in supporting Python’s development and community while ensuring a more diverse voter base that reflects the wide range of contributions made across the project.
After reading the Committees thread and some response in this thread, what I feel is that while I don’t have interest in voting for the SC, I would really like to tell people around me that “if you’re interested, and these are the ways you can participate, you can influence how the language evolve by voting for the group of people that will make these decisions”.
There are many ways to participate in improving the language and how it is being used (other than the community part). We have the triagers, the core committees, the documentation people. With the language as large as it is right now, it makes sense to acknowledge the input from people working on the whole pipeline that brings different skill sets and knowledge.
So TL;DR: I agree opening up the voter roll is good and perhaps about time. I don’t agree it should be open to everyone who thinks they should get a say. I don’t agree it should be open to Fellows either. But having a say should be for the people working on the language building pipeline (for lack of a better description: I guess we need to define this better).
Maybe a “by invitation from a person already voting” like the current process (or like the Django Software Foundation) except that the invitee has to be working on the pipeline somewhere, instead of already committing actively?
Triager here! Agreeing with everything that has been said so far, especially with what @savannahostrowski mentioned about fostering growth.
A more technical point that hasn’t been mentioned yet: the SC directly chooses what PEPs get accepted, and therefore what issues triagers end up dealing with, as well as what features library maintainers get to have – so by getting a vote, you indirectly get a say in what you work on.
I alluded to this in my post above, but this is an excellent way of saying it. Pretty much every PEP decision has a direct impact on the entire community, from users and conference speakers to maintainers and triagers, all the way up to the core team.
According to these lists, the triage team is much smaller than the core team, which isn’t surprising given its current definition. However, I was added to the triage team a few months ago, not because I was interested in doing triage, but so I could have access to some GitHub features for working in a particular area (Android).
Now maybe this was a mistake and I ought to be ejected . But if not, maybe we should consider widening the definition of the triage team so that it’s open to any active contributor who a core developer thinks has a good enough track record, whether involved in triaging or not. And perhaps renaming it to “outer team” or “assistant team” or something like that.
A team defined in such a way should be closely enough involved in the project to be trusted with a vote for the SC. And it would certainly be better than vague criteria like “has enough of a stake in the ecosystem”, which I’m sure neither the SC nor the core developers want to be tasked with evaluating against a large number of candidates.
I’d like it, although I’m not sure I ought to have it.
I’m just a user of Python; I have no involvement in core dev. My main direct involvement with Python nowadays is teaching people to use it and helping people with questions about it. In the past I used it in a job context as well as for research, and I still do to some extent, although less than before.
But the SC ultimately determines what Python becomes, so its decisions impact every user of Python. What I meant above by “I’m not sure I ought to have it” is that it’s obviously infeasible for every Python user to be able to vote for the SC, for many reasons. Still, I do think it is a good idea to explore expanding the franchise somewhat (so I appreciate your seeking input on it).
Right now the SC is elected solely by people who develop Python. That certainly has its pluses, but core devs are a tiny fraction of the set of people who might be called “stakeholders” in some sense. In my experience, those core devs, to an unusually high degree, make an effort to consider a wide range of perspectives, which means that Python suffers from “developer syndrome”[1] much less than many other projects. So I don’t think there is any immediate problem in that regard. Still, I think it would be beneficial to have some role for other groups in electing the SC and thus guiding the evolution of Python, simply to somehow incorporate the perspective of the many-orders-of-magnitude-larger-than-core-devs set of people in the world who are affected by development decisions but have no involvement in the development themselves.
By “developer syndrome” I mean the tendency of many software projects to evolve in a way that matches the preferences of their developers more than those of their users. ↩︎
The “by invitation” sounds good and aspirational, but from my experience and what I’ve seen, the existing voters haven’t been too proactive in inviting non core team into core-related activities
There is already existing practise of “Being invited by existing core team”, it’s not new. But in reality, not all core team members have been proactively inviting people, and when we do, it is limited to inviting individual that core team members already personally know.
While this has merit, at the same time, if the core team hasn’t been actively interacting with the wider community members, we might not even know of who else we can invite.
Examples:
Pre 2019, Python Language summit attendance are for committers, and by invitation of other committers only. In 2015, all Python Language Summit attendees were 50 men. Starting in 2019, we changed it an open application process. Since then we have more core-team members participating and presenting in the Python Language summit.
Till now, Python Steering Council nominations are open to core devs, and those invited/nominated by other core devs. So far, core devs have only nominated 4 other people. None of the non-core dev nominated have ever been elected as Steering Council. The last time a non-core dev was nominated for SC was for the 2022 SC term. Additionally, the non-core dev nominated for SC so far have all been men.
Till now, new Python core team member are “by invitation” of other core devs. The last time core devs invited a woman as a new core team member was 23 men ago. The first time core devs invited a woman core dev was 2017.
In the above examples, we’re missing out on perspectives, voices, and contributions from women. So this is what I’m trying to identify now: who else are we missing out from, who else haven’t been invited to the core team, because we don’t know about them yet. And how can we provide that pathways so that they can participate and be included, without waiting to be invited by existing core team members.
Therefore, while “being invited” sounds good, this is already a thing, and I would like to have additional pathways for people to have voice and contributions in the core Python without waiting to be invited by existing core team.
The SC is elected by active Python core team member: meaning core developers who made commit to Python in the last 2 years.
The number of people contributing and developing Python are much larger group. For example, in Python 3.13 alone there were ~400 new contributors to Python.
I think that’s consistent with what I said? When I say “the SC is elected solely by people who develop Python”, I mean “everyone who can vote for the SC is someone who develops Python”. You seem to be saying that the converse is not true (i.e., that not everyone who develops Python can vote for the SC), but I wasn’t making any statement about that.
In the above examples, we’re missing out on perspectives, voices, and contributions from women. So this is what I’m trying to identify now: who else are we missing out from, who else haven’t been invited to the core team, because we don’t know about them yet. And how can we provide that pathways so that they can participate and be included, without waiting to be invited by existing core team members.
I understand better now where you’re heading. Perhaps this is a good opportunity to rope in the D&I WG. They might have an idea on what kind of groups can be good candidates for the voter roll, or at least a way to reach out to groups that are underrepresented.
The last time core devs invited a woman as a new core team member was 23 men ago.
Can you explain how such “inviting” can look like, and to which core-related activities? New core developers are proposed on a regular basis, so it’s not like regular contributors are ignored.
I’m sure many of us routinely interact with community members. Especially those of us that are active in daily development tasks on GitHub, etc; but also as Python developers in general, including on non-CPython projects.
Is that a problem? The fact that core developers are wary of electing a non-core dev to steer their work as core developer is quite understandable.
So, to be clear, nobody has to be “invited” to contribute to core Python. The contribution process is open to anyone. It’s unclear why opening the SC voter pool would change anything to contribution dynamics.
