TLDR: PEP 8015 had proposed an SC + Core Developers + Teams model. Python’s current governance model has the first two, while the third is something that we’ve informally organised into. Let’s formalise the organisational structures we already have, change the names of various groups to “teams” and benefit from the clearer formal organisation + naming scheme.
PEP 8015 can be found at PEP 8015 – Organization of the Python community | peps.python.org. It was last discussed in 2018, when the post-BDFL governance models were being discussed.
The Team concept
One of the central ideas of PEP 8015 is having “teams” of people from the Python community who are interested in a specific topic, with the Steering Council being able to delegate their power to the specific teams for PEPs. It served as a unit of helping relevant individuals organise themselves, to collaborate on a specific aspect of the Python language.
We already have teams… with a lot of different names
Since the Steering Council model was adopted, the community has basically organised themselves into the “team” model, via various formal and informal-ish structures. We have an ad-hoc naming model with each “team” coming up with their own bespoke name for themselves.
Many of the example teams in PEP 8015 actually exist now. [1]
-
Packaging Team
This is the PyPA, which has effectively adopted exactly what PEP 8015 proposed – in PEP 609 – and we even have the relevant standing delegations for making decisions on Packaging PEPs.
-
Security Team
We have the Python Security Response Team (PSRT). We should probably keep the same name as today though – it’s the only “team” we have right now!
-
Documentation Team
This is basically the role that the “docs-community” would serve. See this issue for how that’s related to the yet-to-be-PSF-board-approved(?) Documentation Working Group.
-
Performance Team
This is roughly the role that the “Faster CPython” project as well as various core developers involved with that work are serving.
-
Asynchronous Programming Team
-
Type Hints Team
Typing-SIG is serving this role. They’re even moving toward needing similar things to PyPA (including a dedicated website for interoperability standards: Static Typing with Python — typing documentation)
What’s the change proposal here?
I’m proposing that we formalise what we already have as an informal structure for the community, while moving away from “authority” / “special interest group (SIG)” / “community” naming to a single consistent name: Team.
Rationale
I think it would be beneficial to make the naming for all these groups consistent.
It helps a lot for communication about how the Python community works – it’s certainly not the only reason (more below) but I do think it’s the most important one… so allow me to pick my own personal example to illustrate that:
If I were to describe what Python development related spaces I’m involved in today, I would say something like:
I’m a member of Python Packaging Authority (PyPA) and the Python Security Response Team (PSRT). I’m also a part of the Python Documentation community and occasionally contribute to the language design discussions.
With the more consistent naming model, that changes to:
I’m a member of the Packaging team, the Security Response team, and the Documentation team. I occasionally contribute to the language design discussions.
One of these is much easier to say and understand.
The communication clarity is not the only benefit though!
-
It affords additional legitimacy and credibility to the efforts by those who are not CPython Core developers, and yet play an important role in the community.
-
It makes it more attractive to contribute to those groups, which would be a good thing to have happen.
-
It helps bring the various parts of the Python community “closer” to the core developers, which could make it more obvious when there’s an opportunity to collaborate.
-
It makes it easier to see that teams can learn from each other, about how to avoid certain organisational mistakes as they grow/mature, or how to go about fundraising for efforts etc.
-
It creates visibility into how different teams organise themselves, with having a clearer decision making model being a somewhat obvious thing for each team to get around to eventually – affording transparency to the various groups.
-
It makes it obvious that we should be documenting these groups of people to make them more discoverable. (eg: as a list-of-teams page on the devguide)
-
It serves as an onramp into core development since there would also be a clearer path for people who don’t directly contribute to
python/cpythonto start contributing to the community immediately around it, lowering the barrier of entry to eventually becoming Core Developers. -
It enforces a clear separation between PSF’s organisational unit (Working Groups) and the broader community’s organisational unit (Team).
We could do some of these today, with the informal structures that we have today – we’re moving in the direction of doing some of these already. I’d argue, however, that many of these improvements are obvious when you look at the situation from a direction of trying to make these groups somewhat more consistent. At that point, I think we should stretch further, deal with the naming and reap the benefits of that.
Who gets to form a team?
That’s the main question and the main “thing to decide on”! We’d need to come up with a definition for a team because our informal structures don’t have a single definition. So… let’s do that with slightly more specific questions.
What’s the criterion for a team?
I think a “Team”, in the context of Python development, should be a group that:
- has a clear $thing that they work on with informal/formal ownership of it,
- plays a role in maintaining some part of Python itself,
- manages/proposes changes to how a core aspect of Python development works (eg: using the PEP process), and
- involves cross-project collaboration, if it involves projects other than CPython itself
FWIW, I can see some pressures for expanding the definition of a team to be broader but I don’t think it would work well. More importantly though, we don’t have to get this perfect in the first shot. One of the nice[2] things about having a formal model is that we can explicitly make decisions about it and evolve it as we learn. 
Who decides that a specific team can be formed?
We do need someone to make the final call on a yes/no question of “Should we let {group of people} call themselves {xyz} team?”. Realistically, we don’t want to be adding excessive additional processes here. The goal isn’t bueracracy.
I think the obvious answer is that the SC decides on this. I’m aware that it’d add one more line item to their usually long backlog but I don’t think we’d be creating/disbanding teams all that often. Plus, I imagine that if this is something we want to do, it would eventually need to become a governance-update PEP that the SC would decide on – so… having them decide on individual teams makes sense to me.
This also means that the SC serves as a body for oversight, allows bubbling up broader/controversial decisions and pushing for broader efforts. I think this is already implied in our informal structures.
Let’s not touch any existing processes
This proposal intentionally does not touch existing formal/informal processes like who gets to vote for the SC, adding a mailing list, adding something under *.python.org etc. I really do not want to introduce any substantial change to the existing processes – that’s an explicit non-goal.
All I’m proposing here is a formalisation of existing social structure, a better naming scheme and a “new” criterion (based on past precedence) for deciding what the name means.
This is on ideas because… I want to see what people think! Opinions, thoughts and inputs are welcome!
I find it mildly amusing how close @vstinner’s examples are, to the (new) informal groups that we have coalesced into ~3-4 years later. ↩︎
Or horrendous, if we end up in a dysfunctional state – but if we end up with a dysfunctional community, we have bigger problems that this would merely be surfacing. :–) ↩︎