Scikit-learn 治理和决策#

本文档的目的是正式化 scikit-learn 项目使用的治理流程，以阐明决策是如何做出的以及我们社区的各个组成部分是如何互动的。本文档建立了一个决策结构，该结构考虑了来自社区所有成员的反馈，并努力达成共识，同时避免任何僵局。

这是一个基于功绩和共识的社区项目。任何对该项目感兴趣的人都可以加入社区，为项目设计做出贡献并参与决策过程。本文档描述了这种参与是如何发生的以及如何在项目社区中获得功绩。

角色和职责#

我们将贡献者、核心贡献者和技术委员会区分开来。它们之间的关键区别在于投票权：贡献者没有投票权，而其他两个群体都有投票权，以及对与其角色相关的工具的权限。

贡献者#

贡献者是社区成员，他们以具体的方式为项目做出贡献。任何人都可以成为贡献者，贡献可以采取多种形式，不仅仅是代码，如贡献者指南中所述。没有成为贡献者的流程：一旦有人以任何方式为项目做出贡献，他们就是贡献者。

核心贡献者#

所有核心贡献者成员都拥有相同的投票权和提名新成员加入下面列出的任何角色的权利。他们的成员资格被视为 scikit-learn GitHub 组织的组织成员。

他们也欢迎加入我们的每月核心贡献者会议。

新成员可以由任何现有成员提名。一旦他们被提名，现任核心贡献者将进行投票。对新成员的投票是项目私有邮件列表中进行的少数活动之一。虽然预计大多数投票将是一致的，但三分之二的投票多数就足够了。投票需要至少开放一周。

在过去 12 个月内未根据其角色为项目做出贡献的核心贡献者将被问及他们是否希望成为名誉成员并放弃其权利，直到他们再次活跃起来。成员列表（活跃和名誉成员，以及他们成为活跃成员的日期）在 scikit-learn 网站上公开。

以下团队构成核心贡献者群体

贡献者体验团队 贡献者体验团队通过帮助处理问题和拉取请求，以及注意到人们可能难以应对的任何重复模式，并帮助改进项目的这些方面，来改善贡献者的体验。

为此，他们在 github 上拥有必要的权限来标记和关闭问题。他们的工作对于改善项目中的沟通和限制问题跟踪器的拥挤至关重要。
沟通团队 沟通团队成员帮助 scikit-learn 进行外联和沟通。该团队的目标是提高公众对 scikit-learn 的认识，包括其功能和用法，以及品牌推广。

为此，他们可以在各种社交网络上操作 scikit-learn 帐户并制作材料。他们还拥有我们博客存储库和其他相关帐户和平台的必要权利。
文档团队 文档团队成员参与项目的文档，除此之外还有其他事情。他们也可能参与项目的其他方面，但他们对文档贡献的审查被认为是权威的，并且可以合并这些贡献。

为此，他们有权合并 scikit-learn 存储库中的拉取请求。
维护者团队 维护者是社区成员，他们通过持续参与社区证明了他们致力于项目的持续发展。他们已经证明他们可以信赖维护 scikit-learn。成为维护者可以让贡献者通过直接访问项目的存储库，更轻松地继续进行与项目相关的活动。维护者应审查代码贡献、合并已批准的拉取请求、对合并拉取请求进行投票，并参与决定 API 的重大更改。

技术委员会#

技术委员会 (TC) 成员是维护者，他们承担额外的责任来确保项目的顺利运行。TC 成员应参与战略规划，并批准对治理模型的更改。TC 的目的是从宏观角度确保项目的顺利进展。事实上，影响整个项目的更改需要综合分析和明确且知情的共识。如果核心贡献者社区（包括 TC 成员）未能按要求的时间框架达成这种共识，TC 是解决问题的实体。TC 成员资格由核心贡献者提名。提名将导致讨论，讨论时间不能超过一个月，然后由核心贡献者进行投票，投票将持续一周。TC 成员资格投票必须获得所有投票的投票的三分之二多数，以及所有当前 TC 成员的简单多数批准。没有积极参与 TC 职责的 TC 成员应辞职。

scikit-learn 的技术委员会由Thomas Fan、Alexandre Gramfort、Olivier Grisel、Adrin Jalali、Andreas Müller、Joel Nothman 和Gaël Varoquaux 组成。

决策过程#

关于项目未来的决策是通过与社区所有成员的讨论做出的。所有非敏感的项目管理讨论都在项目的贡献者邮件列表和问题跟踪器上进行。偶尔，敏感的讨论会在私人列表中进行。

Scikit-learn 使用“寻求共识”的过程来做出决策。该小组试图找到一个在核心贡献者中没有公开反对意见的解决方案。在讨论的任何时候，任何核心贡献者都可以要求投票，投票将在投票呼吁后一个月结束。大多数投票必须得到SLEP 的支持。如果没有任何选项能够获得三分之二的投票，则该决定将升级到 TC，TC 将反过来使用寻求共识，如果在一个月内无法达成共识，则可以选择简单多数投票。这就是我们以后可能称之为“决策过程”的内容。

除了添加核心贡献者和 TC 成员资格（如上所述）之外，决策是根据以下规则做出的

次要文档更改，例如拼写错误修复或添加/更正句子，但不更改scikit-learn.org 着陆页或“关于”页面：需要维护者的 +1，维护者没有 -1（惰性共识），发生在问题或拉取请求页面上。如果维护者不确定其他人是否会同意，则应给予其他人“合理的时间”来表达他们对拉取请求的意见。
代码更改和主要文档更改需要两个维护者的 +1，维护者没有 -1（惰性共识），发生在问题或拉取请求页面上。
对 API 原则的更改以及对依赖项或支持版本的更改通过增强提案 (SLEPs) 进行，并遵循上述决策过程。
对治理模型的更改遵循SLEP020 中概述的流程。

如果在惰性共识上投下了否决票 -1，则提案者可以向社区和维护者提出上诉，并且可以使用上述决策过程批准或拒绝更改。

治理模型更改#

治理模型更改通过增强提案或 GitHub 拉取请求进行。增强提案将经历上一节中描述的“决策过程”。或者，作者可以通过 GitHub 拉取请求直接向治理模型提出更改。从逻辑上讲，作者可以打开一个草稿拉取请求以征求反馈，然后跟进一个新的修订拉取请求以进行投票。一旦作者对拉取请求的状态感到满意，他们就可以在公共邮件列表中呼吁投票。在为期一个月的投票期间，拉取请求不能更改。拉取请求批准将计为赞成票，而“请求更改”审查将计为反对票。如果三分之二的投票是赞成票，则治理模型更改将被接受。

增强提案 (SLEPs)#

对于所有投票，提案必须在投票前公开发布并进行讨论。这种提案必须是一份综合文件，以“Scikit-Learn 增强提案”（SLEP）的形式出现，而不是在问题上进行长时间的讨论。SLEP 必须作为拉取请求提交到增强提案，使用SLEP 模板。SLEP000 更详细地描述了该过程。