新子项目流程#
本文档描述了新子项目在 Jupyter 组织内创建或从其他地方迁移至此的过程。有关 Jupyter 社区当前子项目的列表，请参阅子项目列表。
注意
在 jupyter-incubator 组织下进行孵化的流程已过时。其中可能包含指向已归档代码仓库的链接，以及引用旧版 Jupyter 治理模型的措辞。我们计划审查这些语言，并根据 Jupyter 新的运作结构进行更新。
在此期间，如有任何问题或提案，请在 Jupyter 软件指导委员会团队指南中提出 issue。
创建新子项目有两种方式
-
例如，当一个现有子项目的贡献者决定为相关但可分离的代码创建一个新的 Git 代码仓库时
-
例如，当 github.com/jupyter-incubator 中一个项目的贡献者提交一份提案，申请并入某个官方 Jupyter 组织，并获得指导委员会的批准时
例如，当一个第三方项目的贡献者提交一份吸纳提案，并获得指导委员会的批准时
请注意，github.com/jupyter-incubator 中的项目在满足以下标准并通过本文档后面详述的吸纳流程之前，**不被**视为官方支持和维护的子项目。
官方子项目标准#
以下标准将用于评估子项目是否可以并入某个官方 Jupyter 组织。这些标准适用于任何子项目，无论其开发者是谁。子项目应：
拥有一个活跃的开发者社区，为未来发展提供可持续的模式。
拥有一个活跃的用户社区。
采用可靠的软件工程实践，文档和测试托管在适当的技术平台上（例如 Read The Docs 和 Travis）。
展现出持续的增长和发展。
能与其他官方子项目良好集成。
根据此处记录的 Jupyter 治理和贡献模型进行开发。
有明确定义的范围。
使用适当的技术进行打包，如 pip、conda、npm、bower、docker 等。
作为一项通用准则，我们支持改进现有子项目，而不是将相互竞争的子项目吸纳到本项目中。
评估子项目是否能成为官方子项目的最重要问题是：社区和指导委员会是否就我们将以官方身份开发和维护该子项目达成广泛共识？
下面详细介绍创建官方子项目的两种途径。
直接创建子项目#
在某些情况下，指导委员会成员可以立即在主要的 Jupyter 组织中创建新的官方子项目。当新子项目明显属于 Project Jupyter 现有范围、活动和开发的一部分时，将使用此选项。
直接创建子项目的过程是精简且非正式的：指导委员会成员应对子项目的创建达成共识，并将其创建的消息通知主要的 Jupyter 邮件列表。
吸纳现有的外部子项目#
在其他情况下，提议吸纳的子项目可能已经在官方 Jupyter 组织之外作为开源软件存在并开发了一段时间。本节描述了对这些现有外部子项目的吸纳流程。此流程适用于在 jupyter-incubator GitHub 组织下孵化的子项目（见下文）、在其他 GitHub 组织下开发的子项目，或在其他公共场所作为开源软件开发的子项目。
当一个子项目被吸纳后，它将成为 Project Jupyter 官方支持和维护的一部分，并被迁移到本文档开头提到的某个 GitHub 组织中。
吸纳提案#
如果在某个 Jupyter 组织团队内部能够直接就采纳达成共识，并且满足上述标准，那么项目可能会被立即采纳。这种共识可以通过在该组织的 team-compass 代码仓库中创建一个 Issue 来建立。如果需要更多讨论，将使用以下更正式的提案流程：
子项目团队应向 jupyter/enhancement-proposals 代码仓库提交一个拉取请求（pull request），其中包含一份增强提案，建议将该子项目纳入某个主要的 Jupyter 组织。该增强提案应说明该子项目如何满足上述各项标准。
社区将使用该拉取请求讨论吸纳提案。
指导委员会（SC）将通过共识提出建议。
如果 SC 建议吸纳，子项目随后需提交一个拉取请求，将新项目添加到
jupyter/governance代码仓库中的子项目列表中。[1]执行委员会随后必须通过合并或拒绝该拉取请求来做出决定。
时间线： SC 应尽一切努力迅速做出决定。如果提案有积极的讨论和反馈，应让其继续进行并听取各方意见。但为避免因等待所有人投票而造成不必要的延误，应遵循以下准则：
提案提出后，给予一周时间征集潜在的反对意见（当然也欢迎明确表示同意）。如果没有反对意见，则将沉默视为同意。
如果一个月过去后仍存在持续且活跃的分歧，这应被视为项目尚未准备好毕业的强烈信号（如果认为有必要，仍可由 BDFL 做出接受的决定）。
指导委员会可能提出的建议包括：
整合到现有的官方子项目中。
吸纳为新的官方子项目。
进一步进行内部或外部孵化（见下文），并附上团队为未来吸纳可以采取的步骤建议。
拒绝。如果指导委员会认为提议的子项目没有进展或永远不适合被吸纳，将使用此选项。如果一个被拒绝的子项目一直在 jupyter-incubator GitHub 组织下孵化，其代码仓库将在过渡期后从该组织中移除。
吸纳#
当一个现有的外部子项目被吸纳为新的官方子项目时，将采取以下步骤：
代码仓库将被转移到某个主要的 Jupyter GitHub 组织下。
将为该子项目创建一个 GitHub 团队，该子项目团队将拥有对其代码仓库的读/写权限。
团队将向主要的 Jupyter 邮件列表发送一封电子邮件，宣布新子项目的消息。
标准的 Project Jupyter 许可证文件（维护在此治理代码仓库中）将被添加到该代码仓库。
各个文件中的版权声明应更新为我们的 Project Jupyter 许可证中描述的标准格式。
子项目的孵化#
孵化是指子项目最初在官方 Jupyter 组织之外进行开发的过程。对于具有以下特点的新子项目，建议进行孵化：
存在重大的未解决技术问题或不确定性，需要进行探索。
全新的方向、范围或想法，尚未经过社区的审查。
已存在庞大的代码库，但尚不清楚该子项目将如何与 Jupyter 的其余部分集成。
孵化还使得更广泛的社区能够轻松区分出稳定的、官方支持和维护的子项目（在主要的 GitHub 组织中）与新兴的、为未来纳入而正在开发的子项目。
如果对于某个子项目是否适合孵化存在疑问，相关方应直接在主要的 Jupyter 邮件列表上发起讨论，以获取社区和指导委员会的反馈。
在 jupyter-incubator 组织中进行孵化#
如果一个子项目团队从一开始就知道最终希望其子项目成为某个官方 Jupyter 组织的一部分，那么它可以在 jupyter-incubator 组织中进行孵化。
在 jupyter-incubator 组织中进行孵化的目标如下：
贡献者可以快速、轻松地将其代码展示给 Jupyter 社区，同时遵守个人和组织的贡献限制。
贡献者可以与社区和指导委员会合作，尽早并频繁地收集反馈，这将有助于他们制定和完善一个清晰简洁的整合提案。
让社区能够区分官方支持的子项目和社区成员进行的实验性子项目。
孵化器项目的代码仓库管理政策#
项目可能时常希望创建新的代码仓库来探索各种想法。对此的基本政策如下：
如果项目名为
foo，它可以创建名为foo-X的新代码仓库，而无需请求进一步授权。项目可以自行决定是否在更广泛的 Jupyter 渠道上宣布该仓库，如果它认为有足够的兴趣（显然这些仓库仍然是公开的，并对所有人开放参与）。如果项目希望创建一个名为
bar的仓库（这是一个其他人可能感兴趣的顶级名称），它应该在主要的 Jupyter 邮件列表上发帖。提案将进行讨论，前提是，除非有人提出严重反对，否则这些请求将被尽快批准。
孵化提案#
子项目团队可以通过提交孵化提案来启动 jupyter-incubator 的孵化过程。这个过程设计得轻量而快捷：
提议者必须通过向 jupyter-incubator/proposals 代码仓库提交拉取请求来填写一份孵化申请。
提议者必须通过在主要的 Jupyter 邮件列表上发帖向社区宣布其意图。
提议的子项目必须有一位活跃的指导委员会成员作为倡导者。倡导者的角色是将子项目团队介绍给 Jupyter 社区，并帮助他们完成孵化过程。倡导者可以参与子项目的实际开发和设计，但这不是必需的。
孵化提案将由社区讨论，并由指导委员会的共识批准或拒绝。
如果获得批准，提案的拉取请求将被合并。如果被拒绝，它将被关闭。
孵化期#
一旦一个子项目被批准在 jupyter-incubator 组织中孵化，将采取以下步骤：
将在 jupyter-incubator 组织下创建一个 GitHub 代码仓库。
将创建一个 GitHub 团队，拥有对该仓库的读/写权限，包括倡导者。
标准的 Jupyter 许可证文件（维护在此治理代码仓库中）将被添加到新的代码仓库中。
指导委员会的一名成员将在主要的 Jupyter 邮件列表上宣布新孵化的子项目。
孵化期的目标是证明该子项目将发展出一个活跃的开发者和用户社区。孵化没有特定的时间长度要求，但预计大多数子项目将在孵化期内停留至少六个月到一年。
外部孵化#
在 jupyter-incubator 组织之外进行孵化也是可能的。在这种情况下，没有正式的流程。任何个人或组织都可以简单地在自己的个人 GitHub（或其他版本控制系统）仓库上创建一个新项目，并按自己的意愿进行开发。如果这样一个外部创建和孵化的子项目希望成为官方 Jupyter 组织的一部分，则必须满足本文档开头列出的标准，并遵循相同的吸纳流程。