Nix RFCs角色指南：RFC委员会、Shepherd团队与Shepherd Leader如何分工

Nix RFCs角色指南：RFC委员会、Shepherd团队与Shepherd Leader如何分工

【免费下载链接】rfcsThe Nix community RFCs项目地址: https://gitcode.com/gh_mirrors/rfcs2/rfcs

想参与 Nix 生态的重大变更？先搞懂Nix RFCs仓库中的三种关键角色：RFC 委员会（RFC Steering Committee）、Shepherd 团队（Shepherd Team）与 Shepherd Leader。它们各司其职，共同把一份提案（RFC）从"一个想法"推进到"被接受"，这就是本文要讲清楚的角色分工。

什么是 Nix RFCs？为什么需要角色分工？

RFC 全称 Request For Comments（征求意见请求）。在 Nix 生态中，"实质性"变更——比如语言语义/语法改动、移除语言特性、Nixpkgs 大重构、引入新接口——必须先走 RFC 流程，获得社区共识后才能实施。

普通改动（增删包、修 bug、改文档）直接提 Pull Request 即可，不需要 RFC。

那问题来了：谁来组织讨论？谁来推动进度？谁来拍板合并？答案就是下面这三个角色 🎯

Nix RFCs 流程总览：角色在哪些环节登场？

一个 RFC 的典型生命周期是：

1. 有想法→ 填写 RFC 模板（可先找"co-author"帮助完善）
2. 提交 Pull Request，进入社区评审
3. Shepherd 团队开始护航讨论，推动共识形成
4. 讨论成熟后发起FCP（Final Comment Period，最终评论期），持续 10 个日历天
5. FCP 结束，RFC 委员会负责合并（接受）或关闭（拒绝）

整个过程可参考 Nix RFCs 流程说明 与仓库根目录的README.md。

RFC 委员会（RFCSC）：整个流程的"调度员"

RFC 委员会是常设机构，固定 5 人，每年 12 月由现任委员会从公开提名中选出下一届（机制见rfcs/0043-rfcsc-rotation.md），次年 1 月交接。

它只负责流程，不对 RFC 内容负责，核心职责仅三件：

• ✅组建 Shepherd 团队：PR 开出后 1 周内，从社区提名中一致同意（unanimous）地选出 3–4 名 Shepherd，并指定 Leader
• ✅监督进度：若 Shepherd 团队"摆烂"，委员会要督促甚至重新指派
• ✅合并最终结果：接受或拒绝的 RFC，由委员会执行合并/关闭

通常他们每周开一次约 1 小时的会。另外，委员会成员同一雇主不超过 2 人，避免利益冲突。

Shepherd 团队：单个 RFC 的"护航员"

Shepherd 团队按每个 RFC 单独组建，从 PR 讨论区的名选中产生，负责把这份特定 RFC 推向接受或拒绝。

组队规则很有讲究：

• 3–4 名熟悉该 RFC 涉及领域的社区成员
• RFC 作者本人不能入选
• 最多一半成员可以来自 RFC 委员会（防止"自己审自己"）

他们的日常工作：

1. 引导建设性讨论，新观点不断出现时持续跟进
2. 阶段性总结当前讨论状态（长讨论后通常会发一条 summary 评论）
3. 当讨论趋于成熟，由团队提出FCP 动议（merge 或 close），且须全体成员签核后才进入 FCP

💡 找不齐 Shepherd？rfcs/0130-stalled-rfcs.md定义了"保险丝"：开 PR 1 个月仍凑不齐团队会收到提醒，再 1 个月仍不够则以"社区兴趣不足"关闭 PR，避免无限期空转。

Shepherd Leader：进度的"守时人"

每个 Shepherd 团队里有一人被指定为Shepherd Leader。他的职责很清晰也很"克制"：

• ⏱ 确保流程按时推进（timely fashion）
• 是作者和社区的对接窗口，帮你识别相关方和潜在阻碍
• 没有把团队推向某个特定结论的义务——决策权在团队，不在 Leader

简单说：Leader 管"节奏"，团队管"方向"，委员会管"落地"。

角色分工速查表

延伸阅读：关键 RFC 文件

新手常见疑问（FAQ）

Q1：RFC 委员会会"否决"我的 RFC 吗？委员会不对内容表态，它只推进流程。真正的"接受/拒绝"由 Shepherd 团队发起 FCP、委员会执行合并。

Q2：作者能当自己 RFC 的 Shepherd 吗？不能。作者必须回避，这是保证公正性的硬规则。

Q3：RFC 被接受了是不是就一定能进 Nix/Nixpkgs？不是。接受只代表"主要干系人在原则上同意了方向"，实现阶段仍要过正常的 PR 评审；而且实现优先级不打包票，通常作者自己实现才是最稳妥的路径。

理解这套Nix RFCs 角色分工，你就知道在哪个环节该找谁、该做什么——下次提交重大提案时，流程就不会让你迷路了 🚀

【免费下载链接】rfcsThe Nix community RFCs项目地址: https://gitcode.com/gh_mirrors/rfcs2/rfcs