[python-committers] Governance Discussion #2 Notes (original) (raw)

Steve Dower steve.dower at python.org
Sat Sep 15 23:22:12 EDT 2018

• Previous message (by thread): [python-committers] Governance Discussion #1 Notes
• Next message (by thread): [python-committers] Azure Pipelines Linux failures on PRs
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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.

• Previous message (by thread): [python-committers] Governance Discussion #1 Notes
• Next message (by thread): [python-committers] Azure Pipelines Linux failures on PRs
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the python-committers mailing list