[python-committers] Governance Discussion #2 Notes

[Steve Dower]

Hi all

At the sprints this last week, probably unsurprisingly, we had some
discussions relating to the future of Python's governance. Since not
everyone could be involved, I'm going to be posting the notes from these
meetings (taken by an independent note-taken, and reviewed/redacted by
the participants before being made public).

I want to be very clear that no final decisions were made at these
meetings, but they were very helpful in helping those of us working on
concrete proposals. You should start seeing PEPs 80xx filling out with
content over the next few weeks. *Those* are the reference documents -
these notes are simply a record of what came out of discussions.

If you want to reply to and discuss particular points from these,
*please* reply to the list, change the subject line, and clearly quote
only the relevant part. There is a lot of content here and nothing to be
gained by repeating it endlessly. (Also, if you want to thank me for
copy-pasting into an email, it really is unnecessary but please do it
off-list. We've already passed on our thanks to the note-taker as well.)


For this second meeting, we reduced the audience to those particularly
interested in the governance models. We had four represented there,
which will be written up as PEPs 8010, 8011, 8012 and 8013 over the next
few weeks. I have inserted links to the current drafts of these in the
notes, though at this stage they are mostly still placeholders.

Again, the proposals that we will vote on will be accurately described
in the PEPs. the notes here are basically inaccurate summaries of the
discussion, but we are sharing the notes to help everyone get a sense of
what values we are thinking about when designing proposals, and the
aspects of Python development that we like and the ones we want to change.

This is not the thread to start arguing about details - if anything in
this email makes you upset or nervous, please assume that the email is
at fault and wait for the actual proposals.

Cheers,
Steve

---

The previous meeting showed that there were three main areas of concern:
* What do we want the culture of the team to be?
 * How do we want to interact with each other and with the larger Python
community?
 * How can we build a system that encourages those interactions?
 * Example: if we don't use a mailing list, what do we use?
* What's the five year plan of python?
* How do we decide on a governance model?

These are deeply interrelated questions; notes that follow attempt to
summarize various contributor's points:
* The answers to the first two questions can be determined by the new
governance, whatever that is.
* We must quickly get away from the perception that Python is leaderless.
* We need specific structures, with specific people.
* Both those structures and the people must be selected by a process
that is perceived to be fair and open, without all our energy being
consumed by debate about minutia.
* It will be difficult to decide anything else until there is a clear
leadership structure.
* If we have multiple people who want a focus on async, or on
performance, or on typing, we need some way to resolve what should be
the focus for the next five years.
* These all influence each other. "Where do we want Python to go?" is
very germane to "what should the leadership model be?"
* We can end up in a rathole. Can we identify constituencies that we
want to serve? Education, science, kids, whatever. The structure is less
important than choosing a structure and working towards goals that serve
constituencies within that structure.
* Governance is also heavily tied to communication: how do we make
mundane decisions, how do we resolve controversies? This is all about
communication. Other languages have specified details of their
communication models in their governance arrangement: we put our notes
here, we communicate with this channel, and so on
* There may be different decision-making and communication models for
different areas.
* If you have a BDFL, do they take on everything Guido took on? Or are
they the titular spokesperson who interfaces with the public, and
delegates other decisions to committees?
* Having no governance model is worse than having a suboptimal model.
* The US Constitution was written knowing that the first order of
business would be the Bill of Rights.
 * What is our list of things that we know we need to deal with as soon
as we have a governance model?
 * Deciding how to commit to a governance model has highest priority.
* Our goal should be to achieve general consensus on what looks like a
fair voting model before we vote.
* Wherever we end up at the end, we want the leadership to be perceived
as legitimate and backed by the community.
* The greater good is more important than any particular desired detail.
* The governance model has to be backed by goodwill.
* Should we first determine where Python is going, in order to ensure
that the governance model supports it?
* "I disagree with the details but I support the process" should be the goal
* Python's governance model has been an active, top-down decision maker;
most open source projects have a much more hands-off steering council.
Split Guido's current roles across both formal, hands-off top-down
model, and an organic, bottom-up community based model.
* Do we know who wants to take a leadership role?
 * Are there people who want to actively be involved as a BDFL, a
triumvirate, a council, and so on?
 * If we only have one volunteer for BDFL, this is a waste of time.
 * Triumvirates form as a mechanism for resolving conflict amongst leaders.
* What if no one wants to step into a leadership role?
 * More people will be involved in lesser roles.
 * We can probably find five people who want to be involved in a council.
 * But perhaps nothing will happen with a leadership group of that size.
* What about looking at it the other way: who will go along with
whatever structure gets put in place?
 * Those people are contributors, not leaders, and they don't have to be
involved in the discussion.
* Three main proposals:
(1) BDFL with advisory council and working groups model.
(2) No BDFL, steering committee of say three people.
(3) pure democracy, community driven, only working groups.
* Can we aim for initial draft PEPs October 1st?
* Each of these can be parameterized
* If no one is interested enough to even write a proposal, we can reject it.
* A rejection of a specific proposal is not an endorsement of its opposite.
* Roles granted in perpetuity? Or a cycle?
 * This question should go into a session
 * These are parameters to the proposals

--------------------------------------------------

Follow up two:
Champion your ideas
But remember this is not a competition; this is about doing what's best
for Python
Quick summary of earlier voting discussion:
restricted to core developers who currently have commit bit (or who have
commit bit by end of this week)
ask people who are not affected by the decision to abstain
private repo to post votes
* votes will be made public after; this is not an anonymous vote
 * voting for individual positions later will likely be anonymous
 * this system encourages dialog
 * many people are fine with any of the proposed options but they have
opinions about what is best
 * a public process helps avoid backroom complaining
 * it seems acceptable to have public vote on governance issues
 * quorum is whoever shows up to vote
 * 50% + 1. Supermajority is only 14 people more, so seems unnecessary
 * there are only 93 people in the set of possible voters
*When creating proposals that involve a BDFL, or other role, do not name
a person or group of people. Name a mechanism for choosing that person
or group of people.
*Put in as many specifics as necessary to make your proposal attractive
*The constitution of the united states says how to update itself; do the
same in a governance proposal.

Proposal One: No BDFL, all democracy all the time
PEP 8012 - https://www.python.org/dev/peps/pep-8012/
* Inspired by Rust and Django
* Working groups are self-selected from people interested in focus areas
* Non-experts in an area trust that experts will do well in an area
* Regular decision making process is mostly "go ahead and do it"
* Controversial decisions require a process with documented phases: make
a PEP, find a champion, get comments, set a deadline, decide on whether
it is accepted, rejected or postponed
* How does veto work? Put it to a vote.
* The "voice of Python" is expressed not by a person, but by the design
documents produced
* If you don't want assignment expressions, vote for my proposal

Proposal Two: external auditors
PEP 8013 - https://www.python.org/dev/peps/pep-8013/
* Working groups should continue to go forward — the people who are
working on a specific PEP, and not necessarily core developers.
* Normal decision process should continue
* Controversial decisions should be taken to an elected group of three
people who are NOT core developers who are arbiters of process concerns.
Call them the auditors.
* Appointed for how long? A year? Years? A release? This is a parameter.
* No term limit; you can be re-elected
* Not a developer; an escalation mechanism for when developers cannot
reach consensus
* Every time you take a controversial decision to the auditors, you have
to explain the problem in detail well enough to convince them that
you've done due diligence about design, user impact, and so on.
* Auditors can veto controversial decisions until there is enough
diligence done
* Auditors can require that a decision goes to a vote if it is still
controversial
* Auditors can require that more people weigh in
* Auditors cannot mess things up by proposing new bad stuff; they can
only slow down (hopefully bad) decisions
* We have a list of names of notable people who would be great at this;
whether they'd be willing is another question
* Microsoft would offer employees for this role, but maybe core
developers are opposed to corporate influence

Proposal Three: Trivumvirate of core developers
PEP 8011 - https://www.python.org/dev/peps/pep-8011/
* a similar scheme to Proposal Two, but where the triumvirate must be
core developers
* We are too used to the BDFL model and may be worried to change it
* Should be a diverse group of three people who can work together.
* These people must be trusted; if that trust breaks down then we have a
crisis — but of course we can always change the governance model if this
doesn't work
* Elected for longer than a year; semi permanent
* Role similar to previous BDFL, but with multiple people coming to
consensus.

Proposal Four: Find another BDFL
PEP 8010 - https://www.python.org/dev/peps/pep-8010/
* Elect a BDFL
* Continue with working groups
* Create a council as an advisory group to the BDFL, help find
delegates, and so on
* The BDFL has a broad view of the python ecosystem, and weigh in on
large scale changes, say to the grammar, or changes that have broad
impact, like deciding between performance and compatibility.
* Must be seen as "the voice of Python"
* The BDFL champions the overall vision of the evolution of the
language, with the support of the community
* "For life" is a misnomer. There should be a recall process or vote of
no confidence.
* Release manager has an important advisory role

Thoughts:
* These proposals are consistent in that most of the work is done in
informal groups, there is some sort of leadership council who ensures
that processes are followed.
* The working group and PEP process is pretty much the same in all these
proposals
* The fundamental differences are in who has authority: (1) no
authority, self-policing, (2) authority over process vested in
non-developers, (3) authority vested in a group of developers and (4)
one BDFL
* We can always make a decision, try it, and if it doesn't have good
outcomes, have this conversation again in two years
* Consider the role of release manager in all of these; they have a lot
of power in that they can file a release-blocking bug against stuff they
don't like
* Are there issues with how we induct/vote in new core developers?
* Individual working groups are autonomous and have authority to decide
who is core to their working group
* How do we solve controversial issues? Take it to a vote, take it to
auditors, take it to the BDFL.
* Do we have examples of community-based open-source projects that are
run using proposal 2? No. But we have lots of examples of that model in
business-run projects, non-profit-run projects, and so on.
* There are examples of members of technical committees secretly
proposing features and then approving them, sock puppeting, and so on.
We would want to avoid that. Similarly a BDFL will need to appoint a
delegate if they are also proposing PEPs, and so on.
* Need a graceful way for a leader to step down when their life requires
them to do so. Burnout is real and insidious.
* Be aware of conflicts of interest, double dealing. Financial self
dealing is probably not a problem for us.
* How do we ensure consistency in decision making?
 * Excessive churn in leadership works against this.
 * Having a set of core principles will help.
 * Election campaigning for leadership roles is a mechanism for people
to choose direction.
* Would be helpful if every PEP had a core developer to sponsor it.
Particularly if final approval moves to python core devs.