Scikit-learn治理和决策#
本文档的目的是正式化scikit-learn项目使用的治理流程，阐明如何做出决策以及我们社区的各种元素如何相互作用。该文件建立了一个决策结构，考虑到社区所有成员的反馈，并努力寻求共识，同时避免任何僵局。
这是一个任人唯贤、基于共识的社区项目。任何对项目感兴趣的人都可以加入社区，为项目设计做出贡献并参与决策过程。本文件描述了如何进行参与以及如何在项目社区内赚取绩效。
作用和责任#
我们区分贡献者、核心贡献者和技术委员会。他们之间的一个关键区别是他们的投票权：贡献者没有投票权，而其他两个群体都拥有投票权，以及对其角色相关工具的许可。
贡献者#
贡献者是以具体方式为项目做出贡献的社区成员。任何人都可以成为贡献者，贡献可以采取多种形式--不仅仅是代码--详细介绍 contributors guide .成为贡献者没有任何过程：一旦有人以任何方式为项目做出贡献，他们就是贡献者。
核心贡献者#
所有核心贡献者成员都拥有相同的投票权和提名新成员担任以下任何职位的权利。他们的成员在scikit-learn上被表示为组织成员 GitHub organization .
也欢迎他们加入我们的 monthly core contributor meetings .
新成员可以由任何现有成员提名。一旦获得提名，当前核心贡献者将进行投票。对新成员进行投票是该项目私人邮寄列表上进行的少数活动之一。虽然预计大多数选票将是一致通过的，但三分之二多数票就足够了。投票需要至少开放1周。
在过去12个月内没有根据其角色为该项目做出贡献的核心贡献者将被询问是否愿意成为名誉成员并放弃其权利，直到他们再次活跃起来。活跃成员和名誉成员名单（包括他们开始活跃的日期）在scikit-learn网站上公开。积极的核心贡献者有责任发送此类年度提醒电子邮件。
以下团队构成核心贡献者组：
Contributor Experience Team 贡献者体验团队通过帮助对问题进行分类和拉取请求，以及注意人们可能遇到的任何重复模式，并帮助改进项目的这些方面来改善贡献者的体验。
为此，他们在GitHub上拥有标记和关闭问题所需的权限。 Their work 对于改善项目中的沟通并限制问题跟踪器的拥挤至关重要。
Communication Team 沟通团队的成员帮助scikit-learn进行推广和沟通。该团队的目标是提高公众对scikit-learn及其功能和使用以及品牌的认识。
为此，他们可以在各种社交网络上操作scikit-learn帐户并制作材料。他们还拥有对我们的博客存储库和其他相关帐户和平台的所需权利。
Documentation Team 文档团队的成员参与项目的文档等工作。他们还可能参与项目的其他方面，但他们对文档贡献的审查被认为是权威的，并且可以合并此类贡献。
为此，他们有权合并scikit-learn的存储库中的拉取请求。
Maintainers Team 维护者是社区成员，他们通过与社区的持续接触表明他们致力于项目的持续发展。他们已经证明，他们可以放心地维护scikit-learning。作为维护者，贡献者可以通过直接访问项目的存储库来更轻松地继续与项目相关的活动。维护者预计将审查代码贡献、合并批准的拉取请求、投票支持和反对合并拉取请求，并参与决定对API的重大更改。
技术委员会#
技术委员会（TC）成员是维护人员，他们有额外的责任来确保项目的顺利运行。技术合作委员会成员应参与战略规划，并批准对治理模式的修改。技术委员会的目的是从大局的角度确保顺利进行。事实上，影响整个项目的变化需要一个综合分析和一个既明确又知情的共识。如果核心贡献者群体（包括技术委员会成员）未能在规定的时间内达成共识，技术委员会将负责解决问题。过渡委员会的成员由核心捐助者提名。提名将导致不超过一个月的讨论，然后由核心贡献者投票，投票将持续一周。TC成员的投票取决于所有投票的三分之二多数以及所有现任TC成员的简单多数批准。不积极履行TC职责的TC成员预计将辞职。
scikit-learn的技术委员会由以下人员组成 Thomas Fan , Alexandre Gramfort , Olivier Grisel , Adrin Jalali , Andreas Müller , Joel Nothman 和 Gaël Varoquaux .
决策过程#
有关项目未来的决定是通过与社区所有成员的讨论做出的。所有非敏感项目管理讨论都在项目贡献者上进行 mailing list 和 issue tracker .偶尔，敏感讨论会发生在私人列表上。
Scikit-learn使用“寻求共识”的过程来做出决策。该小组试图找到一个核心贡献者没有公开反对的解决方案。在讨论过程中的任何时刻，任何核心贡献者都可以呼吁投票，投票将在呼吁投票后一个月结束。大多数选票必须得到 SLEP .如果没有一个选项可以获得三分之二的选票，该决定将升级到TC，TC将使用寻求共识的方法，如果一个月内无法达成共识，则采用简单多数投票的后备选项。这就是我们以后可以称之为“ the decision making process ".
决定（除了如上添加核心贡献者和TC成员外）根据以下规则做出：
Minor Documentation changes ，如排印错误修复，或增加/更正句子，但不改变
scikit-learn.org着陆页面或“关于”页面：需要维护者+1，不需要维护者-1（懒惰共识），发生在问题或拉取请求页面上。如果维护者不相信其他人会同意，他们应该给其他人“合理的时间”，让他们对拉请求发表意见。Code changes and major documentation changes 两个维护者要求+1，一个维护者不要求-1（懒惰共识），发生在拉请求页面的问题上。
Changes to the API principles and changes to dependencies or supported versions 发生在 改善建议（SLEPs） 并遵循上述决策过程。
Changes to the governance model 遵循中概述的流程 SLEP020 .
如果对懒惰的共识投了一票否决票，提案者可以向社区和维护者提出上诉，并且可以使用上述决策程序批准或拒绝更改。
治理模式变化#
治理模型更改通过增强提案或GitHub拉取请求发生。增强提案将通过” the decision-making process ”上一节描述了。或者，作者可以通过GitHub拉取请求直接提议对治理模型进行更改。从逻辑上讲，作者可以打开起草拉取请求以获取反馈，并跟进新修订的拉取请求以进行投票。一旦作者对拉取请求的状态感到满意，他们就可以在公共邮件列表上呼吁投票。在一个月的投票期间，合并请求不能更改。Pull Request Approval（合并请求批准）将被视为赞成票，而“Request Changes”（请求更改）审核将被视为反对票。如果三分之二的投票是肯定的，那么治理模式的改变就被接受了。
改善建议（SLEPs）#
对于所有投票，提案必须在投票前公开并讨论。此类提案必须是一份合并文件，形式为“Scikit-Learn Enhancement提案”（SLEP），而不是对某个问题的长时间讨论。SLEP必须作为拉取请求提交给 enhancement proposals using the SLEP template. SLEP000 更详细地描述了该过程。