Scikit-learn 的治理和决策制定#
本文档旨在规范 scikit-learn 项目所使用的治理流程，以阐明如何做出决策以及社区中各个元素如何互动。本文档建立了一个决策制定结构，该结构考虑到所有社区成员的反馈，并努力寻求共识，同时避免陷入僵局。
这是一个以英才制、共识为基础的社区项目。任何对项目感兴趣的人都可以加入社区，为项目设计做出贡献，并参与决策制定过程。本文档描述了如何进行这种参与，以及如何在项目社区中赢得认可。
角色与责任#
我们区分贡献者、核心贡献者和技术委员会。它们之间的一个关键区别在于投票权：贡献者没有投票权，而其他两个群体都拥有投票权，并拥有与其角色相关的工具权限。
贡献者#
贡献者是以具体方式为项目做出贡献的社区成员。任何人都可以成为贡献者，贡献的形式有很多种——不仅仅是代码——如贡献者指南中所详述。成为贡献者没有固定的流程：一旦有人以任何方式为项目做出贡献，他们就是贡献者。
核心贡献者#
所有核心贡献者成员都拥有相同的投票权，并有权提名新成员担任以下列出的任何角色。他们的成员身份以 scikit-learn GitHub 组织成员的形式表示。
他们也欢迎加入我们的每月核心贡献者会议。
新成员可以由任何现有成员提名。一旦被提名，将由当前的核心贡献者进行投票。对新成员的投票是在项目的私人邮件列表中进行的少数活动之一。虽然预计大多数投票会全票通过，但三分之二的投出票数多数即可。投票需要开放至少 1 周。
在过去 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 将反过来使用寻求共识，如果在一个月内找不到共识，则使用简单多数投票作为后备选项。我们 hereafter 可能会将此称为“决策制定过程”。
决策（除了如上所述增加核心贡献者和 TC 成员资格之外）根据以下规则制定：
次要代码和文档更改，例如没有修改代码逻辑的小维护更改、错别字修复或添加/更正一句话，但不更改
scikit-learn.org登录页面或“关于”页面：需要一位核心贡献者的 +1，没有核心贡献者的 -1（懒惰共识），发生在问题或拉取请求页面上。如果核心贡献者不确定其他人会同意，他们需要给予其他人“合理的时间”在拉取请求上发表意见。代码更改和主要文档更改需要两位核心贡献者的 +1，没有核心贡献者的 -1（懒惰共识），发生在问题或拉取请求页面上。
API 原则更改以及依赖项或支持版本的更改遵循上述决策制定过程。特别是 API 原则的更改通过增强提案 (SLEPs)支持。支持版本等较小的决策可以在 GitHub 问题或拉取请求上进行。
治理模型更改遵循 SLEP020 中概述的过程。
如果在懒惰共识上投了否决票 -1，提议者可以向社区和维护者上诉，更改可以使用上述决策制定程序批准或拒绝。
治理模型更改#
治理模型更改通过增强提案或 GitHub 拉取请求进行。增强提案将经历上一节中描述的“决策制定过程”。或者，作者可以直接通过 GitHub 拉取请求提议更改治理模型。从逻辑上讲，作者可以打开一个草稿拉取请求以征求反馈，然后跟进一个新的修改后的拉取请求进行投票。一旦作者对拉取请求的状态满意，他们就可以在公共邮件列表上要求进行投票。在一个月的投票期间内，拉取请求不能更改。拉取请求批准将计为赞成票，“请求更改”审查将计为反对票。如果投出票数的三分之二为赞成票，则治理模型更改被接受。
增强提案 (SLEPs)#
对于所有投票，提案必须在投票前公开并讨论。此类提案必须是一个合并的文档，以“Scikit-Learn 增强提案”（SLEP）的形式，而不是对问题的冗长讨论。SLEP 必须作为拉取请求提交给增强提案，并使用SLEP 模板。SLEP000 更详细地描述了该过程。