Scikit-learn 治理与决策制定#
本文档的目的是正式化 scikit-learn 项目所使用的治理流程，明确决策的制定方式以及社区中各元素的互动方式。 本文档建立了一个决策制定结构，该结构考虑了社区所有成员的反馈，并努力寻求共识，同时避免任何僵局。
这是一个精英治理、基于共识的社区项目。任何对项目感兴趣的人都可以加入社区，为项目设计做出贡献并参与决策制定过程。 本文档描述了这种参与的方式以及如何在项目社区中获得声望。
角色与责任#
我们区分贡献者、核心贡献者和技术委员会。它们之间的一个关键区别在于他们的投票权：贡献者没有投票权， 而其他两个群体都有投票权，以及与其角色相关的工具的权限。
贡献者#
贡献者是社区成员，他们以具体的方式为项目做出贡献。任何人都可以成为贡献者，贡献可以采取多种形式——不仅仅是代码—— 如 贡献者指南 中所述。成为贡献者没有特定的流程：一旦某人以任何方式为项目做出贡献，他们就是贡献者。
核心贡献者#
- 所有核心贡献者成员拥有相同的投票权，并有权提议新成员加入以下任何角色。他们的成员身份在 scikit-learn 的
GitHub 组织 中以组织成员的形式表示。
他们也欢迎参加我们的 `每月核心贡献者会议 ` <scikit-learn/administrative> `_.
新成员可以由任何现有成员提名。一旦他们被提名，现有的核心贡献者将进行投票。对新成员的投票是少数几项在项目私人邮件列表上进行的活动之一。虽然大多数投票预计会是一致的，但只要获得三分之二以上的投票就足够了。投票需要至少开放一周。
在过去12个月内未根据其角色为项目做出贡献的核心贡献者将被询问是否希望成为名誉成员并放弃其权利，直到他们再次活跃。成员名单（包括活跃成员和名誉成员及其成为活跃成员的日期）在scikit-learn网站上是公开的。
以下团队组成了核心贡献者群体：
贡献者体验团队 贡献者体验团队通过帮助处理问题和拉取请求的分类，以及注意到人们可能遇到重复模式的任何地方，并帮助改进这些项目的方面，来改善贡献者的体验。
为此，他们在github上拥有必要的权限来标记和关闭问题。:ref:` 他们的工作 <bug_triaging> `对于改善项目中的沟通和限制问题跟踪器的拥挤至关重要。
沟通团队 沟通团队的成员帮助scikit-learn进行外联和沟通。该团队的目标是提高公众对scikit-learn的认知，包括其功能和使用，以及品牌形象。
为此，他们可以操作scikit-learn在各种社交网络上的账户并制作材料。他们还拥有我们博客仓库和其他相关账户和平台的必要权限。
文档团队 文档团队的成员参与项目的文档编写工作，以及其他相关事务。他们可能还参与项目的其他方面，但他们在文档贡献方面的审查被认为是权威的，并且可以合并这些贡献。
为此，他们有权限在scikit-learn的仓库中合并拉取请求。
维护者团队 维护者是社区成员，他们通过与社区持续的互动，展示了他们对项目持续发展的承诺。他们已经证明他们可以被信任，以谨慎的态度维护scikit-learn。成为维护者使得贡献者能够更容易地进行与项目相关的活动，因为他们可以直接访问项目的仓库。维护者负责审查代码贡献，合并已批准的拉取请求，对合并拉取请求进行投票，并参与决定API的主要变更。
技术委员会#
技术委员会（TC）成员是承担额外责任的维护者，以确保项目的顺利运行。TC成员应参与战略规划，并批准治理模型的变更。TC的目的是从宏观角度确保项目的顺利进展。确实，影响整个项目的变更需要综合分析和明确的、知情的共识。在核心贡献者社区（包括TC成员）在规定时间内未能达成这样的共识的情况下，TC是解决问题的实体。TC成员的资格由核心贡献者提名。提名将导致讨论，讨论时间不能超过一个月，然后由核心贡献者进行投票，投票将持续一周。TC成员的投票需要获得所有投票的三分之二多数，以及所有现任TC成员的简单多数批准。TC成员的任期为两年，可以连任。 未积极参与TC职责的成员应主动辞职。
scikit-learn的技术委员会成员包括：:user:` Thomas Fan <thomasjpfan> 、:user: Alexandre Gramfort <agramfort> 、:user: Olivier Grisel <ogrisel> 、:user: Adrin Jalali <adrinjalali> 、:user: Andreas Müller <amueller> 、:user: Joel Nothman <jnothman> 和 :user: Gaël Varoquaux <GaelVaroquaux> ` 。
决策制定过程#
关于项目未来的决策是通过与社区所有成员的讨论来制定的。所有非敏感的项目管理讨论都在项目贡献者的 邮件列表 问题跟踪器 上进行。偶尔，敏感讨论会在一个私人列表中进行。
Scikit-learn采用“寻求共识”的过程来做出决策。小组试图找到一个核心贡献者中没有公开反对意见的解决方案。在讨论过程中的任何时候，任何核心贡献者都可以要求投票，投票将在要求投票的一个月后结束。大多数投票必须得到:ref:` SLEP <slep>`的支持。如果没有任何选项能获得投票的三分之二，决策将升级到TC，TC将通过寻求共识来进行决策，如果一个月内无法达成共识，则采用简单多数投票作为备选方案。这就是我们此后可能称之为“决策制定过程”的内容。
决策（除了增加核心贡献者和TC成员如上所述）是根据以下规则制定的：
小规模文档更改，如拼写错误修正，或句子的新增/更正，但不包括
scikit-learn.org主页或“关于”页面的更改：需要维护者的+1，没有维护者的-1（懒惰共识），在问题或拉取请求页面上进行。维护者应给予“合理时间”让其他人发表他们的意见。
如果他们不自信其他人会同意，可以发起拉取请求。
代码更改和主要文档更改 需要两位维护者的+1，且没有维护者的-1（懒惰共识），在拉取请求页面的议题中进行。
API原则的更改以及依赖项或支持版本的更改 通过 增强提案（SLEPs） 进行，并遵循上述决策过程。
治理模型的更改 遵循 SLEP020 中概述的过程。
如果在懒惰共识中投了否决-1票，提议者可以向社区和维护者申诉，并且可以使用上述决策程序批准或拒绝更改。
治理模型更改#
治理模型更改通过增强提案或GitHub拉取请求进行。增强提案将经历上一节描述的“决策过程”。或者，作者可以直接通过GitHub拉取请求提出对治理模型的更改。从逻辑上讲，作者可以打开一个草稿拉取请求以获取反馈，并跟进一个新的修订拉取请求进行投票。一旦作者对拉取请求的状态感到满意，他们可以在公共邮件列表上发起投票。在一个月的投票期间，拉取请求不能更改。拉取请求批准将计为正面投票，而“请求更改”审查将计为负面投票。如果三分之二的投票是正面的，则治理模型更改被接受。
增强提案（SLEPs）#
对于所有投票，提案必须在投票前公开并讨论。此类提案必须是一个综合文档，形式为“Scikit-Learn增强提案”（SLEP），而不是在某个议题上的长时间讨论。 问题。必须将SLEP作为拉取请求提交到 增强提案 使用 SLEP 模板 。
更详细地描述了这一过程。