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 将反过来使用寻求共识，如果在一个月内找不到共识，则回退到简单多数投票。我们在此后可能将其称为“决策过程”。
（除上述增加核心贡献者和 TC 成员资格外）决策遵循以下规则
次要文档更改，例如错别字修正，或增加/更正句子，但不对
scikit-learn.org着陆页或“关于”页面进行更改：需要一位维护者的 +1，没有维护者的 -1（懒惰共识），发生在问题或拉取请求页面上。维护者如果对其他人是否会同意不确定，应给予“合理时间”让其他人发表意见。代码更改和主要文档更改 需要两位维护者的 +1，没有维护者的 -1（懒惰共识），发生在问题或拉取请求页面上。
API 原则的更改以及依赖项或受支持版本的更改 通过 增强提案 (SLEPs) 进行，并遵循上述决策过程。
治理模型的更改 遵循 SLEP020 中概述的过程。
如果对懒惰共识投下否决票 -1，提案人可以向社区和维护者提出上诉，更改可以根据上述决策程序批准或拒绝。
治理模型变更#
治理模型变更通过增强提案或 GitHub 拉取请求进行。增强提案将经过上一节描述的“决策过程”。或者，作者可以直接通过 GitHub 拉取请求提议对治理模型进行更改。从操作上讲，作者可以打开一个草稿拉取请求以获取反馈，然后跟进一个新的修订拉取请求进行投票。一旦作者对拉取请求的状态满意，他们就可以在公共邮件列表上发起投票。在一个月的投票期间，拉取请求不能更改。拉取请求批准将被视为赞成票，“请求更改”审查将被视为反对票。如果三分之二的有效票为赞成票，则治理模型更改被接受。
增强提案 (SLEPs)#
对于所有投票，提案必须在投票前公开并进行讨论。此类提案必须是统一的文件，以“Scikit-Learn 增强提案”（SLEP）的形式，而不是问题上的冗长讨论。SLEP 必须作为拉取请求提交到增强提案，并使用SLEP 模板。SLEP000 更详细地描述了该过程。