PEP 8002: Add information about Project Jupyter governance (#770)

* Add information about Project Jupyter governance

* add content per @pitrou review

pep-8002.rst

@@ -1,7 +1,8 @@
 PEP: 8002
 Title: Open Source Governance Survey
 Author: Barry Warsaw <[email protected]>, Łukasz Langa <[email protected]>,
-   Antoine Pitrou <[email protected]>, Doug Hellmann <[email protected]>
+   Antoine Pitrou <[email protected]>, Doug Hellmann <[email protected]>,
+   Carol Willing <[email protected]>
 Status: Active
 Type: Informational
 Content-Type: text/x-rst
@@ -371,6 +372,124 @@ code they deliver allows different teams to have different
 interpretations of the same requirements. For example, there are now
 several teams working on different deployment tools.
 
+
+Jupyter
+=======
+
+The governance structure is documented in the `Main Governance Document
+<https://github.com/jupyter/governance/blob/master/governance.md>`_
+within the `Jupyter Governance repo <https://github.com/jupyter/governance>`_.
+
+The effective governance process grows organically over time as the needs of
+the project evolve. Formal changes to the Governance Document are submitted via
+Pull Request, with an open period for comments. After the open period, a
+Steering Council may call for a vote to ratify the PR changes. Acceptance
+requires a minimum of 80% of the Steering Council to vote and at least 2/3 of
+the vote must be positive. The BDFL can act alone to accept or reject changes
+or override the Steering Council decision; though this would be an extremely
+rare event.
+
+Key people and their functions
+------------------------------
+
+The key people in Jupyter's Governance are the BDFL, Fernando Perez, and the
+Steering Council. Contributors can be given a special status of core contributor.
+Some may also be Institutional Contributors, who are individuals who contribute
+to the project as part of their official duties at an Institutional Partner.
+
+Fernando Perez, the project founder, is the current and first BDFL. The BDFL
+may serve as long as desired. The `BDFL succession plan <https://github.com/jupyter/governance/blob/master/governance.md#bdfl>`_
+is described in the Main Governance Document. In summary, the BDFL may appoint
+the next BDFL. As a courtesy, it is expected that the BDFL will consult with the
+Steering Council. In the event that the BDFL can not appoint a successor, the
+Steering Council will recommend one.
+
+Core contributors are individuals who are given rights, such as commit privileges,
+to act in the best interest of the project within their area of expertise or
+`subproject <https://github.com/jupyter/governance/blob/master/newsubprojects.md>`_.
+An existing core contributor typically recommends someone be given
+core contributor rights by gathering consensus from project leads, who are
+experienced core contributors as listed in the README of the project repo.
+
+To be recommended and invited as a Steering Council member, an individual must
+be a Project Contributor who has produced contributions that are substantial in
+quality and quantity, and sustained over at least one year. Potential Council
+Members are nominated by existing Council members and voted upon by the 
+existing Council after asking if the potential Member is interested and willing
+to serve in that capacity.
+
+Regular decision process
+------------------------
+
+Project Jupyter is made up of a number of GitHub organizations and subprojects
+within those organizations. 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
+release of a subproject.
+
+There is a weekly, public Project-wide meeting that is recorded and posted on
+YouTube. Some larger GitHub organizations, which are subprojects of 
+Project Jupyter, e.g. JupyterLab and JupyterHub, may
+have additional public team meetings on a weekly or monthly schedule. 
+Discussions occur on Gitter, the Jupyter mailing list, and most frequently an
+open issue and/or pull request on GitHub.
+
+Controversial decision process
+------------------------------
+
+The foundations of Project Jupyter's governance are:
+
+* Openness & Transparency
+* Active Contribution
+* Institutional Neutrality
+
+During the everyday project activities, Steering Council members participate in
+all discussions, code review and other project activities as peers with all
+other Contributors and the Community. In these everyday activities, 
+Council Members do not have any special power or privilege through their 
+membership on the Council. However, it is expected that because of the quality
+and quantity of their contributions and their expert knowledge of the 
+Project Software and Services that Council Members will provide useful guidance,
+both technical and in terms of project direction, to potentially less 
+experienced contributors.
+
+For controversial issues, the contributor community works together to refine
+potential solutions, iterate as necessary, and build consensus by sharing
+information and views constructively and openly. The Steering Council may 
+make decisions when regular community discussion doesn’t produce consensus
+on an issue in a reasonable time frame.
+
+Voting
+------
+
+Rarely, if ever, is voting done for technical decisions.
+
+For other Project issues, the Steering Council may call for a vote for a
+decision via a Governance PR or email proposal. Acceptance
+requires a minimum of 80% of the Steering Council to vote and at least 2/3 of
+the vote must be positive. 
+
+The BDFL can act alone to accept or reject changes or override the Steering
+Council decision; though this would be an extremely rare event. As Benevolent,
+the BDFL, in practice chooses to defer that authority to the consensus of the
+community discussion channels and the Steering Council.
+
+Planning releases
+-----------------
+
+Since Project Jupyter has a number of projects, not just a single project, the
+release planning is largely driven by the core contributors of a project.
+
+Changes in the process over time
+--------------------------------
+
+The process has remained consistent over time, and the approach has served us
+well. Moving forward The Project leadership will consist of a BDFL and
+Steering Council. This governance model was a formalization of what
+the Project was doing (prior to 2015 when the Main Governance Document was
+adopted by the Steering Council), rather than a change in direction.
+
+
 Acknowledgements
 ================
 
@@ -380,6 +499,10 @@ core team governs the project.
 Jeremy Stanley, Chris Dent, Julia Kreger, Sean McGinnis, Emmet Hikory,
 and Thierry Carrez contributed to the OpenStack section.
 
+The Project Jupyter Steering Council created the Main Governance Document for
+Project Jupyter, and Carol Willing summarized the key points of that documennt
+for the Jupyter section.
+
 
 Annex 1: Template questions
 ===========================