Jupyter 官方子项目列表

Jupyter 官方子项目列表#

Jupyter 软件开发在软件子项目中进行。在 Jupyter 官方子项目的范畴内，有两种类型的子项目：一种拥有正式的子项目委员会和 SSC 代表，另一种是规模较小、活跃度较低的子项目，其子项目委员会就是 SSC 本身。本文档将列举这两种类型的子项目。

有 SSC 代表的官方子项目#

以下 Jupyter 子项目拥有自己正式的子项目委员会，该委员会选举并维护一名 SSC 代表。

没有 SSC 代表的官方子项目#

以下官方 Jupyter 子项目规模较小且活跃度较低。因此，其正式的子项目委员会将是 SSC，并且它们不会有独立的 SSC 代表。我们期望这些较小的团队能基本维持现状，遵循 Jupyter 决策指南中寻求共识的阶段来做决策。尽管 SSC 对这些项目拥有决策权，但 SSC 会将所有不涉及广泛跨项目影响的决策授权给子项目维护者。在极少数需要投票的情况下，SSC 将作为投票机构，并与子项目维护者密切协商。如果这些子项目中的某一个发展壮大或变得更加活跃，SSC 可以随时为该子项目选举一个独立的委员会，届时该子项目将开始拥有自己的 SSC 代表。在所有其他方面，这些子项目都是完整且正式的子项目。

关于 Jupyter 官方子项目的说明#

“Jupyter 官方子项目”这份文件提出了一系列关于如何将我们的代码仓库组织成官方子项目和 GitHub 组织的变更。本文档描述了这些提议的变更。

  • 服务

    • 通常，像 Binder、nbviewer 和 Jupyter 网站这样的 Jupyter 服务会涉及法律、财务和运营事务。因此，我们提议由向执行委员会（Executive Council）汇报的工作组来管理这些实际的服务，执行委员会可以提供所需的支持和监督。例如，如果我们想聘请全职或兼职人员来维护或运营这些服务，执行委员会将负责筹集资金、招聘和管理这些人员。

    • JupyterHub 和 Binder 团队有一些独特的考虑因素。目前，所有 Binder 代码仓库都在 Jupyterhub 组织下，但有一个独立（但高度重叠）的团队被列为 Binder 团队。这些团队需要商定是各自拥有一个正式的子项目委员会和一名 SSC 代表，还是合并成一个团队。治理工作组将为 JupyterHub 和 Binder 团队提供帮助，以解决这些问题。

    • 我们提议 Jupyter 网站及其代码仓库由一个向执行委员会汇报的工作组来治理。

    • 我们提议 nbviewer 服务（仅指实际的在线服务）由一个向执行委员会汇报的工作组来治理。nbviewer 的可复用部分（位于 jupyter/nbviewer）将成为一个没有 SSC 代表的 Jupyter 官方子项目，如上所述。

  • Jupyter Kernels

    • 为了整合项目在第一方内核上的工作，我们提议建立一个名为 *Jupyter Kernels* 的新官方子项目，并创建一个名为 jupyter-kernels 的 GitHub 组织来承载该子项目的工作。所有 Xeus 代码仓库（jupyter-xeus）将被移至该组织。该子项目还将治理 IPython GitHub 组织，该组织将保持原位（ipython）。

    • 将为该组织建立一个新的子项目委员会，他们将选举一名 SSC 代表。

  • Jupyter 基础与标准

    • 最终，由于 Jupyter 标准具有跨项目的性质，它们归 SSC 所有。JEP 仓库的日常管理机制将由 SSC 决定。

    • 有许多代码仓库包含了项目范围内的标准和协议。为了整合这些仓库的工作，我们提议建立一个名为“Jupyter Standards”的新官方子项目，并创建一个名为 jupyter-standards 的 GitHub 组织来承载该子项目的工作。以下代码仓库将被移至该组织：

    • Jupyter 的软件中有许多组件是其他众多子项目的基础。为了整合这些仓库的工作，我们提议建立一个名为 *Jupyter Foundations* 的新官方子项目，并创建一个名为 jupyter-foundations 的 GitHub 组织来承载该子项目的工作。以下代码仓库将被移至该组织：

目录