python-peps/pep-8002.rst

PEP: 8002
Title: Open Source Governance Survey
Author: Barry Warsaw <barry@python.org>, Łukasz Langa <lukasz@python.org>,
   Antoine Pitrou <solipsis@pitrou.net>
Status: Active
Type: Informational
Content-Type: text/x-rst
Created: 2018-08-24


Abstract
========

This PEP surveys existing and similar open source and free software projects
for their governance models, providing summaries that will serve as useful
references for Python's own selection of a new governance model in the wake of
`Guido's retirement
<https://mail.python.org/pipermail/python-committers/2018-July/005664.html>`_.

Rather than an individual PEP for each of these community surveys, they will
all be collected here in this PEP.


Rationale
=========

CPython is not the first open source project to undergo a governance crisis.
Other projects have experimented various governance options, sometimes several
times during their existence.  There are useful lessons to take away of their
experience, which will help inform our own decision.

Project choice
--------------

There are many open source projects out there, but it will be most fruitful
to survey those which are similar enough to CPython on a couple key metrics:

1. the number of contributors and their activity (there are scaling issues that
   don't make the governance models of very small projects very enlightening
   for our purposes) ;
2. being mostly or partly community-driven (company-driven projects can afford
   different governance options, since the company hierarchy has power over
   the main participants) ;
3. being faced with important design decisions that require a somewhat formal
   decision process.


Rust
====

The governance structure is documented in `Rust RFC #1068
<https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md>`_.

The effective governance process grows organically over time without being entirely
codified as RFCs, especially in case of day-to-day operation details.  One example is
the `formation of Domain Working Groups
<https://internals.rust-lang.org/t/announcing-the-2018-domain-working-groups/6737>`_ in
February 2018.

Key people and their functions
------------------------------

In the Rust project there are teams responsible for certain areas. For language features
there is a "lang team", for tooling there's "dev tools" and "Cargo", and so on.
Contentious issues have facilitators to drive discussion who often aren't the decision
makers.  Typically the faciliators are authors of the proposed changes (see
"Controversial decision process" below).  They ensure all key decision makers are
involved along with interested community members.  They push towards an agreeable
outcome via iteration.

In practice this means decisions are rarely escalated to the core team.

The most common role of a contributor is team membership.  Issue triage/code review
privileges without team membership is rare.  Contributors have full commit access,
code ownership separation is based on trust.  Writing to the compiler repository is
frowned upon, all changes go through pull requests and get merged by an integration
bot after they were reviewed and approved.

New team members are added by nomination by an existing team member.

Regular decision process
------------------------

Primary work happens via GitHub issues and pull requests.  Approving a pull request
by any team member allows it to be merged without further process.  All merged pull
requests end up in the next stable version of Rust.

Notifying relevant people by mentions is important.  Listening to the firehose of
e-mails for all GitHub activity is not popular.

There are planning and triage meetings open to the public happening on IRC and Discord.
They are not very popular because most of work happens through GitHub.  Discussions also
happen on official Rust forums (https://users.rust-lang.org/ and
https://internals.rust-lang.org/).  There is a dedicated moderation team responsible for
taking notes and enforcing `code of conduct
<https://www.rust-lang.org/en-US/conduct.html>`_.

Controversial decision process
------------------------------

Larger or controversial work goes through a `RFC process
<https://github.com/rust-lang/rfcs>`_.  It allows everyone to express their thoughts and
iterates towards a resolution.  At some point when all blocking concerns of relevant
team members are addressed, they sign off on the RFC and it reaches a "final comment
period". That does not require consensus amongst all participants, rather there should
not be a strong consensus against the proposal.

After 10 days the RFC is *merged* unless any new blocking concerns are raised by team
members.  A "merge" signifies that work towards implementing the feature and integrating
it can now happen without interruption.  An RFC doesn't have to have a reference
implementation for it to be accepted.

The other possible results of the "final comment period" are to:

* *postpone* the RFC (similar to the Deferred status in PEPs),
* get it *back into discussion* if blocking concerns can be addressed, or
* *close it* if blocking concerns are not solvable.  When an RFC is marked as
  *closed*, there is a 7 day grace period to debate whether it should be closed.

In practice registering concerns with an RFC happens very often initially but rarely
causes for the RFC to be entirely killed.

This process scales well for small-contention changes and/or smaller changes.  For the
largest controversial changes the discussion gets unwieldy.  This is a topic currently
(as of August 2018) on the minds of the Rust team (see:
`"Listening and Trust, part 1" <http://aturon.github.io/2018/05/25/listening-part-1/>`_,
`"Listening and Trust, part 2" <http://aturon.github.io/2018/06/02/listening-part-2/>`_,
`"Listening and Trust, part 3" <http://aturon.github.io/2018/06/18/listening-part-3/>`_,
`"Proposal for a staged RFC process"
<http://smallcultfollowing.com/babysteps/blog/2018/06/20/proposal-for-a-staged-rfc-process/>`_).

Planning a new release
----------------------

Every six weeks the Rust compiler is released with whatever it contained at the time.
There are no LTS channels or releases yet but this concept is planned to make
redistributors able to keep up with development better.

Every few years a so-called `"Edition"
<https://rust-lang-nursery.github.io/edition-guide/editions/index.html>`_ is released.
Those are milestone releases with full sets of updated documentation and tooling. They
can be backwards incompatible with previous editions.  External packages opt into
breaking changes in their crate metadata.  The Rust compiler supports all editions that
existed prior to its release.  Linking between crates of any supported edition is
possible.

Changes in the process over time
--------------------------------

The Rust programming language was started by Graydon Hoare who developed it as
a personal project for a few years.  When Mozilla started sponsoring the project,
the team slowly grew with Graydon as a BDFL-style figure.  He `left the project
<https://www.reddit.com/r/rust/comments/7qels2/i_wonder_why_graydon_hoare_the_author_of_rust/dsqeh1d/>`_
in 2013.  Rust functions without a BDFL since.  The RFC process was put in place later.
Initially some design discussions happened during closed-door weekly video meetings
which was `shut down
<https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2015-05-26.md#future-of-weekly-meeting>`_
in May 2015 (before the 1.0 release of Rust), organically replaced with open discussion
and direct influence of teams.

The number of teams is growing in time.  The number of technical decisions made by the
core team is decreasing, instead those get delegated to respective teams.

The concept of a "final comment period" was introduced to encourage more public
discussion and enable reacting to a change *about to* being made, instead of having to
revert a rushed decision that was already made.


Acknowledgements
================

Thank you to Alex Crichton from the Rust team for an extensive explanation of how the
core team governs the project.


Annex 1: Template questions
===========================

The following set of questions was used as a template to guide evaluation and
interaction with the surveyed projects:

1. Do you have any open documentation on how the governance model is set up?

2. How does the process look like in practice?

   * Who are the key people?
   * What "special statuses" can contributors have?
   * How are they elected/how are the statuses assigned?
   * How are regular decisions made?
   * How are controversial decisions made?
   * Is there a voting mechanism? how does it work? how often do votes actually happen?
   * Is there a veto mechanism? how often was it actually used?

3. How do you like the process?

   * Which parts work well?
   * Which parts could work better?
   * When it doesn't work well, how does it look like?
   * What would you change if it were only up to you?

4. Related project work:

   * How do you decide when a release happens and what goes into it?
   * How do you decide who gets commit access?
   * Where do you hold discussions? (GitHub, mailing lists, face-to-face meetings, and so on)
   * Do you have a RFC/PEP-like process?
   * Who has access to those discussion channels?
   * How is this access granted/revoked?
   * Who moderates those discussions?
   * Do you (and how) censure participants and how?

5. Process evolution

   * How did this process evolve historically?
   * How can it be changed in the future?


Copyright
=========

This document has been placed in the public domain.



..
   Local Variables:
   mode: indented-text
   indent-tabs-mode: nil
   sentence-end-double-space: t
   fill-column: 70
   coding: utf-8
   End: