166 lines
7.2 KiB
ReStructuredText
166 lines
7.2 KiB
ReStructuredText
PEP: 8002
|
||
Title: Open Source Governance Survey
|
||
Author: Barry Warsaw <barry@python.org>, Łukasz Langa <lukasz@python.org>
|
||
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.
|
||
|
||
|
||
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.
|
||
|
||
|
||
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:
|