[pep-8012] Initial draft 0

pep-8012.rst

@@ -1,28 +1,427 @@
 PEP: 8012
 Title: The Community Governance Model
-Author: Barry Warsaw <barry@python.org>
+Author: Łukasz Langa <lukasz@python.org>
 Status: Active
 Type: Informational
 Content-Type: text/x-rst
-Created: 2018-08-24
+Created: 2018-10-03
-
-
-.. note:: This is just a placeholder until the actual governance PEPs are
-          written.  It is possible that the title, content, model proposed,
-          and authorship will change once the PEP is actually written.
 
 
 Abstract
 ========
 
-This PEP proposes a new model of Python governance based on consensus and
+This PEP proposes a new model of Python governance based on consensus
-voting by the Python community, without the role of a centralized singular
+and voting by the Python community, without the role of a centralized
-leader or a governing council.  It describes how, when, and why votes are
+singular leader or a governing council.  It describes how, when, and
-conducted for decisions affecting the Python language.  It also describes the
+why votes are conducted for decisions affecting the Python language.
-criteria for voting eligibility.
+It also describes the criteria for voting eligibility.
 
-Should this model be adopted, it will be codified in PEP 13 along with the
+Should this model be adopted, it will be codified in PEP 13.
-names of all officeholders described in this PEP.
+
+This model can be affectionately called "The Least Worst Governance
+Model" by its property that while far from ideal, it's still the most
+robust one compared to the others.  Since avoiding issues inherent to
+the other models is a paramount feature of the Community Governance
+Model, we start the discussion a bit unusually: by rejecting the
+other models.
+
+Rejected Ideas
+==============
+
+Let's have another BDFL
+-----------------------
+
+This seems like a very attractive idea because it's a model we know.
+One Dictator to rule us all.
+
+There is no other Guido
+~~~~~~~~~~~~~~~~~~~~~~~
+
+There is no other single person with the unique skillset of Guido van
+Rossum.  Such person would have to combine the following characteristics
+to be a successful leader of the project:
+
+* cohesive long-term vision for the project;
+
+* deep technical understanding of the runtime, the standard library,
+  and the wider third-party library context;
+
+* ability to resolve contentious issues in ways acceptable to all
+  parties involved;
+
+* continuous time involvement over periods of years to keep the
+  above-mentioned traits over time and exercise them.
+
+Malevolent Dictator For Life
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+What if we got somebody who is not as well suited for the position as
+our first Dictator?  There are possible scenarios in which this could
+lead to severe consequences.
+
+The Dictator could gather insufficient trust due to missing technical
+depth, a "close" election, inconsistent vision, poor ability to deal
+with conflict or burnout, and so on.  Given a controversial decision
+decided by the Dictator in a specific way, a Dictator with
+insufficient trust may cause a split within the project.
+
+The Dictator setup invites lobbying concentrated on a single person.
+Unless that person is immune to leverage due to wealth, health, and
+a stable life situation, this poses risk of malicious actors steering
+the project from behind the curtain.
+
+Finally, the Dictator coming from a particular part of the community
+may put more weight on the needs and interests of that particular part
+of the user base, alienating others.
+
+We don't actually need a Dictator
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The irony of the Dictator model is that it requires an election.  Better
+yet, we need an election to even decide on which governance model to
+use.
+
+If we are already able solve two problems of this gravity via the
+community process, why not keep using it for all subsequent decisions?
+
+The warm and fuzzy feeling of a vague proposal
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+One last thing worth mentioning is that when a BDFL model is suggested,
+it's easy to bypass the criticism above by not mentioning *who* the BDFL
+should be.  That way the hopeful reader can project their best
+expectations and wants onto the abstract BDFL, making the idea appear
+more attractive.  This is a mistake.
+
+Without naming the BDFL in the model proposal we are not talking about
+a concrete model.  We can avoid asking and answering the hard questions.
+We can imagine our best-case scenario, a candidate we'd like to serve
+the role.
+
+Omitting a name also puts the Community Model at an unfair disadvantage.
+We already know the good, the bad, and the ugly of our core developer
+group.  It's no platonic ideal, no perfect sphere with no friction.  In
+fact, we expect there to be a fair amount of friction and imperfections.
+
+Thus, to fairly assess the BDFL model proposal, dear reader, you
+should imagine the worst possible person within our team as that
+BDFL.  A concrete human being.  Imagine it's me.
+
+
+Let's have a Council
+--------------------
+
+This group of people roughly sharing the responsibilities of a Dictator
+can also be called a Triumvirate, a Quorum, Elders, Steering Committee,
+and so on.
+
+Like a Dictator, only worse
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This model favors a small group, between three to five people.
+That way it shares most of the criticism with the Dictator model,
+amplified.  Having not one but, say, three people in position of power
+dillutes responsibility while still providing high risk of lobbying,
+insufficient trust, or alienating parts of the community.
+
+Additionally, having multiple people share the responsibility of
+governance creates ample opportunity for internal conflict,
+inconsistent long-term vision of the project, and multiplies the
+required continuous time involvement by its members (it's no Quorum
+if they can't "reach quorum" due to other time commitments).
+
+Just like with a frictionless spherical BDFL, reject ideas of
+Councils without considering how would it work for you if that
+Council consisted of three people you find inadequate for the role.
+Imagine if I had two friends.
+
+Most importantly, just like with a Dictator, we don't need a Council.
+By the time we had one, we would have already had two successful
+elections.  Why not keep voting?
+
+
+Motivation
+==========
+
+Now that we rejected all that we should, let's talk why we even need
+a governance model on top of a loosely defined group of committers.
+
+We want to block single committers from making wide-reaching changes
+that impact the future of the language.  Coherent vision and backwards
+compatibility are important in any programming language, but they are
+doubly important for Python which is very dynamic (e.g. has very complex
+backwards compatibility implications).  Moreover, Python is used by a
+diverse group of users, from school children through scientists to
+corporations with multi-million line codebases.  We want to include
+all our varied audiences.
+
+We want to avoid stagnation.  Python is a mature project but it needs
+to keep evolving to stay relevant, both the runtime and the programming
+language.  To do that, people interested in improving a particular part
+of the project should be able to do so without needless friction.
+But for substantial changes, we want some friction to ensure they are
+wise changes.
+
+
+Rationale
+=========
+
+The Community Model is the most inclusive model.  No single person or
+a small group of people is in a distiguished position of power over
+others.  Contributors in this model are self-selecting.
+
+This model ensures no user group is put at a disadvantage due to the
+interests of a single person or a small group of people.
+
+This model works.  There is a number of large open-source projects run
+this way (two of which, Rust and Django, are described in PEP 8002).
+ECMAScript and C++ are similarly developed.
+
+
+Specification
+=============
+
+Key people and their functions
+------------------------------
+
+The core team
+~~~~~~~~~~~~~
+
+The Python project is developed by a team of core developers.
+While membership is determined by presence in the "Python core" team
+in the "python" organization on GitHub, contribution takes many forms:
+
+* committing changes to the repository;
+* reviewing pull requests by others;
+* triaging bug reports on the issue tracker;
+* discussing on official Python communication channels. 
+
+Some contributors are dormant, in other words they did not contribute
+to the last two releases of CPython.  Any dormant contributor can at
+any time resume contribution.
+
+Experts
+~~~~~~~
+
+The Python Developer's Guide lists a number of interest areas along with
+names of core developers who are recognized as experts in the given
+area.  An expert or a sub-team of experts has the following
+responsibilities:
+
+* responding to issues on the bug tracker triaged to the given interest
+  area on a timely basis;
+* reviewing pull requests identified as belonging to the given interest
+  area on a timely basis;
+* overviewing cohesive design in the evolution of the given interest
+  area.
+
+A core developer can assign and unassign themselves at will to
+a given interest area.  Existing experts listed for the given interest
+area must be made aware of this change and have to unanimously agree to
+it.
+
+If a given interest area lists multiple experts, they form a sub-team
+within the core team.  They are responsible for the given interest area
+together.
+
+A core developer should avoid membership as an expert in too many
+interest areas at the same time.  This document deliberately doesn't
+specify a maximum number, it simply signals that overexertion leads to
+burnout and is a risk to the project's ability to function without
+a given contributor.
+
+Moderators
+~~~~~~~~~~
+
+There is a group of people, some of which are not core developers,
+responsible for ensuring that discussions on official communication
+channels adhere to the Code of Conduct.  They take action in view of
+violations.
+
+
+Regular decision process
+------------------------
+
+Primary work happens through bug tracker issues and pull requests.
+Core developers should avoind pushing their changes directly to the cpython
+repository, instead relying on pull requests.  Approving a pull
+request by a core developer allows it to be merged without further
+process.
+
+Notifying relevant experts about a bug tracker issue or a pull request
+is important.  Reviews from experts in the given interest area are
+strongly preferred, especially on pull request approvals.  Failure to
+do so might end up with the change being reverted by the relevant
+expert.
+
+Experts are not required to listen to the firehose of GitHub and bug
+tracker activity at all times.  Notifying an expert explicitly during
+triage or bug/pull request creation may be necessary to get their
+attention.
+
+
+Controversial decision process
+------------------------------
+
+Substantial changes in a given interest area require a PEP.  This
+includes:
+
+* Any semantic or syntactic change to the language.
+* Backwards-incompatible changes to the standard library or the C API.
+* Additions to the standard library, including substantial new
+  functionality within an existing library.
+* Removing language, standard library, or C API features.
+
+Failure to get a substantial change through the PEP process might result
+with the change being reverted.
+
+Changes that are bug fixes can be exempt from the PEP requirement.  Use
+your best judgement.
+
+PEP, Enhanced
+~~~~~~~~~~~~~
+
+The PEP process is augmented with the following changes and clarifications
+over information already present in PEP 1:
+
+* PEPs are not merged until the final decision is made on them; they are
+  open pull requests on GitHub until that moment;
+
+  * to make review easier, all changes to the PEP under review should be
+    made as separate commits, allowing for granular comparison;
+
+* a submitted PEP needs to identify the area of interest and relevant
+  experts as the body that makes the final decision on it;
+* if the PEP author is one of the experts of the relevant area of
+  interest, they must name another person from outside of that interest
+  area to contribute to the final decision in their place;
+* the PEP author is responsible for gathering and integrating feedback
+  on the PEP using the official communication channels, with the goal of
+  building consensus;
+* all community members must be enabled to give feedback;
+* at some point, one of the named experts posts a "summary comment" that
+  lays out the current state of discussion, especially major points of
+  disagreement and tradeoffs; at the same time the expert proposes
+  a "motion for final comment period" (FCP), along with a proposed
+  disposition to either:
+
+  * accept;
+  * accept provisionally;
+  * reject; or
+  * defer the PEP.
+
+* to enter the FCP, the PEP must be signed off by all experts of the
+  relevant area of interest;
+* the FCP lasts for fourteen calendar days to allow stakeholders to file
+  any final objections before a decision is reached.
+
+Very controversial PEPs
+~~~~~~~~~~~~~~~~~~~~~~~
+
+If a core contributor feels strongly against a particular PEP, during
+its FCP they may raise a motion to reject it by vote.  Voting details
+are described below in "Voting Mechanics".
+
+This should be a last resort and thus a rare occurrence.  It splits the
+core team and is a stressful event for all involved.  However, the
+experts filing for an FCP for a PEP should have a good sense whether
+a motion to reject it by vote is likely.  In such case, care should be
+taken to avoid prematurely filing for FCP.
+
+There is no recourse for the opposite situation, i.e. when the
+experts want to reject a PEP but others would like it accepted.  This
+ensures that the relevant experts have the last say on what goes in.
+If you really want that change, find a way to convince them.
+
+Moderators on official communication channels enforce the Code of
+Conduct first and foremost, to ensure healthy interaction between all
+interested parties.  Enforcement can result in a given participant
+being excluded from further discussion and thus the decision process.
+
+Revisiting deferred and rejected PEPs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If a PEP is deferred or rejected, the relevant experts should be
+contacted first before another attempt at the same idea is made.
+If the experts agree there is substantial evidence to justify
+revisiting the idea, a pull request editing the deferred or rejected
+PEP can be opened.
+
+Failure to get proper expert buy-in beforehand will likely result in
+immediate rejection of a pull request on a deferred or rejected PEP.
+
+Other Voting Situations
+~~~~~~~~~~~~~~~~~~~~~~~
+
+* Nominating a new core developer;
+* Removing a core developer from the core team;
+* Disbanding the experts team for a given area of interest.
+
+The latter two are votes of no confidence.  Those describe a situation
+where a core developer is forcefully removed from the core team or an
+experts team is forcefully disbanded.  Hopefully those will never have
+to be exercised but they are explicitly mentioned to demonstrate how
+a disfunctional area of interest can be healed.
+
+If a core developer is removed by vote from the core team, they lose
+the ability to interact with the project.  It's up to the Moderators'
+discretion to remove their ability to post on the bug tracker and GitHub
+or just moderate their future behavior on a case-by-case basis.
+
+If the experts team for an area of interest is disbanded, other core
+developers can step up to fill the void at will.  Members of the
+disbanded experts team cannot self-nominate to return.
+
+Voting Mechanics
+----------------
+
+Votes take fourteen calendar days.  The starting date is taken looking at
+the timezone of the person who filed for the motion to vote.  The end
+date is fourteen days later Anywhere-On-Earth.
+
+Dormant core developers as defined in "Key people and their functions"
+above are not counted towards the totals if they abstain.  However, they
+can vote if they choose to do so and that way they count as active.
+Voting is a form of contribution.
+
+Voting is done by a commit to a private repository in the "python"
+organization on GitHub.  The repository is archived and publicized after
+the voting period is over.  The repository's name should start with
+"vote-".
+
+Changes to one's vote during the voting period is allowed.  Peeking
+at other developers' cast votes during the time of the vote is possible.
+
+Every situation requires a different vote percentage:
+
+* PEP rejection by vote requires over 1/3rd of the non-dormant core
+  developer population to explicitly vote to reject.  Note that if
+  more than 1/3rd of core developers decide against a PEP, this means
+  there exists no super-majority of core developers who are in favor
+  of the change.  This strongly suggests the change should not be made
+  in the shape described by the PEP.
+* New core developer nomination requires there to be no votes cast
+  against it.
+* Votes of no confidence require a super-majority of at least 2/3rds of
+  the non-dormant core developer population to explicitly vote in favor
+  of the motion.
+
+
+Omissions
+=========
+
+This document deliberately omits listing possible areas of interest
+within the project.
+
+
+Acknowledgements
+================
+
+Thank you to the authors of PEP 8002 which was a helpful resource in
+shaping this document.
+
+Thank you to Alex Crichton and the Rust team for a governance model
+that was a major inspiration for this document.
 
 
 Copyright