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:

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.

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 Enterprise

  • Jupyter Foundations