scikit-learn · amueller · Feb 25, 2019 · Dec 27, 2018 · Dec 27, 2018 · Dec 28, 2018
diff --git a/doc/about.rst b/doc/about.rst
@@ -33,6 +33,11 @@ in the FAQ.
 
 .. _citing-scikit-learn:
 
+Governance
+----------
+The decision making process and governance structure of scikit-learn is laid
+out in the `governance document <governance>`_.
+
 Citing scikit-learn
 -------------------
 

diff --git a/doc/governance.rst b/doc/governance.rst
@@ -0,0 +1,131 @@
+
+.. _governance:
+
+===========================================
+Scikit-learn governance and decision-making
+===========================================
+
+The purpose of this document is to formalize the governance process used by the
+scikit-learn project, to clarify how decisions are made and how the various
+elements of our community interact.
+This document establishes a decision-making structure that takes into account
+feedback from all members of the community and strives to find consensus, while
+avoiding any deadlocks.
+
+This is a meritocratic, consensus-based community project. Anyone with an
+interest in the project can join the community, contribute to the project
+design and participate in the decision making process. This document describes
+how that participation takes place and how to set about earning merit within
+the project community.
+
+Roles And Responsibilities
+==========================
+
+Contributors
+------------
+Contributors are community members who contribute in concrete ways to the
+project. Anyone can become a contributor, and contributions can take many forms
+– not only code – as detailed in the `contributors guide <contributing>`_.
+
+Core developers
+---------------
+Core developers are community members who have shown that they are dedicated to
+the continued development of the project through ongoing engagement with the
+community. They have shown they can be trusted to maintain Scikit-learn with
+care. Being a core developer allows contributors to more easily carry on
+with their project related activities by giving them direct access to the
+project’s repository and is represented as being an organization member on the
+scikit-learn `GitHub organization <https://github.com/orgs/scikit-learn/people>`_.
+Core developers are expected to review code
+contributions, can merge approved pull requests, can cast votes for and against
+merging a pull-request, and can be involved in deciding major changes to the
+API.
+
+New core developers can be nominated by any existing core developers. Once they
+have been nominated, there will be a vote by the current core developers.
+Voting on new core developers is one of the few activities that takes place on
+the project's private management list. While it is expected that most votes
+will be unanimous, a two-thirds majority of the cast votes is enough. The vote
+needs to be open for at least 1 week.
+
+Core developers that have not contributed to the project (commits or GitHub
+comments) in the past 12 months will be asked if they want to become emeritus
+core developers and recant their commit and voting rights until they become
+active again. The list of core developers, active and emeritus (with dates at
+which they became active) is public on the scikit-learn website.
+
+Technical Committee
+-------------------
+The Technical Committee (TC) members are core developers who have additional
+responsibilities to ensure the smooth running of the project. TC members are expected to
+participate in strategic planning, and approve changes to the governance model.
+The purpose of the TC is to ensure a smooth progress from the big-picture
+perspective. Indeed changes that impact the full project require a synthetic
+analysis and a consensus that is both explicit and informed. In cases that the
+core developer community (which includes the TC members) fails to reach such a
+consensus in the required time frame, the TC is the entity to resolve the
+issue.
+Membership of the TC is by nomination by a core developer. A nomination will
+result in discussion which cannot take more than a month and then a vote by
+the core developers which will stay open for a week. TC membership votes are
+subject to a two-third majority of all cast votes as well as a simple majority
+approval of all the current TC members. TC members who do not actively engage
+with the TC duties are expected to resign.
+
+The initial Technical Committee of scikit-learn consists of :user:`Alexandre Gramfort <agramfort>`,
+:user:`Olivier Grisel <ogrisel>`, :user:`Andreas Müller <amueller>`, :user:`Joel Nothman <jnothman>`,
+:user:`Hanmin Qin <qinhanmin2014>`, :user:`Gaël Varoquaux <GaelVaroquaux>`, and
+:user:`Roman Yurchak <rth>`.
+
+Decision Making Process
+=======================
+Decisions about the future of the project are made through discussion with all
+members of the community. All non-sensitive project management discussion takes
+place on the project contributors’ `mailing list <mailto:[email protected]>`_
+and the `issue tracker <https://github.com/scikit-learn/scikit-learn/issues>`_.
+Occasionally, sensitive discussion occurs on a private list.
+
+Scikit-learn uses a "consensus seeking" process for making decisions. The group
+tries to find a resolution that has no open objections among core developers.
+At any point during the discussion, any core-developer can call for a vote, which will
+conclude one month from the call for the vote. Any vote must be backed by a
+`SLEP <slep>`. If no option can gather two thirds of the votes cast, the
+decision is escalated to the TC, which in turn will use consensus seeking with
+the fallback option of a simple majority vote if no consensus can be found
+within a month. This is what we hereafter may refer to as “the decision making
+process”.
+
+Decisions (in addition to adding core developers and TC membership as above)
+are made according to the following rules:
+
+* **Minor Documentation changes**, such as typo fixes, or addition / correction of a
+  sentence, but no change of the scikit-learn.org landing page or the “about”
+  page: Requires +1 by a core developer, no -1 by a core developer (lazy
+  consensus), happens on the issue or pull request page. Core developers are
+  expected to give “reasonable time” to others to give their opinion on the pull
+  request if they’re not confident others would agree.
+
+* **Code changes and major documentation changes**
+  require +1 by two core developers, no -1 by a core developer (lazy
+  consensus), happens on the issue of pull-request page.
+
+* **Changes to the API principles and changes to dependencies or supported
+  versions** happen via a :ref:`slep` and follows the decision-making process outlined above. 
+
+* **Changes to the governance model** use the same decision process outlined above.
+
+
+If a veto -1 vote is cast on a lazy consensus, the proposer can appeal to the
+community and core developers and the change can be approved or rejected using
+the decision making procedure outlined above.
+
+.. _slep:
+
+Enhancement proposals (SLEPs)
+==============================
+For all votes, a proposal must have been made public and discussed before the
+vote. Such proposal must be a consolidated document, in the form of a
+‘Scikit-Learn Enhancement Proposal’ (SLEP), rather than a long discussion on an
+issue. A SLEP must be submitted as a pull-request to
+`scikit-learn/enhancement_proposals <https://github.com/scikit-learn/enhancement_proposals/>`_
+using the `SLEP template <https://github.com/scikit-learn/enhancement_proposals/blob/master/slep_template.rst>`_.