PEP 8002: Add information about Project Jupyter governance (#770)
* Add information about Project Jupyter governance * add content per @pitrou review
This commit is contained in:
Carol Willing
GitHub
parent
3894e01b4a
commit
b930b50071
125
pep-8002.rst
125
pep-8002.rst
|
|
@ -1,7 +1,8 @@
|
|||
PEP: 8002
|
||||
Title: Open Source Governance Survey
|
||||
Author: Barry Warsaw <barry@python.org>, Łukasz Langa <lukasz@python.org>,
|
||||
Antoine Pitrou <solipsis@pitrou.net>, Doug Hellmann <doug@doughellmann.com>
|
||||
Antoine Pitrou <solipsis@pitrou.net>, Doug Hellmann <doug@doughellmann.com>,
|
||||
Carol Willing <willingc@gmail.com>
|
||||
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
|
||||
===========================
|
||||
|
|
|
|||
Loading…
Reference in New Issue