# Draft Summary of Guido's Wise Kittens (aka CPython governance)

## I. Situation summary

*Paraphrased from Guido's email*

- A. Day to day decisions in the issue tracker or on GitHub
- can just be dealt with as it has always been.

- B. How are PEPs decided

- C. How are new core devs inducted

- D. Code of Conduct
- if you don't like that document your only option might be to leave this group voluntarily.
- Perhaps there are issues to decide like when should someone be kicked out (this could be banning people from python-dev or python-ideas too, since those are also covered by the CoC).

**PEPs combined to form a CPython constitution**
We may be able to write up processes for these things as PEPs (maybe those
PEPs will form a kind of constitution). But here's the catch. I'm going to
try and let you all (the current committers) figure it out for yourselves.

## II. Guiding Principles

Two widely accepted guiding principles should be consulted if we have difficulty reaching consensus:
- "I came for the language and stayed for the community"
- The Zen of Python

If we do not have a process decided for CPython community things (i.e. CoC), we should first look to work already being done by the PSF.

## III. Guido's governance suggestions

This section will take each of the major points brought up by Guido and summarize some of the discussion from python-committers.

### A. Day to day decisions on the issue tracker or GitHub

The existing process (what we are doing in practice and outlined in the devguide) should be fine for the short term.

We **trust** each other to do these activities in a manner that benefits the Python language, the CPython community, and honors the PSF mission: *"The mission of the Python Software Foundation is to promote, protect, and advance the Python programming language, and to support and facilitate the growth of a diverse and international community of Python programmers."*

#### Comments

> For the smaller decisions, ... leave the final calls to the subject matter experts, original authors, and module maintainers when applicable. The people who've invested the most time in a subject area are probably the best ones to be decision makers for those areas. But mostly, we should aim for consensus and only appeal to a decision maker when there is a major divergence about which way to go.
>

### B. How are PEPs decided

#### Suggested options

- **vote** where the majority wins. Vote is reserved to core developers.
- **dictator per PEP**
- **triumvirate or quintumvirate** Ruling of elders with three or five powerful individuals. Guido’s Unworthy Inherited Delegation Organization and trium*ate are also suggested name.
- **research other options / informational PEP**
- **another BDFL or BD**

##### Process changes for an option

- length of tenure
- selection / election

##### Comments

> Essentially the idea would be have a wiki/faq editable by all the participants. It would include the key examples, arguments for and against, and rebuttals which can be collected into a current-state-of-the-conversation. ...somewhat different than the current PEP process because currently PEP authors dominate the conversation and others can get drowned out too easily.

> nice to have the decisions made by someone other that the principal proponents. From my own experience with PEPs, I know that the psychological effects are powerful -- if you are the one spelling out all the details and defending the idea against all the slings and arrows, then it is only natural to come to identify with the PEP and come to believe that the only righteous outcome is for it to be accepted.

> With the current discussion method, the costs are often disproportionate ([editor summary] to the value in time, money, burden)

> One idea is to have a list dedicated to PEP discussions. We could
establish a set of rules (cultural norms) for discussion on that
list.
> - do your background research before posting: read PEP in its
entirety, read complete PEP discussion thread
> - make high quality posts: ensure your points are truly bringing new
ideas forth, present them clearly and succinctly
> - lay down rules for subject lines of posts, when you can start a
new thread. Off topic discussion should go back to python-ideas.

> a key asset that Guido has provided for us as a BDFL is
consistency in design/taste. Design by committee through voting does not
appeal to me at all as that can too easily lead to shifts in preferences
and not have the nice cohesion we have with the language's overall design,
especially considering that there will always be subjective choices to make
(someone has to eventually choose the colour of the shed). People,
including me, have also pointed out that by having Guido to look up to you
we have had a very consistent view of how the community should behave and
that too has been an asset.

> my choice is dictator or triumvirate.

> I'd like to point out that the N-virate idea doesn't handle a key issue:
once you have a N-virate, how do you evolve its composition according to
the implication and motivation of its members - but also to remarks or
frustation by non-virate contributors (especially new contributors who
will feel there's a perpetual category they're locked out of)? Do you
just wait for people to gently step down when required?

> ... define the scope of
any long-term appointees. For example, saying "we have an N-virate that
decides on PEPs" is very different from saying "we have an N-virate that
decides on the PEP approver (formerly BDFL-delegates)". The latter does
not necessarily lock anyone out from being a critical part of Python's
future, but it does avoid endless arguments about selecting who is
responsible with deciding.

> For me, I would like the release manager to also take on some of the
responsibility for new features in their releases. Perhaps holding one
position in an N-virate for the current RM (who continue rotating every
two releases) is a good way to keep things fresh?

> One way would be to re-elect them every 5 or so years. Essentially,
an N-virate is a dictator-like entity for a few years

> We've had good luck in the OpenStack community tying leadership to
release cycles. It causes elections more often (our cycles are 6
months long), but people tend to step up for several cycles in a
row so that hasn't been a cause of excessive turnover. Having
frequent opportunities for folks to step down gracefully when they
need or want to also means no one feels like they are signing up
for an indefinite time commitment.

> For a multi-person group, staggered elections where only a portion
of the group is up for election at one time, also provides some
consistency when there is turnover.

> release cycle length is an amount of time the community is used to dealing with, and therefore might make a good cadence for elections or whatever other rotation mechanism is selected for the new group.

> trying to have
the release manager also be a decider of potentially controversial things
doesn't seem scalable.

> current RM can serve a useful role on the Council, but not in a voting capacity.

> * A Council member wants to author a PEP. They probably shouldn’t also get to vote on the PEP’s acceptance, so the RM can serve as a replacement vote for that one PEP. (Maybe only for Standard Track PEPs).

> * If a Council member is temporarily unavailable, the RM can serve in their place during that period.

> * The RM can give valuable insight that may influence Council members votes. Maybe the PEP’s implementation is too difficult for the current release, and recommends deferral.

> * If the Council also decides on the “PEP-worthiness” of an idea, the RM can weigh in based on their unique perspective on the release cycle.

> * The RM can provide an independent oversight role on the Council, kind of like an ombudsman (or maybe that should be a separate role, although I suspect it will be rarely invoked in practice).

> But that doesn't help deal with inconsistency since that just means we have
consistency for 2 releases and then we start all over again. If you're
suggesting someone forcibly rotates out every 5 years then that's different
since that adds in some consistency thanks to the remaining two members.

> Remember the time scale we are talking about here. Python is 28 years old,
so a 5 year scale means we would have swapped leaders 6 times at this
point. Python 3.0 came out in 2008, so we're approaching 10 years, so a 5
year time scale we would not have had any consistency in just Python 3's
lifetime.

> IOW I don't see anyone (or some group of 3) who is as well-versed in
everything on Guido's level. That can be solved if Guido agrees to
join the permanent N-virate though :)

> Are we looking for people who are skilled at language design, or who are
skilled at building consensus through open decision-making processes?
Because those are very different sorts of skills, and if this new body
is intended to only be a final arbiter on decisions the former set of
skills may be less important than the latter.

> I think we'll be talking less and less about language design, and instead about library and infrastructure design.

> I suspect this will make us much more conservative in accepting
language changes compared to e.g. what our deprecation policy should be.

> - Primary to delegate responsibilities to domain experts
> - Secondary to provide consistency and trust
> - Lastly to have final word in case of controversial bike shedding

> If the primary approach to decision making is to delegate unless
an arbiter is absolutely necessary, then long-term consistency and
stability comes less from finding individuals to commit to serving
for very long terms on the N-virate as it does from everyone having
a good understanding of the history of discussions and from a
willingness to keep the status quo in situations where consensus
isn't reached (note "consensus" rather than "unanimous agreement").

> Building the system to support and encourage turnover, like we do
with release managers, lowers the level of effort someone is signing
up for when they agree to serve. Given the *many* discussions of
burnout in the Python community and open source in general, that
seems like an important feature.

> Ongoing consistency is achieved through a strong culture.

> The actual solution is to ensure the members of the group are humble
enough to admit this, and aware enough of the community to be able to
identify and nominate the people who are well-versed enough for a
particular subject.

> We should *always* be able to nominate a core committer to be the
designated expert for a particular area (at least for long enough to
approve a PEP). If we cannot, the problem is that we don't have anyone
for that area, not that the triumvirate isn't well-versed enough themselves.

> I prefer more transparency in governance generally, and as a member of the community governed by this body I'd prefer more rather than less insight into the process and the thinking that went into the decision.

> As for the new governing model, I imagine that we don't need to make
any decisions *right now*. As suggested, core devs can simply
count +1/-1 on any language feature and we'll see how it goes. Or
maybe the first such vote should be on the new governing model? :)

> I really hope that we won't have an excruciating debate on the mailing list about the governing model though; maybe we can discuss it on the upcoming core dev sprint.

> In the short term we could appoint a *temporary* triumvirate to fill
in as BDFL (with the intent to re-assess the situation in September if
we haven't resolved on a permanent solution by then). That would
allow us to maintain business-as-usual (and try out a triumvirate).

> The details don't matter. The point is that, at heart, Python is what it
is because Guido is who he is. No matter what we do when he steps down,
Python will change in a fundamental way.

> https://www.python.org/dev/peps/pep-0401/

> Consistency, I suggest, outweighs many of our other valid concerns raised
so far. I support the approach of sorting out over time how the
composition of the triumvirate changes and when -- legislating how things
work before we have a good sense of things will quickly become
problematic. I have faith in the people we are choosing from for the first
triumvirate.

> My first instinct is to suggest: instead of one successor, we will have
several people as the new "leaders", perhaps a co-BDFL, or even 3-5 people
as co-BDFLs/leaders.
This is based on my experience with organizing meetup and conference.
The benefit is to lessen the burden and responsibilities of one person, and
they will have backups when they need to go on a break, vacation, take care of personal life.

> Will this limit the candidacy to certain
people just because they have the employer support?
> - I don't think it necessitates work time, but you might want to check with your family if
they are happy with your current engagement level. ;)

>
One useful resource is Vicky Brasseur's talk: *Passing the Baton, Succession
planning for your project* https://www.youtube.com/watch?v=Jhkm2PA_Gf8
The [slides](
https://ia800809.us.archive.org/2/items/pyconau2017-successionplanning/03-pyconau2017-successionplanning-with_notes.pdf)

> Some ideas from that talk:
> 1. identify critical roles (e.g. PEP decision making)
> 2. refactor large roles
> 3. mentor the new successor, shadow the previous leader
> 4. document all the things

> key function Guido provided was tone and consistency in design.

> It’s important to recognize that we have so many intelligent and compassionate contributors, that much of Python’s ongoing development can essentially carry on unchanged ... PEP 572: It’s up to all of us to accept that, move on, and learn to use it tastefully.

> Where the BDFL role is most important is in those holistic decisions about global features, such as PEP 572. These things impact everyone and every corner of Python, so having a final arbiter(s) that is accepted by the community at large is critical.

### C. How are new core devs decided

### D. Code of Conduct for CPython community spaces

- Follow the lead set by Guido
-
#### Comments

> I believe none of us is an expert in *this* kind of problems so I’m positive it would be beneficial to a) look what others did and process it into a PEP(?), b) possibly even involve someone external who *is* an expert like PyCon US did with their CoC, and most importantly c) never, ever quote works of ---.

> People,
including me, have also pointed out that by having Guido to look up to you
we have had a very consistent view of how the community should behave and
that too has been an asset.

> I joined the PSF's CoC committee in hopes of coming up with a proposal by
the end of the year for fleshing out details of enforcement, etc., so my
hope is this will eventually get resolved.

## Other Items / Future Study

### 1. Informational PEP

I think it would be worth studying the governance structure of a
bunch of open source projects picked according to a set of criteria:

- major project in # of users and contributors
- non BDFL-governed
- mostly volunteer-driven
- with an established decision process for major enhancements

(e.g. as an informational PEP)

> Suggestions: Apache, GNOME, Plone... there are many. (biased:) Apache is large, volunteer-driven, and long-established. There is also some crossover between the PSF and the ASF, to assist with such a review.