Foundation of New Governance Model

.gitignore

@@ -1,9 +1,14 @@
+# Jupyter
+.ipynb_checkpoints
+default.profraw
+
 # Byte-compiled / optimized / DLL files
 __pycache__/
 *.py[cod]
 
 # C extensions
 *.so
+*.o
 
 # Distribution / packaging
 .Python
@@ -57,4 +62,4 @@ docs/_build/
 target/
 
 # Docs
-_build
+_build

bootstrapping_decision_making.md

@@ -0,0 +1,34 @@
+# Bootstrapping Decision-Making Bodies
+
+As the new Jupyter governance model is approved and implemented, we are moving from an informal Subproject governance model to a formal model. As part of this process, each Jupyter Subproject will need to establish a formal decision-making body, including deciding its size and who its members are. There are a number of challenges associated with this:
+
+- Most Subprojects do not currently have a well-defined decision process or decision-making body.
+- There is a wide range of Subproject community sizes and activity—some have only a few contributors and infrequent commits, while others have dozens of developers and daily activity.
+- We are proposing to establish new Subprojects for certain areas of Project Jupyter (or combining related areas) that do not have an existing history of informal governance.
+- The new governance model and [decision-making guide](decision_making.md) is designed to support large, highly participatory decision-making bodies. As such, even Subprojects that have a clear decision-making body today may wish to increase the size of that body to include more contributors.
+- We wish to avoid each Subproject having layers of meta consensus or voting to establish very different processes for electing their decision-making body.
+- We wish to involve the current Steering Council in forming Subproject decision-making bodies.
+
+## Proposed framework
+
+We propose the following framework for Subprojects to establish and bootstrap their formal decision-making bodies. This framework is a suggested process and guiding set of principles that can be adapted to a particular Subproject's existing circumstances. The Governance Working Group will be available to meet with any Subproject to openly discuss how the Subproject can best use and adapt these ideas to their existing structure and needs.
+
+The overall principle of this framework is to gradually grow the decision-making body from a trusted, respected, and well-defined group. The process we propose is:
+
+
+1. Jupyter Steering Council members will sign up to each Subproject in which they wish to be on the decision-making body. This forms the initial decision-making body for each Subproject.
+2. The decision-making body uses the new Decision-Making Guidelines and the principles below to decide if the next action should be:
+   A. Electing a single new member to the decision-making body, in which case the process proceeds to step 3, or
+   B. Stopping electing members, in which case the decision-making body is complete and the process ends.
+3. The current decision-making body elects a single new member using the Decision-Making Guidelines and the principles below, thereby increasing the body's size by one, and proceeds to step 2.
+
+The bootstrapping process should observe these principles:
+- To address issues of multi-stakeholder governance, during the process above, successively elected members in step 3 should rotate across different organizations to avoid overrepresentation of a single organization in a stage of the process.
+- Decision-making bodies should be inclusive and as large as necessary to give voice to contributors who are actively working on the Subproject or working group. This should be evaluated in both steps 2 and 3 of the process above.
+
+This process has the following characteristics:
+
+- By seeding each decision-making body from the current Steering Council, we start each process from a clear starting point.
+- By gradually increasing the size of the decision-making body one person at a time, the power implicit in this election process is gradually distributed over a larger group of people.
+- At each stage where the new decision-making body is considering adding a new person, they can also choose to stop electing additional members. This allows the group to decide on the overall size in an organic, gradual manner.
+- At each step, issues of diversity and inclusion of the representative body are considered.

decision_making.md

@@ -0,0 +1,42 @@
+# Decision-Making Guide
+
+This document describes how Jupyter’s governing bodies make decisions. Because individuals often work across multiple decision-making groups, all Jupyter governing bodies are expected to follow this approach.
+
+We seek to honor the principles of collaboration, inclusive participation, and responsive decision making. Some aspects of this decision-making guide are required of all teams. Others are provided as recommendations and are optional. We have clearly noted the optional aspects of decision making below.
+
+Finally, the Jupyter Board of Directors may either intervene, or be called upon by members of a team, in the event that issues arise in the decision-making process. This includes, but is not limited to: process ambiguity, violations of the decision-making process, mitigating circumstances that require process exceptions, etc.
+
+## Required aspects of decision making
+
+The decision-making process is intended to balance broad participation of stakeholders with agility. While the size of decision-making bodies may vary (e.g., software projects can range from a handful to dozens of decision makers), all need to find this balance. The guidelines below cannot fully capture the role of human judgment and discretion.
+
+All official Jupyter projects, working groups, governing bodies, and official initiatives must have a clearly-defined and documented decision-making body. Formally, these decision-making bodies make decisions using consensus seeking with an option to call a vote to move the decision forward. All decisions, whether made by informal consensus or by formal vote, may be revisited; however, if a decision-making body finds itself frequently revisting consensus-based decisions, this should be viewed as an indication that the body's understanding of informal consensus may need to be reviewed.
+
+Depending on the governing body, decisions may be proposed by members of the decision-making body or by a broader group of stakeholders/contributors.
+
+**Informal consensus seeking.** Decision making starts with informal consensus seeking through discussion. The goal of this phase is to refine the proposal, consider alternatives, weigh trade-offs, and attempt to find informal consensus. The legitimacy of the consensus-seeking process is predicated on all stakeholders having their voices heard, so teams must be proactive in providing opportunities for all relevant stakeholders to provide input. If the decision-making body arrives at informal consensus, they may immediately move to document and enact the decision. This is the consensus-seeking phase.
+
+**Calling a vote.** When the discussion matures during the consensus-seeking phase, any member of the decision-making body can call the matter to a vote. When that member (the sponsor) calls the vote, they shall summarize the proposal in its current form for the entire decision-making body. After the proposal is seconded by another member of the decision-making body, members have seven days to vote. The governing body may consider longer voting periods as necessary for special circumstances, or _shorter periods only if all voting members are present_. The decision will be determined by a simple majority of non-blank votes for binary decisions (i.e., approving a proposal) and ranked choice for multi-class decisions (one among many, or several among many). The sponsor may update the proposal at any point during the voting period, in which case the voting period will be reset.
+
+**Voter participation and quorum.** All members of a decision-making body are required to participate in at least 2/3 of formal votes of that decision-making body per calendar year (teams can decide how to account for the specifics of this in low-activity projects, etc.). Members that have not met the 2/3 vote participation threshold for a year will automatically be asked to step down at the end of that year. Those individuals remain eligible to rejoin the decision-making body in the future as they become available to participate at the required level. The quorum for all formal votes will be 50% and a "blank" option will always be included, with the "blank" option counting towards the quorum but not included in totals for calculating results.
+
+**Recording.** Once a decision has been made during the consensus-seeking phase or by a formal vote, the decision-making body will record the decision e.g., in Team Compass issues for decision-making bodies whose workflow is on GitHub or other equivalent and publicly visible mechanisms. 
+
+## Optional aspects of decision making
+
+While the previous section is prescriptive for all Jupyter teams, the following are recommended guidelines rather than mandatory procedures.
+
+- Teams should not call a vote to short-circuit an ongoing discussion that is still productive in terms of exploring ideas and feedback. Votes should be called only when discussion has explored the space and stakeholders have provided input.
+- Teams should proactively solicit input from relevant stakeholders and should not assume that silence is consent without attempting to reach out to those individuals.
+- If you are interested in a decision being made, it is your responsibility to encourage voting member/stakeholder/community participation in the decision-making process. If you cannot get such participation, you may want to hold off on doing any significant work on the matter.
+- Special guidelines for software projects making decisions:
+  - Add a link to this document in your issue and PR templates along with a link to the decision-making body membership (see recommended language below).
+  - Create `seeking consensus`, `vote`, and `decision made` issue labels to make it easy to find issues/PRs where decisions are discussed and resolved.
+  - When a vote is called on GitHub, the sponsor should summarize the decision and paste a checklist of the voting members to use in voting in the top entry (description) of the issue/PR.
+  - When communications (in whatever number of channels) point to a discussion that requires a project-wide decision, and before major implementation work starts, a standalone issue should be opened that summarizes the issue, points to relevant prior discussions, and calls for an explicit vote/decision. This issue should be tightly scoped to the relevant decision only, and include the `vote` label.
+  - When an implementation of a decision appears in a pull request, link to the relevant `vote` issue.
+- Decision-making bodies and those proposing decisions should explicitly distinguish between decisions that are two-way doors (easy to reverse later) and one-way doors (difficult or impossible to reverse later). For one-way doors, teams should carefully weigh alternatives and tradeoffs and take extra care to ensure broad participation and stakeholder input. For two-way doors, teams should feel free to move quickly, without compromising the principles and procedures described herein.
+
+## Language for issue/PR template
+
+Project Jupyter makes decisions using a consensus-seeking model. You can read about this model here (link). The decision-making body for this project is documented here (link).

list_of_subprojects.md

@@ -0,0 +1,71 @@
+# List of Official Jupyter Subprojects
+
+At the highest level, any Github repository under any official Jupyter GitHub organization is either itself an Official Jupyter Subproject, or is part of an Official Jupyter Subproject. All such Subprojects have all of the privileges and responsibilities detailed in the Software Subprojects of Jupyter governance document. Within the Official Jupyter Subproject designation, there are two types of Subprojects: ones with a formal decision-making body and SSC representation, and smaller, less active ones whose decision-making body is the SSC itself. This document enumerates Subprojects of these two types.
+
+### Official Subprojects with SSC representation
+
+The following Jupyter Subprojects have their own formal decision-making body that elects and maintains an SSC representative:
+
+- JupyterLab (https://github.com/jupyterlab/jupyterlab)
+- JupyterHub and Binder 
+  - https://github.com/jupyterhub/jupyterhub
+  - https://github.com/jupyterhub/binder
+  - https://github.com/jupyterhub/binderhub
+- Voilà (https://github.com/voila-dashboards/voila)
+- Jupyter Server (https://github.com/jupyter-server/jupyter_server)
+- Jupyter Widgets (https://github.com/jupyter-widgets)
+- Jupyter Notebook (https://github.com/jupyter/notebook)
+- Jupyter Kernels
+  - jupyter-xeus (https://github.com/jupyter-xeus/)
+  - IPykernel (https://github.com/ipython/ipykernel)
+  - IPython (https://github.com/ipython/ipython)
+- Jupyter Foundations
+- Jupyter Standards
+- Jupyter Enterprise
+- Jupyter Security
+
+### Official Subprojects without SSC representation
+
+The following official Jupyter Subprojects are smaller and less active. As such their formal decision-making body will be the SSC and they will not have an independent SSC delegate. Our expectation is that these smaller teams will basically continue working as they do today, making decisions using the consensus seeking phase of the Jupyter Decision-Making Guidelines. Even though the SSC has decision-making authority over these projects, the SSC delegates all decisions that do not have broad cross-project implications to the Subproject maintainers. In the rare situation that a vote is called, the SSC will serve as the voting body and will consult closely with the Subproject maintainers. If one of these Subprojects grows or becomes more active, the SSC can, at any time, elect a standalone decision-making body for the Subproject, at which point, the Subproject will begin to have an SSC delegate of their own. In all other respects, these Subprojects are full and official Subprojects.
+
+- nbdime (https://github.com/jupyter/nbdime)
+- nbgrader (https://github.com/jupyter/nbgrader)
+- ipyparallel (https://github.com/ipython/ipyparallel)
+- QtConsole (https://github.com/jupyter/qtconsole). Note that QtConsole today is most actively maintained by the Spyder team; as part of this reorganization we will discuss with them whether it's more appropriate to move the project to be fully under their organization.
+- All other repos not listed above and that don't clearly fall into one of the official Subproject GitHub organizations above.
+
+## Notes about Official Jupyter Subprojects
+
+The Official Jupyter Subprojects document proposes a number of changes to how our repositories are organized into official Subprojects and GitHub organizations. This document describes the changes that are being proposed.
+
+- Services
+  - In general Jupyter services such as Binder, nbviewer, and the Jupyter website involve legal, financial, and operational matters. As such, we are proposing that the actual services are managed by working groups that report to the Board of Directors, who can provide the needed support and oversight. For example, if we want to hire full or part time staff to maintain or operate these services, the Board of Directors would be responsible for raising funds, hiring, and managing those staff.
+  - The JupyterHub and Binder teams have a number of unique considerations. Currently all Binder repositories are under the Jupyterhub organizations, but there is a separate (but highly overlapping team) listed as the Binder team. These teams will need to work out if they would like to each have a formal decision-making body with an SSC representative, or if they would like to have a single team. The Governance Working Group will be available to the JupyterHub and Binder teams to help working through these questions.
+  - We propose that the Jupyter website and its repository will be governed by a working group that reports to the Board of Directors.
+  - We propose that the nbviewer service (only the actual live service) be governed by a working group that reports to the Board of Directors. The reusable part of nbviewer contained (https://github.com/jupyter/nbviewer) will be governed by the Jupyter Enterprise Subproject.
+- Jupyter Kernels
+  - To consolidate the project’s work on first-party kernels, we propose to establish a new official Subproject called _Jupyter Kernels_ and create a Github organization named jupyter-kernels for the work of the Subproject. All Xeus repositories (https://github.com/jupyter-xeus) will be moved into this organization. This Subproject will also govern the IPython GitHub organization, which will be left in place (https://github.com/ipython).
+  - A new decision-making body for this organization will be established, and they will elect an SSC delegate.
+- Jupyter Standards
+  - Ultimately, because Jupyter standards are cross-project in nature, they are owned by the SSC. The mechanics of day-to-day management of the JEP repo will be decided by the SSC.
+  - There are a number of repositories that encode project-wide standards and protocols. To consolidate work on these repositories, we propose to establish a new official Subproject called Jupyter Standards and create a Github organization named jupyter-standards for the work of the Subproject. The following repositories will be moved into this organization:
+    - Jupyter Client (https://github.com/jupyter/jupyter_client)
+    - Jupyter Notebook Format (https://github.com/jupyter/nbformat)
+    - Documentation for other specifications maintained by other Subprojects, such as the Jupyter Widgets message specification, or the Jupyter Server REST APIs.
+    - JEPs repo (https://github.com/jupyter/enhancement-proposals).
+- Jupyter Enterprise
+  - A number of Jupyter repositories that address the needs of large-scale deployments (meaning use cases that target organizational rather than individual needs, this term is independent of industrial, corporate or non/for-profit applications). To consolidate work on these repositories, we propose to establish a new official Subproject called _Jupyter Enterprise_ and create a Github organization named jupyter-enterprise for the work of the Subproject. The following repositories will be moved into this organization:
+  - Enterprise Gateway (https://github.com/jupyter/enterprise_gateway)
+  - Kernel Gateway (https://github.com/jupyter/kernel_gateway)
+  - Docker stacks (https://github.com/jupyter/docker-stacks)
+  - Jupyter Notebook Viewer (https://github.com/jupyter/nbviewer)
+- Jupyter Foundations
+  - Jupyter’s software has a number of components that serve as a foundation for many other Subprojects. To consolidate work on these repositories, we propose to establish a new official Subproject called _Jupyter Foundations_ and create a Github organization named jupyter-foundations for the work of the Subproject. The following repositories will be moved into this organization:
+    - nbconvert (https://github.com/jupyter/nbconvert)
+    - Jupyter Core (https://github.com/jupyter/jupyter_core)
+    - Jupyter-packaging (https://github.com/jupyter/jupyter-packaging)
+    - Terminado (https://github.com/jupyter/terminado)
+    - nbclient (https://github.com/jupyter/nbclient)
+    - Telemetry (https://github.com/jupyter/telemetry)
+    - Traitlets (https://github.com/ipython/traitlets)
+    - Jupyter Console (https://github.com/jupyter/jupyter_console)