Project Jupyter 之前的治理#
注意
在 2022 年 12 月之前，Project Jupyter 采用的是基于终身仁慈独裁者 (BDFL) 和指导委员会的治理模式，具体如本文档所述。
此文档的正式版本，以及下文治理部分定义的角色中的个人和机构列表，包含在项目治理仓库中：
项目#
Jupyter/IPython 项目（以下简称“本项目”）是一个隶属于 501c3 NumFOCUS 基金会的开源软件项目。本项目的目标是开发开源软件，并为可复现、探索性和交互式计算部署开放的公共网站与服务。本项目开发的软件在 BSD（或类似）开源许可下发布，其开发过程公开，并托管在公共 GitHub 仓库中，分别位于 IPython GitHub 组织 和 Jupyter GitHub 组织 下。项目软件的例子包括 IPython Notebook、IPython Terminal、IPython.parallel、Jupyter Hub 等。本项目运行的服务包括托管在 jupyter.org 或 ipython.org 域名下的公共网站和网络服务。项目服务的例子包括 Jupyter 和 IPython 网站（https://jupyter.org.cn 和 https://ipython.pythonlang.cn）、nbviewer（https://nbviewer.ipython.org）以及 Jupyter coLaboratory（https://colaboratory.jupyter.org）。
本项目由一个分布式开发者团队开发，他们被称为贡献者。贡献者是为项目的一个或多个仓库贡献了代码、文档、设计或其他工作的个人。任何人都可以成为贡献者。贡献者可以隶属于任何法律实体，也可以不隶属于任何实体。贡献者通过提交、审查和讨论 GitHub 的拉取请求 (Pull Requests) 和问题 (Issues)，以及参与 GitHub、Google+、Hackpad、Gitter 聊天室和邮件列表上开放和公开的项目讨论来参与项目。项目参与的基础是开放和透明。
以下是当前 IPython 主仓库的贡献者列表：
Jupyter 和 IPython 项目的其他仓库日志中也列出了许多其他贡献者。
项目社区由项目的所有贡献者和用户组成。贡献者代表更广泛的项目社区工作并对其负责，我们努力将贡献者和用户之间的壁垒降到最低。
本项目正式隶属于 501c3 NumFOCUS 基金会（https://numfocus.org），该基金会作为其财政赞助方，可以持有项目商标和其他知识产权，帮助管理项目捐赠，并作为上级法律实体。NumFOCUS 是唯一与项目有正式关系的法律实体（参见下文的机构合作伙伴部分）。
治理#
本节描述了本项目的治理和领导模式。
项目治理的基础是：
开放与透明
积极贡献
机构中立
传统上，项目领导由一位终身仁慈独裁者 (BDFL, Fernando Perez) 和一部分被称为核心开发者的贡献者提供。这些核心开发者因其积极且持续的贡献而被授予对项目 GitHub 仓库的“提交权限”。通常，所有项目决策都通过核心开发者之间的共识，并征求社区的意见来做出。BDFL 可以（但很少选择）否决核心开发者的决定并就某事项做出最终决定。
虽然这种方法一直很有效，但随着项目的发展，面临更多的法律和财务决策，以及与其他机构的互动，我们认为需要一个更正式的治理模式。未来，项目领导层将由一位 BDFL 和一个指导委员会组成。我们将此治理模式视为对我们已在做的事情的正式化，而不是方向上的改变。
终身仁慈独裁者 (BDFL)#
本项目将有一位终身仁慈独裁者（BDFL, Benevolent Dictator for Life），目前是 Fernando Perez。作为“独裁者”，BDFL 有权为本项目做出所有最终决定。作为“仁慈的”独裁者，BDFL 在实践中选择将该权力下放给社区讨论渠道和指导委员会（见下文）的共识。我们期望并且过去的情况也表明，BDFL 很少会行使其最终决定权。由于很少使用，我们将 BDFL 的最终决定权称为“特殊”或“否决”投票。当 BDFL 行使否决权时，通常发生在指导委员会陷入僵局，或者指导委员会请求 BDFL 就特定事项做出决定的情况下。为确保 BDFL 的仁慈性，本项目鼓励持不同意见者在该 BDFL 所采取的整体方向上创建分支 (fork)。BDFL 是指导委员会（见下文）的主席，并可酌情将其在特定决策或一系列决策上的权力委托给任何其他委员会成员。
BDFL 可以指定其继任者，但期望在做出此决定时会咨询指导委员会。如果 BDFL 无法指定继任者，指导委员会将向 NumFOCUS 主理事会提出一个或多个建议。虽然指导委员会和 NumFOCUS 主理事会将在 BDFL 的选举过程中密切合作，但最终决定将由 NumFOCUS 主理事会做出。
指导委员会#
本项目将设立一个指导委员会，由那些在质量和数量上做出了重大贡献，且持续贡献至少一年的项目贡献者组成。委员会的总体职责是通过与 BDFL 合作并听取社区意见，确保项目在技术上和社区层面上的长期健康发展。
在项目的日常活动中，委员会成员与所有其他贡献者和社区成员一样，以平等的身份参与所有讨论、代码审查和其他项目活动。在这些日常活动中，委员会成员不因其委员会成员身份而拥有任何特殊权力或特权。然而，由于他们贡献的质量和数量，以及他们对项目软件和服务的专业知识，我们期望委员会成员能为可能经验较少的贡献者提供有益的指导，无论是在技术上还是在项目方向上。
指导委员会及其成员在某些情况下扮演特殊角色。特别是，委员会可以：
就项目的总体范围、愿景和方向做出决策。
就与其他组织或个人的战略合作做出决策。
就具体的技术问题、功能、错误和拉取请求做出决策。他们是指导代码审查过程和合并拉取请求的主要机制。
就本项目运行的服务做出决策，并为项目和社区的利益管理这些服务。
当常规的社区讨论在合理时间内未能就某个问题达成共识时做出决策。
委员会成员资格#
要获得成为指导委员会成员的资格，个人必须是项目贡献者，其贡献在质量和数量上都必须是重大的，并且持续至少一年。潜在的委员会成员由现任委员会成员提名，并由现任委员会投票决定。根据成功的投票结果，新当选的成员将被邀请担任该职位。委员会最初将由截至 2014 年底在过去一年中非常活跃的现有核心开发者组成。
在考虑潜在成员时，委员会将全面审视候选人的贡献。这包括但不限于代码、代码审查、基础设施工作、邮件列表和聊天参与、社区帮助/建设、教育和推广、设计工作等。我们刻意不设定任意的量化指标（如“在此仓库中有 100 次提交”），以避免鼓励那些为了迎合指标而非项目整体福祉的行为。我们希望鼓励团队中拥有多样化的背景、观点和才能，这就是为什么我们明确规定代码不是评估委员会成员资格的唯一标准。
如果一名委员会成员在项目中连续一年不活跃，他们将被考虑从委员会中除名。在除名前，BDFL 会联系不活跃的成员，询问他们是否计划恢复积极参与。如果他们不打算恢复，经过委员会投票后将立即被除名。如果他们计划很快恢复积极参与，将给予一年的宽限期。如果他们在该期限内没有恢复积极参与，将通过委员会投票除名，不再有宽限期。所有前委员会成员将来随时都可以像其他任何项目贡献者一样被再次考虑成为成员。退休的委员会成员将在项目网站上列出，以表彰他们在委员会活跃的时期。
如果现任成员（BDFL 除外）被认为对项目的福祉造成积极损害，并且沟通和冲突解决的尝试失败，委员会有权将其驱逐。
利益冲突#
我们预计 BDFL 和委员会成员将在各种公司、大学和非营利组织中任职。因此，成员可能会有利益冲突。此类利益冲突包括但不限于：
可能影响其在本项目工作的项目外的经济利益，如投资、雇佣或承包工作。
接触其雇主的专有信息，这些信息可能泄露到他们在项目中的工作中。
个人从项目资源中私下获利，而项目没有收益或遭受损失的情况。
包括 BDFL 在内的所有委员会成员，都应向委员会其他成员披露他们可能存在的任何利益冲突。在特定问题上有利益冲突的成员可以参与委员会关于该问题的讨论，但必须回避对该问题的投票。如果 BDFL 在特定决策中回避，他们将为该决策指定一位临时代替者。
委员会的私密通信#
除非有特殊要求，所有委员会的讨论和活动都将是公开的，并与项目贡献者和社区合作进行。委员会将有一个私密邮件列表，该列表将谨慎使用，且仅在特定事项需要保密时使用。当需要私密通信和决策时，委员会将尽力在删除不应公开发布到互联网上的个人/私密/敏感信息后，向社区总结这些内容。
小组委员会#
委员会可以创建小组委员会，为项目的特定方面提供领导和指导。与整个委员会一样，小组委员会应以公开和透明的方式开展业务，除非有特殊的保密要求。小组委员会的私密通信应在委员会的主要私密邮件列表上进行，除非有特殊要求。
问题：如果 BDFL 不在某个小组委员会中，他们是否仍然拥有否决权？
建议：他们有否决权，但应指定一名代表在大多数时候扮演该角色，只有当委员会不同意该代表的决定且团队内部无法达成解决方案时，才寻求 BDFL 的明确干预。这与 BDFL 为特定决策（或回避情况）指定代表不同，后者是 BDFL 将其权力完全移交给他人。这更像是 Linus Torvalds 在其“副手”模型中使用的模式。
NumFOCUS 小组委员会#
委员会将维持一个职能范围狭窄的小组委员会，以管理其与 NumFOCUS 的互动。
NumFOCUS 小组委员会由 5 人组成，负责管理通过 NumFOCUS 获得的项目资金。预计这些资金的使用方式将符合 NumFOCUS 的非营利使命以及由全体委员会决定的项目方向。
该小组委员会不得就项目的方向、范围或技术方向做出决策。
该小组委员会将有 5 名成员，其中 4 名为现任委员会成员，1 名为指导委员会外部人员。小组委员会成员中，向同一个人汇报工作（通过雇佣或承包关系）的人数不得超过 2 人（包括汇报对象本人，即汇报对象 + 1 人是上限）。这可以避免有效多数票掌握在一人手中的情况。
机构合作伙伴与资金#
BDFL 和指导委员会是项目的主要领导层。没有任何外部机构、个人或法律实体有能力拥有、控制、篡夺或影响项目，除非通过作为贡献者和委员会成员参与项目。然而，由于机构是项目的主要资金来源，正式承认机构在项目中的参与非常重要。这些机构就是机构合作伙伴。
机构贡献者是指任何作为机构合作伙伴官方职责一部分为项目做出贡献的个人项目贡献者。同样，机构委员会成员是指任何作为机构合作伙伴官方职责一部分为项目做出贡献的项目指导委员会成员。
根据这些定义，机构合作伙伴是指在美国或其他地方任何雇佣了至少一名机构贡献者或机构委员会成员的受承认的法律实体。机构合作伙伴可以是营利性或非营利性实体。
机构通过雇佣作为其官方职责一部分积极为本项目做出贡献的个人，从而有资格成为机构合作伙伴。换句话说，机构合作伙伴影响项目的唯一方式是，在与社区其他贡献者和委员会成员平等的条件下，积极参与项目的开放式开发。仅仅在机构环境中使用 Jupyter/IPython 软件或服务并不能使一个实体成为机构合作伙伴。财务捐赠也不能使一个实体成为机构合作伙伴。一旦一个机构有资格成为机构合作伙伴，指导委员会必须提名并批准该合作关系。
如果一个现有的机构合作伙伴不再有贡献的员工，他们将获得一年的宽限期，以便其他员工开始做出贡献。
机构合作伙伴可以通过任何合法途径为其在本项目上的工作寻求资金。这可能涉及非营利组织向私人基金会和捐赠者筹款，或营利性公司利用项目软件和服务构建专有产品和服务。机构合作伙伴为参与本项目而获得的资金称为机构资金。然而，机构合作伙伴获得的任何资金都不能凌驾于项目 BDFL 和指导委员会之上。如果一个合作伙伴有资金进行 Jupyter/IPython 相关工作，而委员会决定不将该工作作为项目的一部分，该合作伙伴可以自行开展。但在这种情况下，该合作伙伴的工作部分将不属于 Jupyter/IPython 的范畴，也不能以暗示存在正式关系的方式使用项目商标。
为了表彰机构的贡献，机构合作伙伴分为两个级别，并享有相关权益：
第一梯队 = 拥有至少一名机构委员会成员的机构
在 Jupyter/IPython 网站、演讲和 T 恤衫上予以鸣谢。
能够在 Jupyter/IPython 网站、演讲和 T 恤衫上鸣谢其自身的资金来源。
可以无限制地参加在（计划的）年度 Jupyter 项目务虚会期间举行的年度机构合作伙伴研讨会。这允许机构合作伙伴邀请任意数量的自家员工、资金来源方和合作者，即使他们不是项目贡献者或委员会成员。
能够通过其委员会成员的参与来影响项目。
委员会成员受邀参加半年一次的 Jupyter/IPython 开发者会议。
第二梯队 = 拥有至少一名机构贡献者的机构
享有与第一梯队合作伙伴相同的权益，但是：
只有机构贡献者受邀参加机构合作伙伴研讨会和半年一次的 Jupyter/IPython 开发者会议。
更改治理文件#
对治理文件的更改通过向本项目的治理文件 GitHub 仓库 jupyter/governance 提交 GitHub 拉取请求 (pull request) 来进行。该过程分为两个阶段：
讨论阶段 从提交者首次打开拉取请求时开始。在此期间，拉取请求必须处于草稿状态。拉取请求会根据公众的评论和审查进行完善，目标是在社区中达成共识。
当拉取请求的作者认为已经获得了足够的反馈和迭代时，可以发起投票。这通过将拉取请求从草稿状态转为活跃状态来触发。此操作将启动投票阶段。
投票阶段 从拉取请求进入活跃状态时开始。拉取请求中提议的更改将被冻结，在投票开始后不得进行实质性修改。在投票阶段，指导委员会投票决定是批准更改并合并拉取请求（接受提议的更改），还是关闭拉取请求而不合并（拒绝提议的更改）。
所有投票的期限为投票阶段开始后的 4 周。在 4 周结束时，如果 2/3 的票数表示赞成（票数的小数部分向上取整），则提案通过；否则提案被拒绝，拉取请求被关闭。在 4 周期限之前，如果至少 80% 的指导委员会成员已投票，且 2/3 的票数表示赞成（票数的小数部分向上取整），则提案通过。由于 BDFL 在本项目中拥有最终决定权，BDFL 有权单独行动，接受或拒绝更改，或否决指导委员会的决定。