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)，技术委员会将反过来使用寻求共识的方法，如果在一个月内无法达成共识，则可以使用简单多数投票作为后备选项。此后，我们可能会将其称为“决策流程”。

除了添加核心贡献者和上述技术委员会成员之外，决策是根据以下规则做出的：

  • 次要文档更改，例如更正错别字，或添加/更正句子，但不更改scikit-learn.org登录页面或“关于”页面：需要一位维护者的 +1，一位维护者没有 -1（惰性共识），在问题或拉取请求页面上进行。如果维护者不确定其他人是否会同意，则应给予其他人“合理的时间”来表达他们对拉取请求的意见。

  • 代码更改和主要文档更改需要两位维护者的 +1，一位维护者没有 -1（惰性共识），在问题或拉取请求页面上进行。

  • 对 API 原则和依赖项或支持版本的更改是通过增强提案 (SLEP)进行的，并遵循上述决策流程。

  • 对治理模型的更改遵循SLEP020中概述的流程。

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

治理模型更改#

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

增强提案 (SLEP)#

对于所有投票，提案必须在投票前公开提出并讨论过。此类提案必须是经过整合的文档，以“Scikit-Learn 增强提案”(SLEP)的形式出现，而不是在问题上的冗长讨论。SLEP 必须作为拉取请求提交到增强提案，并使用SLEP 模板。SLEP000更详细地描述了此流程。