scikit-learn 治理与决策机制解析：角色分工、共识投票与 SLEP 提案流程

本文基于仓库中的 治理文档 系统讲解 scikit-learn 项目的治理结构：从贡献者、核心贡献者到技术委员会（TC）的三级角色体系、基于共识寻求（consensus seeking）与惰性共识（lazy consensus）的分级决策规则，以及 SLEP（Scikit-Learn Enhancement Proposal）增强提案机制。读完后，你将能够准确理解 scikit-learn 中“谁有投票权、一次变更需要多少票才能合并、API 级变更为什么必须走 SLEP”，并知道如何在仓库中找到各团队的成员名单与配套制度文档。

1. 治理文档的定位：把决策过程制度化

governance.rst 开篇明确了自身的目的：形式化（formalize）scikit-learn 的治理过程，澄清决策是如何做出的、社区各要素如何交互，并建立一个既吸纳全体成员反馈、力求达成共识、又能避免死锁（deadlock）的决策结构。

文档对项目性质的定性是：这是一个功绩制（meritocratic）、基于共识（consensus-based）的社区项目。任何对项目有兴趣的人都可以加入社区、参与项目设计并进入决策过程；该文档描述的正是“如何参与”以及“如何在一个项目社区中赢得功绩（merit）”。

这份文档在仓库中并非孤立存在，它与项目文档体系相互引用：

• doc/index.rst.template 的导航中提供 “Governance” 入口（第 23 行）；
• doc/about.rst 中说明“scikit-learn 的决策过程与治理结构（角色与职责）记载于治理文档”（第 25 行）；
• doc/developers/contributing.rst 的贡献指南在开头即引导读者参考该治理文档（第 31–32 行）。

2. 角色与职责：三级贡献者体系

治理文档区分了三类角色：贡献者（Contributors）、核心贡献者（Core Contributors）、技术委员会（Technical Committee）。三者之间的关键区别在于投票权：贡献者没有投票权，而后两组不仅拥有投票权，还持有与其角色相关的工具权限。

2.1 贡献者（Contributors）

贡献者是以具体方式为项目做出贡献的社区成员。要点有三：

1. 任何人都可以成为贡献者，贡献形式多样，不仅限于代码——具体形式见 doc/developers/contributing.rst 贡献指南；
2. 成为贡献者没有流程：一旦以某种方式向项目做出贡献，就已是贡献者；
3. 贡献者没有投票权，但所有决策的讨论环节都面向全体社区成员开放（见第 3 节）。

仓库根目录的 CONTRIBUTING.md 进一步列举了贡献途径：改进文档、改进/分类/调查 issue、审查他人 PR、报告自己遇到的问题、为相关 issue 点赞、传播项目等，并强调所有渠道的沟通都应遵守 CODE_OF_CONDUCT.md。

2.2 核心贡献者（Core Contributors）

核心贡献者享有统一的投票权，并有权提名新成员进入下方列出的各个角色。其成员身份体现为 scikit-learn GitHub 组织的 organization member；他们也受邀参加每月的核心贡献者会议（monthly core contributor meetings）。

新成员提名与投票规则（原文档第 48–53 行）：

• 任何现有成员都可以提名新成员；
• 提名后由当前核心贡献者投票。这是少数在项目私有邮件列表上进行的活动之一；
• 尽管预期多数投票会一致通过，但所投有效票的三分之二多数（two-thirds majority of the cast votes）即可通过；
• 投票必须开放至少 1 周。

12 个月不活跃机制（原文档第 55–60 行）：过去 12 个月未按其角色对项目做出贡献的核心贡献者，会被询问是否愿意转为荣誉成员（emeritus），并暂时放弃其权利，直到重新活跃。成员名单（含活跃与荣誉成员，以及各自转为活跃的时间）在 scikit-learn 网站上公开；由活跃核心贡献者负责发出年度提醒邮件。

核心贡献者由四个团队构成，各自的职责与权限如下：

团队	职责	关键权限
Contributor Experience Team（贡献者体验团队）	通过协助 issue 与 PR 的分类（triage）改善贡献者体验，识别贡献者反复受阻的重复模式并推动改进	在 GitHub 上打标签、关闭 issue 的权限；其工作详见 doc/developers/bug_triaging.rst，对项目沟通质量、防止 issue 追踪器过载至关重要
Communication Team（传播团队）	负责 scikit-learn 的外联与传播，提升公众对项目功能、用法以及品牌的认知	可运营 scikit-learn 在各社交网络的账号、制作材料，并持有博客仓库及其他相关账号、平台的权限
Documentation Team（文档团队）	主要参与项目文档工作，也可能参与项目其他方面；其对文档贡献的评审具有权威性，可直接合并此类贡献	持有 scikit-learn 仓库中合并 PR 的权限
Maintainers Team（维护者团队）	通过持续参与社区、展现出对项目长期开发投入的成员；维护者被证明能够谨慎地维护 scikit-learn。直接仓库访问使其更顺畅地推进项目相关工作	预期职责包括：审查代码贡献、合并已批准的 PR、就 PR 合并投赞成或反对票、参与 API 重大变更的决策

成员名单在仓库中的落地：上述四个团队的公开名单以独立 RST 文件形式存放于 doc/ 目录，包括 doc/maintainers.rst、doc/contributor_experience_team.rst、doc/communication_team.rst、doc/documentation_team.rst，以及对应的荣誉成员列表 doc/maintainers_emeritus.rst、doc/contributor_experience_team_emeritus.rst、doc/communication_team_emeritus.rst。这些文件均为机器生成（文件头带有 “Generated by generate_authors_table.py” 标记），生成逻辑见 build_tools/generate_authors_table.py：

• 该脚本从 GitHub 组织的四个团队拉取成员，团队 slug 在脚本第 50–53 行定义：core-devs、contributor-experience-team、communication-team、documentation-team；
• 荣誉成员（emeritus）由组织成员减去所有团队成员计算得出（第 95–101 行），脚本还显式移除了 CI 机器人账号 sklearn-ci、sklearn-wheels、sklearn-lgtm（第 90 行）；
• 脚本按成员姓氏排序（第 172–175 行的 key 函数），最终在第 206–253 行写出上述各团队与荣誉名单的 RST 文件；
• 需要说明：脚本要求管理员权限（通过用户名 + access token 调用 GitHub API），文档注释也提示“每次团队新增成员后都应更新表格”。

2.3 技术委员会（Technical Committee, TC）

TC 成员是承担额外职责的维护者，职责包括参与战略规划、批准治理模型的变更。TC 存在的目的是从全局视角保证项目顺畅推进：影响整个项目的变更需要综合分析与“明确且知情的共识”；当核心贡献者社区（含 TC 成员）无法在规定时限内达成这种共识时，TC 就是解决该问题的实体（即死锁裁决者）。

TC 的选举规则（原文档第 115–120 行）：

1. TC 成员由核心贡献者提名；
2. 提名后进入讨论，讨论不得超过 1 个月；
3. 随后由核心贡献者投票，投票开放 1 周；
4. 通过条件为双重门槛：所投有效票的三分之二多数，且现任 TC 成员的简单多数（simple majority）同意；
5. 不积极参与 TC 职责的成员预期应当辞职。

文档当前列出的 scikit-learn TC 成员为：Thomas J. Fan、Alexandre Gramfort、Olivier Grisel、Adrin Jalali、Andreas Müller、Joel Nothman 与 Gaël Varoquaux（原文档第 122–126 行，以 :user: Sphinx 角色标注）。

3. 决策流程（Decision Making Process）

3.1 讨论渠道

关于项目未来的决策通过与全体社区成员的讨论做出。渠道划分（原文档第 130–134 行）：

• 所有非敏感的项目管理讨论都在项目贡献者公共邮件列表（[e-mail]）和 issue 追踪器上进行；
• 偶发的敏感讨论在私有列表上进行（如 2.2 节提到的核心贡献者新成员投票）。

3.2 共识寻求、投票与升级机制

scikit-learn 采用**“共识寻求”（consensus seeking）流程做决策：团队努力寻找一个在核心贡献者中没有未解决异议（no open objections）**的解决方案。关键机制（原文档第 136–144 行）：

• 讨论进行到任何时刻，任何核心贡献者都可以发起投票（call for a vote），投票自发起之日起 1 个月后结束；
• 大多数投票必须以 SLEP 为支撑（见第 4 节）；
• 若没有任何选项能获得所投有效票的三分之二，决策升级（escalated）到 TC；
• TC 自身同样使用共识寻求，兜底方案是：若 1 个月内仍无法达成共识，则用简单多数投票裁决。

文档将上述整套机制统称为**“决策制定流程”（the decision making process）**。

3.3 分级决策规则

除“新增核心贡献者”“TC 成员选举”（见第 2 节）外，其余决策按以下规则分级处理（原文档第 146–171 行）：

变更类型	通过条件	发生场所
小的代码与文档变更：不改变代码逻辑的小维护、拼写修复、增改一句话等（但不包含 scikit-learn.org 落地页或 “about” 页面的变更）	1 位核心贡献者 +1，且无核心贡献者 -1（惰性共识 lazy consensus）	issue 或 PR 页面
代码变更与重大文档变更	2 位核心贡献者 +1，且无核心贡献者 -1（惰性共识）	issue 或 PR 页面
API 原则变更，以及依赖项或支持版本的变更	走上述完整的“决策制定流程”；API 原则变更必须由 SLEP 支撑；支持版本这类较小决策可在 GitHub issue 或 PR 上进行	决策流程 / issue / PR
治理模型变更	走 SLEP020 提案描述的流程	SLEP 流程

两条补充规则值得注意：

1. 惰性共识中的“合理时间”：在惰性共识场景下，核心贡献者若不确定其他人是否会同意，预期应给予他人“合理时间（reasonable time）”在 PR 上表达意见后再合并；
2. 否决申诉（veto appeal）：如果惰性共识上出现一票否决（-1），提案者可以向社区与维护者申诉，该变更随后按完整的决策制定流程批准或否决。

3.4 治理模型变更的两条路径

治理模型（governance model）本身的修改有两条路径（原文档第 173–186 行）：

路径一：增强提案（SLEP）——按第 3.2 节描述的“决策制定流程”走完整共识与投票。

路径二：直接提交 GitHub PR——作者可直接以 PR 形式提议治理模型变更，其操作细节是：

• 作者可先开一个 draft PR 收集反馈，再提交修订后的 PR 用于投票；
• 作者满意后，可在公共邮件列表上发起投票；
• 1 个月的投票期内，PR 不得修改；
• 计票规则：PR 的 approval 记为赞成票，“Request Changes” 审查记为反对票；
• 若所投有效票的三分之二为赞成，则治理模型变更被接受。

4. SLEP：Scikit-Learn Enhancement Proposal

SLEP 是投票的前置条件。治理文档（slep 小节，原文档第 188–201 行）规定：

1. 任何投票之前，提案必须先公开并被讨论过；
2. 提案必须是一份整合好的文档（consolidated document），形式为 “Scikit-Learn Enhancement Proposal”（SLEP），而不是 issue 上的一段冗长讨论；
3. SLEP 必须以 PR 形式提交到 enhancement proposals 仓库，并使用官方的 SLEP 模板；
4. SLEP000 提案对该流程有更详细的描述（SLEP020 则规定了治理模型变更的流程，见 3.3 节）。

仓库内有多处文档相互印证了 SLEP 与治理流程的绑定关系：

• doc/glossary.rst 的术语表中，SLEP 条目定义为：“API 原则的变更以及依赖项或支持版本的变更通过 SLEP 发生，并遵循治理文档中描述的决策制定流程”（第 759–769 行）；
• doc/developers/contributing.rst 对功能请求的要求是：当 feature request 涉及 API 原则变更或依赖项/支持版本变更时，必须由 SLEP 支撑，按模板提交，并遵循治理文档的决策流程（第 205–210 行）。

也就是说，SLEP 是 scikit-learn 中“重大变更”的强制入口：先有整合后的提案文档公开讨论，再进入共识寻求与投票。

5. 小结：一次典型变更如何流经这套治理体系

综合上文，一次 scikit-learn 变更的治理路径可以归纳为：

1. 讨论：在公共邮件列表或 issue 追踪器上与全体社区讨论；
2. 分级：小改动走惰性共识（1–2 位核心贡献者 +1、无 -1，并给予他人合理评论时间）；API 原则、依赖与支持版本变更必须先出 SLEP；
3. 投票：必要时由任意核心贡献者发起投票（开放 1 个月），大多数投票以 SLEP 为支撑；
4. 升级：无选项获得三分之二票数时升级至 TC，由 TC 在共识寻求兜底简单多数投票后裁决；
5. 落点：治理模型变更最终经由 SLEP 或“封版 PR + 邮件列表投票（approval 计赞成、Request Changes 计反对、三分之二通过）”完成。

围绕这套制度，仓库提供了可直接查阅的配套材料：治理正文 doc/governance.rst、贡献指南 doc/developers/contributing.rst、bug 分类规范 doc/developers/bug_triaging.rst、术语表 doc/glossary.rst，以及由 build_tools/generate_authors_table.py 从 GitHub 团队数据生成的各团队成员名单（doc/maintainers.rst 等）。