[pep-8002] Add Rust governance summary

pep-8002.rst

@@ -1,6 +1,6 @@
 PEP: 8002
 Title: Open Source Governance Survey
-Author: Barry Warsaw <barry@python.org>
+Author: Barry Warsaw <barry@python.org>, Łukasz Langa <lukasz@python.org>
 Status: Active
 Type: Informational
 Content-Type: text/x-rst
@@ -20,6 +20,114 @@ 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 grew organically over time without being entirely
+codified.  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 the core team is rarely key in a decision.
+
+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.
+
+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 in the *r/rust* subreddit.  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 concerns of relevant team
+members are addressed, they sign off on the RFC and it reaches a "final comment period".
+
+After 7-10 days the RFC is *merged* unless any "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.  There were no cases of an RFC reaching the
+"final comment period" but not actually being eventually merged.
+
+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 year there is going to be an "Edition" release.  Those are milestone releases.
+
+Changes in the process over time
+--------------------------------
+
+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
 =========