Foundation of New Governance Model

.gitignore

@@ -1,3 +1,7 @@
+# Jupyter
+.ipynb_checkpoints
+default.profraw
+
 # Byte-compiled / optimized / DLL files
 __pycache__/
 *.py[cod]
@@ -57,4 +61,4 @@ docs/_build/
 target/
 
 # Docs
-_build
+_build

bootstrapping_decision_making.md

@@ -0,0 +1,32 @@
+# Bootstrapping Decision Making Bodies
+
+As the new Jupyter governance model is approved and implemented, Jupyter Subprojects will have to establish a formal decision making body. There are a number of challenges associated with this:
+
+- We are moving from an informal model where most Subprojects do not have a formal decision making body, to the formal one described in the Decision Making Guidelines.
+- Most Subprojects do not have a well defined decision making body today.
+- In the new model, there is flexibility about the size of the formal decision making bodies. Each Subproject will need to also determine how large its formal decision making body is.
+- There is a wide range of sizes of Subprojects — some have a few contributors and others have many dozens.
+- We are proposing to establish new Subprojects for certain areas of Project Jupyter, that don’t 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.
+- Our current governance model (informal consensus by an informal group lacking clear boundaries) does not have an established mechanism for decisions like this. We believe it will be very difficult for Subprojects to elect a formal governing body and pick its size using informal consensus.
+- We wish to avoid each Subproject having layers of meta consensus or voting to establish a process for electing their decision making body.
+- We need to take existing Steering Council members into account. There may be Steering Council members that would like to be on the formal decision making body for a Subproject, even though they have not been active on the Suproject for a period of time.
+
+## Proposed framework
+
+We would like to propose the following framework for Subprojects to establish and bootstrap their formal decision making bodies. This framework is not being presented as a set of strict rules, but more as a set of flexible principles that Subprojects can use for this task. The Governance Working Group will be available to meet with all Subprojects to openly discuss how the Subproject can best use and adapt these ideas to their case.
+
+The overall principle of this framework is that of gradual accumulation of the decision making body, rather than bulk election. The process we propose can be briefly outlined as follows:
+
+
+- Each Subproject typically has a core of individuals who have a long history with the Subproject and have made significant contributions to the Subproject (in many cases, they founded the Subproject). There is universal agreement that these people should be on the formal decision making body for the Subproject. An example would be Min for JupyterHub. This initial group can be as small as a single person and keeping it as small as possible ensures this step will be simple. Let’s call the size of this initial group `N0`.
+- Once the initial group or person is established, that group will use the new Decision Making Guidelines to elect the next single member they would like to add to the formal decision making body. At this point, the decision making body would have size `N0+1`.
+- At this point, the `N0+1` people would use the Decision Making Guidelines to elect the next single member to add to the decision make body.
+- This process continues in an inductive manner where at each point, the current `N` people on the decision making body elect the `N+1` person, or choose to stop electing new members.
+
+This framework has the following characteristics:
+
+- 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.
+- In the spirit of Jupyter always seeking to develop multi-stakeholder governance, this bootstrapping process should try to maximize the participation of individuals from multiple organizations. Specifically, they should when possible alternate across organizations to avoid all initial members of the decision making body belonging to a single organization.
+- As explained in the SSC document, there will be a working group with an SSC representative focused on issues of Inclusive Community Development. This representative can be a point of contact to assist with any issue regarding inclusion and participation in the creation of the project decision making bodies.

list_of_subprojects.md

@@ -0,0 +1,67 @@
+# 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 (https://github.com/jupyterhub/jupyterhub)
+- 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)
+- Binder
+  - https://github.com/jupyterhub/binder
+  - https://github.com/jupyterhub/binderhub
+- Jupyter Kernels
+  - jupyter-xeus (https://github.com/jupyter-xeus/)
+  - IPython (https://github.com/ipython/ipython)
+  - IPykernel (https://github.com/ipython/ipykernel)
+- Jupyter Standards
+- Jupyter Foundations
+
+### 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. In the rare situation that a vote is called, the SSC will serve as the voting body and will consult closely with the team. 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)
+- QtConsole (https://github.com/jupyter/qtconsole)
+- ipyparallel (https://github.com/ipython/ipyparallel)
+- 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 Jupyer 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
+  - 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.
+- Jupyter Enterprise
+  - A number of Jupyter repositories pertain to enterprise deployments. 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)

software_steering_council.md

@@ -0,0 +1,53 @@
+# Software Steering Council
+
+## Purpose
+
+The Jupyter Software Steering Council (SSC) has jurisdiction over software-related decisions across Project Jupyter, with a primary focus on coordination across projects and decisions that have impact across many Jupyter Subprojects. It is also a mechanism for representatives of each project to share information and expertise. Technical decisions and processes where the SSC isn't explicitly involved are automatically delegated to the individual projects to manage their day-to-day activities, create new repositories in their orgs, etc., with independence and autonomy.
+
+## Responsibilities
+
+### Sole responsibilities
+
+The SSC is responsible for the following:
+
+- Defining the submission, review, and approval process for Jupyter Enhancement Proposals.
+- Stewarding the JEP process to ensure that it is inclusive and participatory, and solicits feedback from the right stakeholders. As a starting point, [the NumFOCUS DISCOVER Cookbook](https://github.com/numfocus/DISCOVER-Cookbook) may offer some useful starting pointers.
+- Making decisions on JEPs after receiving community feedback (JEPs are the mechanism for elevating any software decision/idea up to the broader Project, while individual Subprojects can make decisions within their scope via their regular mechanisms).
+- Owning, managing and implementing the Jupyter Incubation process (https://github.com/jupyter-incubator).
+- Owning, managing and implementing the Jupyter Attic process (https://github.com/jupyter-attic).
+- Stewarding discussions and activities beyond JEPs that involve cross-cutting concerns, standards, protocols and other architectural issues that impact the entire project.
+- Owning and managing anything related to security vulnerabilities across the project, including the Jupyter security lists, any private security repositories, etc.
+
+### Shared responsibilities with the Board of Directors
+
+The SSC and BoD share the responsibility for:
+
+- Updates or amendments to the [Jupyter Code of Conduct](https://jupyter.org/governance/conduct/code_of_conduct.html).
+- Changing the Jupyter Governance model.
+- Creation of new Jupyter Subprojects.
+- Removal of Subprojects from Jupyter.
+- Designation of working groups that have a non-software focus but that carry a representative to the SSC, for specific topics where this is desired. This includes maintaining a working group on Inclusive Community Development; this group's representative can act as a point of contact on issues of Diversity, Inclusion and Community within the SSC and a bridge to the rest of the working group and the Board of Directors.
+
+## Membership
+
+SSC members are leaders from Jupyter Subprojects that wish to assist the community in sharing information across projects and participate in decision-making that affects many stakeholders in the Jupyter ecosystem. Membership requires active and ongoing participation in the project.
+
+### Member composition
+
+The Software Steering Council is composed of one representative from each of the Jupyter Subprojects. In addition, the SSC may contain members from certain working groups that have been created by the BoD and whose scope has important impact on SSC activities, such as Diversity and Inclusion, Accessibility, and Internationalization.
+
+### Term length
+
+There is no term length for SSC membership, as each Jupyter Subproject is in charge of selecting its own representative. Projects are encouraged to define their own expectations around SSC membership tenure, to share SSC membership responsibilities amongst core team members, and to provide mechanisms for healthy rotation that avoid burnout.
+
+### Selecting SSC members
+
+Each Jupyter Subproject or working group with SSC representation is responsible to nominate a single representative using the Jupyter Decision Making Guidelines.
+
+### Bootstrapping the SSC
+
+The initial Software Steering Council will be created with individuals nominated by each of the major Jupyter Subprojects, as defined by our [official list](list_of_subprojects.md).
+
+## Relationship with the Board of Directors
+
+The SSC exercises autonomy in managing its responsibilities. It takes advising and guidance from the Board of Directors, but does not report to the BoD for any technical decisions. It also works with the Board of Directors to make any decisions that must be made jointly (e.g., changes to governance).

software_subprojects.md

@@ -0,0 +1,31 @@
+# Software Subprojects of Project Jupyter
+
+Software design and development in Project Jupyter is organized into a set of Software Subprojects. These software Subprojects often map onto GitHub repositories/organizations, but that is not strictly required. The lifecycle of Software Subprojects is [described in detail here](newsubprojects.md).
+
+Since Project Jupyter promotes open technical standards and interoperability among components, there is a rich ecosystem of tools developed by third parties that are not under the umbrella of Project Jupyter’s Governance or the Software Steering Council. We strive to maintain open communication with this community, however,this document focuses only on official Jupyter Subprojects.
+
+## Responsibilities of Jupyter Subprojects
+
+Unless the Software Steering Council (SSC) or the Board of Directors says otherwise, Subprojects self-govern as autonomously as possible, while following the overall governance model and processes of Project Jupyter. Specifically, all Subprojects under Jupyter’s governance have the following responsibilities:
+
+- Adhere to the Jupyter Code of Conduct.
+- Adhere to the [Jupyter Decision Making Guidelines and process](decision_making.md).
+- Where applicable, nominate and maintain a single representative to the SSC.
+- Follow the licensing guidelines and practices of the project ([use of the BSD license and copyright header](https://github.com/jupyter/jupyter/blob/master/LICENSE)).
+- Follow Jupyter’s trademark, branding, and intellectual property guidelines.
+- Conduct its activities in a manner that is open, transparent, and inclusive. This includes coordinating with the SSC and the Board of Directors on mechanisms for information flow and updates to the broader community (details of this, project-wide, will be developed as our new governance model is adopted and implemented).
+
+## Incubator Subprojects
+
+Incubator Subprojects are experimental and early-stage efforts where ideas are being explored and developed in the open and under the principles of Jupyter’s governance.  Therefore, Subprojects under incubation have the same responsibilities listed above for official Jupyter projects.
+
+The [Jupyter Incubator GitHub organization](https://github.com/jupyter-incubator) serves as a home for all Incubator Subprojects and has further details on the process to create and approve them. This organization serves as a neutral playing ground for people who can’t easily create their own repositories.
+
+## SSC Representation
+
+Official Jupyter Software Subprojects that have large and active enough teams to have a standalone, formal Decision Making Body will elect and maintain a single representative to the SSC. The decision making body of each such Subproject is free to set term limits or rotate this responsibility as they see fit.
+
+There exist two categories of Subprojects that, while operating under Jupyter’s governance, do not have a dedicated delegate to the SSC:
+
+- There are a number of smaller and/or low-activity Subprojects that don’t have enough active participants to have a standalone decision making body. The SSC itself will be the formal decision making body for these Subprojects when necessary, while otherwise allowing the team to manage its day-to-day activities.
+- Projects in the Jupyter Incubator will only acquire official SSC representation if/once they graduate to official Jupyter Subproject status.