Adopting the concept of "Teams" (from PEP 8015)

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

    Async-SIG - Discussions on :slight_smile:

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


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/cpython to 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. :slight_smile:

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 * 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!

  1. 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. ↩︎

  2. 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. :–) ↩︎


I guess an obvious thing that’s missing from what I wrote above is the “costs” of making this change.

The existing groups will have to agree to renaming themselves. These groups will then also need to decide on what to do about renaming various parts of their existing “operational bits”, rename themselves in the documentation in a way that still keeps the old name discoverable and more. I think the group most drastically affected by this would be the PyPA – but I think that’s also the group that would benefit the most.[1]

The process of organising into a group would get an additional step: asking the SC to ratify the team. This also means that SC will get an additional thing in their agenda/backlog, each time a team has to be created/dissolved.

There might be some pressure for the teams to have a more formal decision making structure, which… I think that’s a good thing but I can see why someone else might consider this a cost – so I’ll just list it here.

  1. I would really like to not argue about the “authority” part of the name, the next time one of the projects under the umbrella makes a backwards incompatible change. :slight_smile: ↩︎

1 Like

How are teams different from the existing SIGs? If it’s just that the SIG concept isn’t well maintained, why would teams be different?
IMO, if there is extra overhead (like a charter etc. in the SIG case, or even an entry in some list), informal groups will spring up, avoid the barriers, and then grow enough to be important despite the structure. Maybe “how do we formally tell if something is a Team?” is a bad question to ask.

Even without formal teams, the SC can delegate relevant people (as in the PyPA case), and I don’t see a problem with e.g. delegating foo PEPs to a “foo council” that would be elected by a “foo team”. Or to experts by any other name. The SC already considers consensus at the appropriate mailing lists & other places where interested people gather.


Two reasons:

  1. A team isn’t defined by being a mailing list.
  2. There will be a single “source of truth” for the list of teams: a list in [whatever markup format] that is maintained in a single place, only updated when the SC says so.

A SIG has a fairly restrictive definition for what can be a SIG. More importantly though, it is possible for the page to be out of date with what’s defined on mailman, as it is currently – with distutils-sig being retired on Mailman but not on the page, and typing-sig is not even listed on the page. I find it amusing that “async-SIG” is not a SIG “technically” – despite for all intents and purposed being one. Stuff like that won’t be possible with what I’m proposing for the teams model.

Most of the things noted as benefits earlier are not transferable to SIGs. Many are derived from having a clearer name, and by being a more formally defined list ratified by the SC.

Honestly, a large part of the problem with SIGs are the two sources of truth and the name itself. It’s an obscure and opaque name, for anyone who hasn’t encountered it before. As I noted, I think naming is very important and a critical part of being able to communicate clearly.

I agree that adding more overhead in processes is not good and, yes, we’ll always have informal groups prop up. The goal isn’t to prevent people from organising into groups but, instead, to facilitate those that already have. If they’re an important group that directly contributes to one aspect of the language development, then it’ll only be natural for them to become a team IMO.

As I noted in the examples above, there are many existing groups that don’t use the SIG naming for some reason or another. It’s, not The PyPA isn’t organised around a single mailing list. On the other hand, Async-SIG doesn’t meet the definition of being a SIG. :slight_smile:

Of course, and I’m not proposing we change that.

I still think that doing a formalisation of the informal structures into a single consistent name will make it a lot more obvious how things are actually working, making both contributing easier as well as making it easier to communicate about the contribution process.


Last week, I asked on the Packaging category how people feel about a renaming.

As I understand it, the general concensus is that people are happy/fine with a renaming as long as it happens as part of an effort to align the naming with other groups (as proposed here). No one has explicitly noted that they’re opposed.

One relevant concern with the word “Team” (in the context of the PyPA, at least) that was raised:

Most of the discussion so far has also involved a bunch of bikeshedding on the word “Team” and some sadness being expressed about the “Cheeseshop” → PyPI renaming. :slight_smile:

1 Like

Just for completeness, I’ll note that there was little interest in the whole idea of adopting the team concept. While that may be because the question was specifically about the PyPA name, I would have expected at least some comment on the overall idea, and there was little of that.

Personally, I’m indifferent to the idea, bordering on against, as it seems to imply quite a lot of organisational churn for little benefit. I may be underestimating the benefits (the value of image/presentation changes is notoriously hard to evaluate in advance) but it’s not something I’ve seen a great need for.

Also, I’d like to see a concrete description of what a group would have to do to be considered a “team”. In particular, the original post here doesn’t state anything specific - for example there’s nothing I can see (apart from a vague assumption that “we should be consistent”) which would stop the PyPA from being the “Packaging team” but still retaining the name PyPA in all the places it’s currently used. I guess it’s considered obvious that we shouldn’t do that - but we’ll have to retain at least redirects for all the URLs using “pypa”, for example, so the term won’t be eliminated totally… I don’t want to see the “branding inquisition”[1] popping up everywhere demanding changes, and I don’t want to see already over-stretched volunteer teams being expected to prioritise “branding” work over bug fixes or feature development.

  1. “Cardinal Biggles - fetch the Style Guide!” ↩︎


The Steering Council discussed the this proposal, and wasn’t convinced it’s a good idea. It would add more process, and not a lot of value.

Speaking for myself (so I don’t misrepresent the other SC members):

Would it help communication if “team” would be an additional term? So you could say:

  • Python’s packaging team is PyPA
  • Python’s security team is PSRT
  • Python’s documentation team is docs-community
  • Pradyun is a member of the Packaging, Security, and Documentation teams.

I don’t think common naming really helps “communication about how the Python community works”. Each of those teams works very differently: “member of the Security Response Team” means you’re a highly trusted professional with access to embargoed security issues, while “member of the Type Hints Team” means (AFAIK) that you’ve signed up to the mailing list.

Many of the benefits you list wouldn’t be benefits of a renaming, but of documenting and/or standardizing how those disparate groups work and organize themselves. The documenting could help (but needs someone to do the work), while I’m skeptical about standardizing (both the PSRT & typing-sig are work pretty well as they are!)

According to the proposal, the SC should be the body that decides that a specific team can be formed. Practically, as a SC member, I have no idea what the decision should be based on, and what the practical effect of being a “team” should be (and by extension, why is the question relevant).
Some very important teams are little more than mailing lists, so should any group of people with a common topic and discussion forum be allowed to be a team? But then, why would a group apply to be a team if that just means there’s an entry in a list? That’s not typically something the members of the team need.

Dissolving a team is another tricky thing to do. When discussion dies out and a group gradually disbands, there’s usually no one interested to formally de-list the group. Just look at the SIGs!

I understand the opinions aren’t what you hoped for :‍(


I may be coming late to this but it sounds good to me.