PEP 8011: Leadership by Trio of Pythonistas (ToP, or simply Trio)



Full text:

Note, before commenting or asking questions, please read the PEP in its entirety.
Constructive feedback of this PEP is welcomed.

PEP: 8011
Title: Python Governance Model Lead by a Trio of Pythonistas
Author: Mariatta Wijaya, Barry Warsaw
Status: Active
Type: Informational
Content-Type: text/x-rst
Created: 2018-08-24


This PEP proposes a governance model for Core Python development community, lead by a trio of equally authoritative leaders. The Trio of Pythonistas (ToP, or simply Trio) is tasked with making final decisions for the language. It differs from PEP 8010by specifically not proposing a central singular leader, but instead a group of three people as the leaders.

This PEP also proposes a formation of specialized workgroups to assist the leadership trio in making decisions.

This PEP does not name the members of the Trio. Should this model be adopted, it will be codified in PEP 13 along with the names of all officeholders described in this PEP.

This PEP describes:

  • The role and responsibilities of the Trio
  • Guidelines of how to trio members should be formed
  • Reasoning of the group of three, instead of a singular leader
  • Role and responsibilities of Python core developers to the trio
  • Sustainability considerations
  • Diversity and inclusivity considerations

Open discussion points

Various tweaks to the parameters of this PEP are allowed during the governance discussion process, such as the exact responsibilities of the Trio, term lengths of service, voting procedures, and trio disbandment. These will be codified by the time the PEP is ready to be voted on.

It is allowed, and perhaps even expected, that as experience is gained with this model, these parameters may be tweaked in order to provide for a smoother governing process. The process for tweaking these parameters will generally be the same voting process as described in PEP 8001.

Roles and responsibilities of the leadership Trio

  • Be open, considerate, respectful. In other words, adhering to The PSF’s code of conduct.

  • Pronounce on PEPs, either as a team, or individually if the other trio members agree.

  • Provide vision and leadership for Python, the programming language and the community.

  • Understand their own limitation, and seek advice whenever necessary.

  • Provide mentorship to the next generation of leaders.

  • Be a Python core developer

  • Be a voting member of The PSF (one of Contributing / Manager / Fellow / Supporter).

  • Understand that Python is not just a language but also a community. They need to be aware of issues in Python not just the technical aspects, but also other issues in the community.

  • Facilitate the formation of specialized working groups within Core Python. See “formation of specialized working groups” section below.

  • Set good example of behavior, culture, and tone to Python community. Just as Python looks at and learn from other communities for inspiration, other communities will look at Python and learn from us.

What are NOT considered as the role responsibilities of the trio

The following are not the expected out of the trio, however they can do these if they wish.

  • They are not always the ones coming up with all the ideas, vision, problems to solve, and what not. The trio will be open and accepting suggestions from core developers and community.

  • Day to day bug reports do not require the trio to intervene. Any core devs are able to make decisions, but will defer to the respective focused workgroups, and will eventually defer to the trio when there are major disagreements among core developers.

  • Does not run / decide on Python language summit and its logistics.

  • Does not run / decide on Python core sprint and its logistics.

  • Does not handle CoC cases, those are responsibilities of the CoC workgroup, but will speak out if they witness those cases.

  • Does not make decisions about other Python implementation (Cython, IronPython, etc).

  • Does not run / decide on Python conferences and its logistics.

  • Not an evangelist of Python. The trio is not expected to preach/advertise for Python. They can if they want to, but not expected.

  • Not an educator of Python. The trio is not expected to be the ones teaching/writing about Python. They can if they want to, but not expected.

  • The trio is not expected to be available 24/7, 365 days a year. They are free to decide for themselves their availability for Python.

  • Not a PEP editor.

Guidelines for the formation of the trio

The success of this governance model relies on the members of the trio, and the ability of each trio members to collaborate and work well together.

The three people needs to have similar vision to Python, and each can have different skills that complements one another.

With such team, disagreements and conflict should be rare, but can still happen. We will need to trust the people we select that they are able to resolve this among themselves.

When it comes to select the members of the trio, instead of nominating various individuals and choose the top three, core developers will nominate and vote for groups of threes who they believe can form this united trio.

This PEP will not name or nominate anyone into the trio.

Only once this PEP is accepted, any active core developers (who are eligible to vote) can submit nomination of groups of three.

Once this PEP is accepted and core devs have submitted their nominations, each active eligible core devs can vote for one group of three.

Qualities desired out of the trio:

  • Be a Python core developer.

  • Be a voting PSF member (one of Contributing / Manager / Fellow / Supporter).

  • Be a member of the community with good standing.

  • Adhere to The PSF’s code of conduct (Be open, considerate, and respectful).

  • Be willing to accept the said roles and responsibilities.

  • Able to communicate and articulate their thoughts effectively.

The following are not requirements when considering someone into the trio:

  • “Experience being a BDFL of something” is not a requirement.

  • “Be a genius” is not a requirement.

Diversity and inclusivity

The core Python development team fully supports the Python Software Foundation’s diversity statement, and welcomes participation and contribution from people from diverse backgrounds. When nominating people to to be part of the trio, Python core developers will take every effort into including members from underrepresented group into consideration.

Ideally, nomination should include and reflect the diversity of core Python contributors.


Lack of employer support or lack of luxury of free time should not be a factor when identifying who should be in a trio. If there are individuals who the core devs have identified as having the necessary skills for being a member of the trio, but they are unable to do it because of lack of time, lack of financial support, then we should open discussion with The PSF or other parties into providing the needed support.

Additional guidelines

When nominating someone other than yourself, please first ask privately if they are ok with being nominated, and if they are ok with nominated in that group of three. This is so people don’t feel pressured to accept nomination just because it happens publicly.

Why not other governance model

Core Python community are familiar with the singular BDFL model for over two decades, it was a model that has “worked” for Python. Shifting to a completely different model all of the sudden, could be disruptive to the stability of the community. However, the community can continue to evolve in the future.

If this PEP is chosen, it is not meant to be the only governance model for Python going forward.

This PEP proposed a transition into a community lead by a group of people (although small), while also introducing concept of additional specialized workgroups.

Why not more than three

Too many chefs spoil the soup.

The goal of having a leadership team is for team Python core developers to be able to come to consensus and decisions. The larger the leadership team is, the more difficult it will be in coming up with decision.

This is also for the benefit of the members of the trio. Learning to collaborate with other people in a team is not something that happen organically and takes a lot of effort. It is expected that members of the trio will be part of the team for a long term period. Having to deal with two other people is probably difficult enough. We want the trio to be able to do their duties and responsibilities as efficient as possible.

The more people in the group, the more difficult it is to try to come up with time to meet, discuss, and coming up with decision.

Roles and responsibilities of Python Core Developers to the trio

  • Be open, considerate, and respectful. In other words, adhere to The PSF’s Code of Conduct

  • Decisions and pronouncements made by individual members of the trio are to be seen as authoritative and coming from the trio.

  • Once the trio has pronounced a decision, core devs will be supportive, even if they were not supportive in the beginning (before the trio made such decision)

  • Continue with day to day decision making in the bug tracker, and defer to the trio if there is major disagreement

  • Python core developers do not handle CoC cases, those are responsibilities of the CoC workgroup, but will speak out if they witness those cases

  • Aware that they are part of the larger Python community, not just the technical aspect of it.

  • Be a voting PSF member (one of Contributing / Manager / Fellow / Supporter).

  • Set good example of behavior, culture, and tone to Python community.

Term (open to discussion)

The trio is not expected to serve for life, however a longer term is desired. The purpose of longer term service is to avoid unnecessary churns of needing to “elect”, and to provide stability and consistency in the language and the community.

Succession planning of the trio (open for discussion)

The trio should notify core devs of their intention to disband/retire/quit from their roles at least one year in advance, to allow for them to actively mentor and train the next generation of successors, and to avoid power vacuum.

The trio not necessarily have to be the ones choosing who the next leaders will be.

This PEP does not enforce that the same governance model be chosen for the next generation. Python as language and community can continue to evolve. By giving one year advance notice to disband, the trio is giving the core Python community an opportunity to reflect on the success/failure of this governance model, and choose a different governance model if needed.

However, the next governance model and leaders should be chosen/elected within one year after the trio announced their desire to disband.

If it was decided to continue with this model of governance, the next generation of trio will be nominated and elected similar to how the first trio were nominated/chosen.

The trio should act as advisor/mentor to the next generation chosen leaders for at least X months.

Since future trio will be chosen out of Python core developers, it will make sense for future Python core developers to possess some but not necessarily all, qualities of the trio as laid out in this PEP.

Therefore, the guidelines for selecting trio members can also be used as guidelines when identifying future Python core developers.

Scenario if one member of the trio needs to quit (open for discussion)

This is open to further discussion.

What if one member of the chosen trio has to quit, for unforseen reasons?

There are several options:

  • The remaining duo can select another member to fill in the role
  • The trio can choose to disband, core developers can nominate other trios
  • Core developers can choose a different governance model
  • ??

Formation of working groups/area of expertise/ownership (previously BDFL delegate)

(Open for discussion).

Certain areas and topic of Core Python and Python community require leaders with specific skills of specialty. It will be recommended that there will be several working groups with more authority in that specific area to assist the trio in making decisions.

The role of these “specialized work groups/council” is to be the final decision maker for controversial discussions that arise in their respective areas.

These working groups should be small (3-5 people), for similar reasons that the leadership trio is a small group.

These working groups should consist of both Python core developers and external experts. This is to ensure that decision made does not favor only Python core developers.

Python Core developers will defer decisions to these working groups on their respective topic. However these groups will answer/defer to the trio.

These working groups can be selected and members voted only after this PEP gets accepted.

If this PEP is accepted, the working group can be decided within a year or two after the PEP’s acceptance.

When selecting members of these special work groups, the trio will take every effort into including members from underrepresented group into consideration. Ideally, the workgroup members should include and reflect the diversity of the wider Python community.

Members of this workgroup do not need to be a Python core developer, but they need to be at least a basic member of the PSF.

These workgroup are active as long as the trio are active.

Several suggested working groups to start:

  • Documentation of CPython

  • Security of CPython

  • Performance of CPython

The workgroup can be seen as having similar role as the previously known role of “BDFL-delegate” or PEP czars. The difference is, instead of appointing a single person as decision maker, there will be a small team of decision makers.

Another difference with the previous “BDFL-delegate” role, the group can be active as long as the trio is active, as opposed to only when there is a PEP that requires their expertise.

When the trio disbands, these workgroups are disbanded too.

Why these workgroups are necessary

This is an effort to ‘refactor large role’ of the previous Python BDFL.

Reasoning for choosing the name trio

Not to be confused with Python trio (an async library).

The “trio” is short and easy to pronounce, unlike other words that are long and can have negative interpretations, like triad, trinity, triumvirate, threesome, etc.


This document has been placed in the public domain.


(Steve Dower) #2

Very nicely put! I like a lot about this, especially the “refactoring” idea, and explicitly planning for a new governance model at the next transition.

One question about vision: the early section says that the trio are expected to provide a vision for Python, but should not be expected to provide vision (one mention of vision in each list), which seems like a contradiction (not an argument :wink: ). I think this is suggesting that others outside the trio should provide vision as well, or perhaps it’s just an editing mistake, but it would be nice to be totally clear on whether the trio ultimately determines the direction that Python takes or not.

(Carol Willing) #3

Thanks @Mariatta for putting this together. I’m wondering if working groups should have a higher limit so as to improve participation from community stakeholders (science, web, data science, education, etc.) that have a vested interest in any breaking changes or new directions.

Perhaps the leadership of the working group is 1-5 people, but the working group is open to a larger audience for participation.

(Antoine Pitrou) #4

Can you explain why that is a requirement? I’m quite sure you’ll find core developers who are not PSF members at all (it’s not like there’s much to vote on as a PSF member, either). The PSF is mostly an administrative body, and many people are not interested in that.

(Victor Stinner) #5

I like diversity and I concur that it’s important, but I’m not sure about “With such team, disagreements and conflict should be rare” part. IMHO disagreement is fine and is expected if you take in account diversity. I don’t see the point of building a group of 3 people who always agree on everything. For me, diversity means to have different point of views and different use cases which can be incompatible.

I just suggest to rephrase the “disagreements and conflict should be rare” part.

(Jack Diederich) #6

I strongly agree with posting a slate instead of posting a list of nominees and skimming the top-N vote-getters. It avoids weird edge cases and gamesmanship. I can think of a set of three people, each of whom I would want to be on the council, but I wouldn’t want to all be on the council at the same time.


In my mind, diversity is much broader than simply diverse of point of views, but also skills and background.
Also, diverse does not mean always contradictory. If the leadership team consists of people who are historically always contradict each other, coming to a consensus and decision will be difficult.
Therefore I used the word “similar” and “complementary skills” instead of “different”.
If there is a better way to phrase this, do suggest, but I don’t want to put emphasis on “difference” here.

(Barry Warsaw) #8

So that means if I want to be on the trio, I have to pick my running mates carefully (or perhaps, luckily). Is there a prohibition from running on multiple slates? Could I run with Alice and Carl on one slate, and Albert and Cate on another?


The PSF does more than “administrative” things.

The PSF provides and manages funding for Python Language Summit, and Core Python sprint, both are crucial for core Python.
The PSF also provides the infrastructure for the bug tracker, GitHub bots, handles CLA formalities, and also Code of Conduct workgroup is organized under the PSF.

The reality is Python core developers relies heavily on The PSF, yet so far we’ve been seen somewhat different entities.

Going forward, I’d like to see the core team to work alongside The PSF more. At the very least, what core devs can do is to help elect the PSF board members (once a year). This PEP does not enforce core developers to be active and being the ones running for the board, but simply be a voting member.

By being a PSF member, one affirms that they are part of Python community, and that they share the same values and work towards advancing the mission of the PSF and supports the PSF’s diversity statement.

Being a member of The PSF is reasonable expectation out of Python core developers, it can help strengthen the trust from the community, knowing we are all part of the same community.
In my mind, all existing core devs are eligible for the Contributing level membership if they are not already. I do know that a number of people here are PSF fellow members too.

See the different levels here:


I don’t think there should be limitation that one can only be in one slate.
So yes, we can have Barry + Alice + Carl, Barry + Albert + Cate, so I think we’ll have no trouble with this.


Hmm I guess the name of “working group” is not appropriate. My context here is perhaps what you consider as the “leaders” of the working group. I think the wider community can still participate and provide suggestions, but the leaders are the ones coming up with consensus and decision. This section is for suggesting that we have such leaders. Hope this makes sense?

(Antoine Pitrou) #12

Part of that is that there are less and less core developers on the PSF board. If you look at the PSF board history, until 2012 a good fraction (almost half) of the PSF board was Python core developers. Nowadays there are two of them.

This is largely because the PSF has been emphasizing non-development activities, and has been promoting people based on social (e.g. community-oriented) rather than technical achievements. This can be seen as positive, but explains the rift between the PSF and the core development group.

Anyway… To come back to the constraint you’re proposing, I’m not sure forcing people to vote will achieve anything. Personally, I know that, while I do vote on the yearly PSF election, I have a hard time choosing people, since I usually don’t know them and the biographies all say exactly the same thing (has been working for diversity, organizes a lot of conferences etc. etc.). In general I end up voting based on a simple but potentially irrelevant criterion (last time I think I voted for non-Americans).

(Victor Stinner) #13

In the current board (2018-2019), I know that Kushal Das is a core developer. I’m not sure who is the second core dev, sorry :frowning:

(I’m talking about “Board of Directors”)

(Antoine Pitrou) #14

Thomas Wouters is a core developer (he’s even here @thomas). He’s just not very active :wink:

(Victor Stinner) #15

Thomas was my first guess, but I failed to find him in :frowning:

(Barry Warsaw) #16

I’m also uncertain whether it’s a good thing to require PSF membership or not. In some ways, I think it’s healthy that there’s a separation between the PSF and the core dev team. I’m pretty sure most core devs would balk loudly if the PSF began dictating any technical changes in CPython itself. OTOH, I’m sure I’m not alone as a core dev saying how much I value the work the PSF does! Core devs do the technical work better than the PSF does, but the PSF does community better. I think that’s actually okay.

(Guido van Rossum) #17

Remember that the PSF also runs and/or pays for the infrastructure!


The reality is we can’t separate the community from the technical aspect of Python.
During the sprint, the core developers were asked what about Python do they like the most. A majority of us answered, “the community”. And I believe this is the same sentiment shared with the broader Python community.

By being a member of The PSF, core dev affirms that they are part of the same Python community, that they support and work towards advancing The PSF’s mission and diversity statement.

It is not like core dev will do a lot more work by becoming a member of the PSF. Core devs are already working one step above the rest of the community by actively contributing to the language. The extra level of commitment and affirmation is important to gain trust from the wider community.

I don’t see any downside by being a member of The PSF, only positive things.

Sorry I don’t quite understand how this relates to the PEP. This PEP does not say that The PSF can now begin dictating technical changes to CPython. Perhaps you’re making overreaching assumptions.

The PSF can continue to “do community” better, but as core devs we are part of the community too. We might not want to do the “non technical” things, but we need to work alongside each other instead of clearly separating ourselves from “The community” or the PSF.

In case people don’t realize, the decisions made by The PSF affects the core devs already.


Hmm, I’m struggling to convey this part too. I simply expected the trio to be open to suggestions, similar to anyone (even non core devs) could propose a PEP, but ultimately the trio will decide what the visions are.

(Carol Willing) #20

Perhaps: the trio communicates the vision for Python’s future based on input from the Python core developers and greater Python community.