PowerShell 治理体系解析：委员会、维护者与工作组如何驱动 RFC 决策

本文以 PowerShell 仓库中 docs/community/governance.md 为蓝本，完整拆解项目的治理架构：PowerShell 委员会的权限与职责、仓库维护者（Repository Maintainers）的合并关卡、工作区（Working Groups）的分域治理，以及一个想法从 Issue 到 RFC 再到实验性功能落地的完整流程。读完本文，你将理解为什么 PowerShell 的每个重大特性都要求先写 RFC、哪些变更必须走 1 - Planning 审批，以及 CODEOWNERS 等机制如何把治理规则固化到仓库中。

一、治理体系的角色定义

governance.md 开篇用一组术语锚定了整个治理体系，理解这些角色是理解后续所有流程的前提：

角色	定义与权限
PowerShell 委员会（PowerShell Committee）	由项目负责人组成的委员会，负责设计决策、审批 RFC 以及审批新的维护者/委员
仓库维护者（Repository Maintainer）	负责在所有要求（代码评审、测试、文档、适用的 RFC 审批）满足后将 PR 合入 master；只有维护者拥有 master 分支的写权限
工作区（Working Groups, WGs）	针对 PowerShell 特定领域的贡献者集合，负责在领域内建立共识并向委员会输出专业意见
Corporation	拥有 PowerShell 仓库的实体（为 Microsoft）。在极端情况下保留解散或重组委员会、项目负责人及公司维护者的权利
公司维护者（Corporate Maintainer）	拥有对委员会或任何协作者决策的否决权（veto）的实体或个人。该权力应被审慎使用，因为项目定位是由社区驱动的。最初的公司维护者是 Jeffrey Snover
RFC 流程	"request-for-comments"（征求意见稿）流程，设计决策通过该流程做出

这套设计的核心是权限分级：只有维护者能写 master，只有委员会能拍板设计变更，领域问题交给工作区，公司保留最终否决权。下面逐层展开。

二、PowerShell 委员会

委员会及其成员是 PowerShell 体验的主要守护者，覆盖 PowerShell 语言、设计与整个项目。当前委员会成员为：

• Bruce Payette（BrucePay）
• Jim Truher（JamesWTruher）
• Paul Higinbotham（paulhigin）
• Rob Holt（rjmholt）
• Steve Lee（SteveL-MSFT）

哪些变更必须走 RFC

文档明确列出五类必须先有书面 RFC、并留出充足时间让社区反馈之后才能开工的变更：

1. PowerShell 的新特性或新能力（如 PowerShell 类、PSRP over SSH 等）；
2. 任何可能构成破坏性变更的改动——破坏性变更的判定标准见 docs/dev-process/breaking-change-contract.md，该契约将变更分为"公共契约、合理灰区、不太可能的灰区、明确非公共"四个桶，其中前三类破坏性变更都需要联系委员会；
3. 随核心 PowerShell 模块一同发布的新模块、新 cmdlet 或新参数（如 Microsoft.PowerShell.*、PackageManagement、PSReadLine）；
4. 新增委员会成员或仓库维护者；
5. 任何对维护流程本身的修改（包括委员会成员、仓库维护者、领域专家的职责变更）。

哪些变更不需要 RFC

文档也给出了轻量通道：如果新特性被认为足够小（例如文档中举的例子——把 Mac/Linux 上 PSReadLine 的默认 EditMode 改为 Emacs），则标有 1 - Planning 标签的 issue 只需要简单多数委员签字即可推进。随后由一名仓库维护者把 issue 重新标记为 2 - Ready，贡献者即可开工。

这里有一个关键的安全阀：任何委员如果觉得某个行为大到值得走 RFC，都可以加上 RFC-required 标签，此时 issue 所有者必须按 RFC 流程执行。也就是说，"免 RFC"通道随时可以被升级为正式 RFC 流程。

委员的行为准则（DOs 与 DON'Ts）

文档以 DO/DON'T 列表约束委员行为，值得摘录其要点：

应当（DO）：

1. 执行 行为准则（Code of Conduct），接收滥用与违规报告并提交委员会处理；
2. 就 issue 和 PR 回复设计层面的意见（支持好的工作、为兴奋的新特性背书）；
3. 鼓励围绕 PowerShell 方向的良性讨论；
4. 对未走恰当 RFC 流程的 PR 提出"红旗"警告；
5. 为文档和最佳实践做贡献；
6. 在 GitHub 之外保持社区存在感（博客、技术问答社区、Reddit、Hacker News 等）；
7. 把社区反馈充分纳入决策权重；
8. 对多样化的观点保持礼貌与尊重；
9. 确保贡献者遵循贡献指南。

不应当（DON'T）：

1. 不为鸡毛蒜皮的小事反复打"红旗"以至于拖慢项目进度；
2. 不得把个人观点包装成委员会的"绝对意见"——委员被鼓励表达观点，但必须表明这只是个人观点。

委员会成员的产生

委员会初始成员为 Microsoft 员工，但文档预期随着时间推移，社区中的 PowerShell 专家会逐步加入。加入条件高度依赖贡献度与专业度。流程为：任何委员随时可以提名一位出色的社区成员加入委员会，提名必须以 RFC 形式提交（详述该人为什么合格、将如何贡献），RFC 讨论后需要**全体委员一致通过（unanimous vote）**才能确认新委员。

行为准则的执行

按文档引用 贡献指南 中"Code of Conduct Enforcement"一节的规定：滥用报告由 PowerShell 委员会审查；一旦认定违反行为准则，可以施加临时封禁，时长视影响与严重程度而定，从 1 天、数天、一周到最长 30 天不等；屡犯者可能面临对 PowerShell 组织的永久封禁。

三、仓库维护者（Repository Maintainers）

维护者是社区/仓库的"受信托管理人"，负责保持 PowerShell 代码的一致性与质量，首要职责之一就是在所有要求满足后合并 PR。

权限模型

治理文档中特别强调：工作区（WG）成员对仓库有写权限，但可以 git push 到除 master 以外的所有分支，可以合并除 master 以外所有分支上的 PR——因为 master 是唯一长寿命分支（详见 docs/git/README.md）。而只有仓库维护者能写 master，这是治理权限模型中最重要的一道闸。

当前维护者名单

docs/maintainers/README.md 列出当前维护者（按字母序维护）：Aditya Patwardhan、Andrew Menagarishvili、Dongbo Wang、Ilya Sazonov、Robert Holt、Travis Plunk，并保留了一节"Former Repository Maintainers"记录历史成员。

合并前的检查清单

governance.md 只给出了维护者职责的概览，而 docs/maintainers/README.md 以 MUST / SHOULD / SHOULD NOT 三级强度细化了合并纪律，这是理解"PR 到底怎样才能进 master"的关键：

• MUST：遵守行为准则并向委员会报告疑似违规；确保每位贡献者签署了有效的 Microsoft 贡献者许可协议（CLA）；含第三方代码时核验许可证合规；确认需要委员会审批的变更已走完 RFC 或审批流程；纯文档 PR 也要确认代码评审已进行；含新功能的 PR 必须确认测试与文档已编写。
• SHOULD：给 issue/PR 加正确的标签；为 PR 指派合适的领域专家（例如增加远程功能可能需要安全专家）；校验 git 提交者身份与 PR 提交者一致；提醒贡献者在 PR 描述中引用 issue（如 Resolves issue #123）；等待 CI 通过。
• SHOULD NOT：不合并 CI 失败的 PR；不合并 CLA 状态检查未通过的 PR；不在 PR 提交后立即合并（要给社区留下反馈时间，紧急情况除外）；不合并自己的 PR——维护者开的 PR 必须由另一名维护者合并，除非存在极端的短期紧急情况或另一名维护者已明确签字认可。

成为维护者的路径文档同样写得很清楚：现有维护者可以一致提名（unanimous）一位社区成员，提名提交委员会听取理由，委员会需要简单多数才能否决该提名；获批后由现任维护者提交 PR 更新该文档，PR 描述即为公开公告。注意这个门槛设计：进入 WG 与进入维护者名单的流程不同，维护者提名对委员会而言"默认通过、少数否决"，而新委员则"全票通过"。

四、工作区（Working Groups）：分域治理的核心

工作区是 PowerShell 治理体系中最具特色的部分，其完整定义在 docs/community/working-group.md 与 docs/community/working-group-definitions.md 中。

设计目标

委员会设计 WG 流程时有四个明确目标：

1. 在不牺牲 PowerShell 稳定性的前提下提升创新速度；
2. 减少贡献者在不切实际的 PR 和 RFC 上耗费的时间（通过 WG 前期筛选）；
3. 提升 Microsoft 内外领域专家（SME）的正式权威；
4. 减少需要委员会出面主持的技术讨论数量。

换言之，WG 是把"技术可行性判断"从委员会下沉到领域专家的机制。

现有工作区一览

working-group-definitions.md 维护着各 WG 的定义、成员与示例议题，当前包括：

工作区	职责范围
DSC	管理 PowerShell 7 中 DSC 的一切面向，包括语言特性（如 Configuration 关键字）与 PSDesiredStateConfiguration 模块。由于 DSC 已集成进语言本身，必须按语言特性治理
Developer Experience	模块开发体验（C#、脚本等）与在其他应用/运行时中宿主化 PowerShell 及其 API 的体验；重点关注与 Windows PowerShell 的向后兼容（如 PowerShell Standard）以及与 .NET CLI、VS Code 扩展等工具链的集成
Engine	核心引擎代码的实现与维护：语言解析器、命令与参数绑定器、模块与提供程序系统（*-Item cmdlets、Providers）、性能、组件化、AssemblyLoadContext。注意：Engine WG 不负责语言定义，那是 Language WG 的职责，但许多 issue 需要两边共同输入
Interactive UX	仅限交互场景的体验：Console、Help 系统、Tab 补全/IntelliSense、Markdown 渲染、PSReadLine、调试
Language	处理 PowerShell 语言的抽象定义本身，与 Engine WG 明确区分；语言决策影响深远，因此该 WG 与委员会协作最紧密
Remoting	PSRP（PowerShell 远程协议）、PSRP 之下的协议（WinRM、SSH）、以及"纯 SSH"等远程相关协议；由于序列化边界相似，还负责 PowerShell 作业系统
Cmdlets and Modules	源码位于本仓库的核心/inbox 模块：新 cmdlet 与参数提案、现有 cmdlet 的改进与修复、破坏性变更。而 Microsoft.PowerShell.Archive、PackageManagement、PowerShellGet、PSDesiredStateConfiguration、PSReadLine、ThreadJob 等模块在各自独立仓库中，由各自仓库的维护者负责
Security	任何有安全含义的 issue 或 PR 都应引入该 WG 提供专业意见

文档还专门列出了明确不设工作区的领域，以示完整性：Build（构建、编译、打包所需的一切，如 build.psm1、install-powershell.ps1、打包脚本与基础设施）与 Quality（测试代码、测试基础设施、代码覆盖率、Pester）——这两块不归 WG 管，由维护者直接负责。这个"负面清单"本身也是治理设计的一部分：它防止责任真空，也防止 WG 无限膨胀。

WG 成员的职责与纪律

governance.md 对 WG 成员列出的 DO 清单相当具体：

1. 应当分诊并参与所有打了 WG-* 标签的 issue 和 PR 讨论；
2. 应当定期与 WG 其他成员沟通，就"issue 是否推进"协调决策；
3. 应当对 issue 是否进入实现或 RFC 阶段做出决策；
4. 应当给 issue 分配正确的标签；
5. 应当只在自己实际着手处理时才认领（assign）自己领域的 issue 和 PR；
6. 应当为被指派或属于本 WG 的 PR 做代码评审——评审时即使一切正常也要留言（一句 "LGTM" 即可），让他人知道已有人看过；
7. 应当确保贡献者遵循贡献指南与行为准则；
8. 应当确保贡献包含针对所有新增/变更功能的 Pester 测试；
9. 应当确保贡献包含针对新增/变更功能的文档；
10. 应当鼓励贡献者在 PR 描述中引用 issue，并鼓励 PR 标题有意义（必要时直接改标题，让 changelog 信息准确可用）；
11. 应当核验所有贡献遵循编码规范。

不应当：不走 RFC 或审批流程就创建新特性、新设计或改变行为。

working-group.md 还补充了一条纪律：WG 成员反复在无共识的情况下代表 WG 发言，可能被谴责（censured）甚至移出团队。

一个想法如何穿过 WG：完整流程

working-group.md 用编号步骤（配图即本文开头的流程图）描述了完整生命周期：

1. 贡献者产生一个想法；
2. 贡献者以非正式 issue 描述想法，包含理由、用例、以及预期输入/输出示例，用于判断可行性与价值；
3. 维护者给 issue 打上Area 标签，该标签映射到一个或多个 WG；
4. 若 WG 判断想法可以在 PowerShell 仓库之外原型验证（如做成一个模块），则建议贡献者在项目外起步，issue 关闭（可附新项目链接）。若外部实现后来被证明成功且流行，贡献者可以开新 issue 重启流程，提议将其并入主包；
5. 相关贡献者在 issue 中讨论可行性与方案，拥有该 Area 的 WG 有义务参与；
6. 经过"足够穷尽"的讨论（WG 判断没有新论点出现）后，WG 通过尽力共识（best effort consensus）做出是否继续的判断。文档给出的共识方式示例包括：某位 WG 成员以评论形式提案、其他成员用 GitHub 的点赞/点踩"react"表态，或 WG 通过自己的私密渠道达成共识。

若 WG 否决：流程终止。常见否决理由包括：想法可以在主仓库外实现并验证价值；难以或无法实现；实现会引入不受欢迎的（可能破坏性的）变更；以及其他 WG 特定理由。贡献者若持有有说服力的理由认为 WG 错了，可以 appeal（上诉）到 PowerShell 委员会——方式是在 issue 中 mention @PowerShell/PowerShell-Committee，随后维护者会加上 Review-Committee 标签并重新打开 issue，委员会将再与 WG 讨论后做出最终裁决。文档特意警告：上诉必须列明理由，无理由的上诉可能被委员会拒绝受理。

若 WG 认可想法有价值，进入两条分支：

分支一："RFC Not Required"

WG 判定想法小、无争议、简单，可免 RFC。此时 WG 把 issue 标记为 "RFC not required"，issue 直接进入代码 PR 阶段，由 WG 和维护者评审。注意委员会保留最终权威：若委员会看到某个 "RFC Not Required" issue 认为需要更多论述，仍有权强制要求 RFC。对于较小的破坏性变更，维护者或 WG 可以加 Review - Committee 标签请委员会提供额外意见。

分支二：RFC/原型双轨流程

若想法有显著的设计或生态影响、无法在仓库外原型验证、且社区与 WG 一致认为值得推进，贡献者（可以是原 issue 提交者，也可以不是）必须同时做两件事：

• 在 PowerShell/PowerShell-RFC 仓库中把一个 Draft PR（草稿 PR） 写成 RFC；
• 在 PowerShell/PowerShell 仓库中以 Draft PR 形式提交实现原型。

两步顺序不限，但两者都是代码被接受（包括实验性功能）的必要条件。文档明确说明"Draft"大写指 GitHub 的 Draft pull request 特性，项目有意"大量使用"它来标记一个想法从提出到实现的整个生命周期。

RFC 的三阶段模型

working-group.md 解释了 RFC 流程如何从"文件夹迁移"模式（Draft → Experimental → Accepted/Final）演进为围绕 Draft PR 的模型。此前用文件夹推进 RFC 与 PR 评审的收益难以调和；借助 GitHub Draft PR，RFC 现在有三个阶段：

1. Draft PR 阶段：RFC 处于评审期，公开征集意见，可基于社区反馈持续大幅修订；
2. 至少两个月讨论后，RFC/PR 作者把 PR 标记为"ready for review"，RFC 进入委员会评审队列。若委员会认定 RFC 意图不合理（设计存在不可调和的问题、或与 PowerShell 的原则不符），则拒绝 PR，流程终止；
3. 多数情况下，委员会会等待代码 PR 先以实验性（experimental）方式合并，借助用户反馈或遥测（telemetry）数据再决定 RFC PR 的去留；
4. 最后委员会合并或关闭 RFC PR，分别对应 RFC 被接受或被拒绝。

实验性功能：为什么必须"先有代码"

文档中"Experiments"一节论证了一个关键原则：委员会在考虑接受 RFC 之前，要求存在某种实现。理由有二：

• 实现一个想法往往能暴露出当初构思时没理解的机会与挑战；
• 一个看似简单的代码变更，只有放进可运行代码中实验，才能看出其连锁影响。

因此贡献者可以编译 PR 分支来摆弄一个可工作的迭代版本，从而判断特性是否如预期般有价值。只要 RFC 已写成草稿并发布，WG 或委员会通常会批准该特性作为实验性功能纳入 preview 版本，以扩大真实反馈范围，并让遥测能反映用户是否大规模关闭该特性。文档注明当前这是逐案（case-by-case）决定，委员会未来会逐步建立"何时该以实验性方式合并"的更明确指导线。实验的完整度标准是：足以作为用户体验的合理指示器；若特性需要破坏性变更，破坏应直接做在原型里，让用户能实验该破坏的影响是否可接受。

这一原则在仓库中有直接源码印证：实验性特性的开/关命令实现位于 src/System.Management.Automation/engine/ExperimentalFeature/，其中 EnableDisableExperimentalFeatureCommand.cs 与 GetExperimentalFeatureCommand.cs 分别对应 Enable-ExperimentalFeature / Disable-ExperimentalFeature 与 Get-ExperimentalFeature 命令，配合仓库根目录的 experimental-feature-linux.json 与 experimental-feature-windows.json 描述平台差异——这正是上文"以遥测和用户反馈决定是否转正"机制的落地代码。

WG 成员的滥用举报

文档同样为 WG 机制留了出口：WG 成员可能是志愿者，若出现行为不当、越权或违反行为准则的情况，建议通过 GitHub 的举报滥用机制通知维护者审查。

五、治理规则在仓库中的落地：标签、CODEOWNERS 与契约

治理文档的"Issue Management Process"和"Pull Request Process"两节分别指向 docs/maintainers/issue-management.md 与贡献指南。把这两处与治理文档对照，可以看到规则是如何落到可操作层面的：

标签体系是 WG 治理的操作接口

issue-management.md 定义了 issue 分类标签（Issue-Bug、Issue-Enhancement、Issue-Discussion 等）、解决标签（Resolution-Fixed、Resolution-By Design、Resolution-Won't Fix 等），以及最关键的 Area / WG 标签。其中 WG-* 前缀标签与 working-group-definitions.md 中定义的 WG 一一对应，例如：

• WG-Engine / WG-Engine-Performance / WG-Engine-Providers：核心引擎、解释器、运行时及其性能、内置提供程序；
• WG-Language：解析器、语言语义；
• WG-Interactive-Console / WG-Interactive-PSReadline / WG-Interactive-IntelliSense / WG-Interactive-Debugging / WG-Interactive-HelpSystem：交互体验各子域；
• WG-DevEx-Portability / WG-DevEx-SDK：跨平台模块编写与 SDK 宿主化；
• WG-Remoting、WG-Security、WG-Quality-Test 等。

治理文档中"WG 应分诊并参与所有带 WG-* 标签的 issue"这一条纪律，正是以这套标签体系为执行载体的。此外还有流程标签：Review - Needed、Review - Waiting on Author、Review - Abandoned、Review - Committee（对应治理文档中需要委员会复审的 issue/PR）、Committee-Reviewed 等。

CODEOWNERS：把"领域归属"写进仓库

治理体系还通过 .github/CODEOWNERS 把领域归属固化为强制评审规则。该文件的默认规则把所有路径指派给 @PowerShell/powershell-maintainers 团队，再按目录叠加领域 owner，例如：

• src/System.Management.Automation/engine/remoting 指派给引擎与远程方向的两位维护者；
• src/System.Management.Automation/engine/parser 指派给语言方向的专家；
• src/System.Management.Automation/help 指派给帮助系统方向的专家；
• 构建相关（*.csproj、*.yml、build.*、tools/ 等）指派给维护者团队——与上文"Build 不设 WG，由维护者直接负责"的定义互相印证。

从源码结构看，CODEOWNERS 中注释掉的部分（如 Cmdlets Management、Console、DSC 等区域）说明该文件是渐进式演进的，但已启用的条目已经体现了治理文档中"WG/领域专家参与评审"的要求在 CI 层面的自动执行。

破坏性变更契约：RFC 边界的量化定义

治理文档中"可能要求破坏性变更"的判定并非空话，docs/dev-process/breaking-change-contract.md 给出了量化标准，将变更分为四桶：

1. Public Contract：明确违反公共契约的变更，如改变既有输入下的可观察行为、重命名/删除公共类型或 cmdlet 及参数（参数可通过别名缓解）、缩小参数取值范围、在不提升协议版本号的情况下做不兼容的协议变更——这些不可接受；而新增类型/成员/cmdlet、把报错行为改成新功能、带协议版本升级的协议变更则可接受；
2. Reasonable Grey Area：客户合理依赖的行为变化（如事件执行时序、解析器从宽容变严格），需要判断力，通常需要大范围外部预览，也可能需要 RFC；
3. Unlikely Grey Area：客户可能但大概率不会依赖的变化（如无参 cd 的语义、对象格式化输出——因为 PowerShell 管道传的是对象而非文本，格式化视为 UX 问题可以自由调整）；
4. Clearly Non-Public：内部 API 破坏私有反射、System.Management.Automation.Internal 命名空间的变更、参数集重命名——不需要事前审批，但若对生态造成过大痛苦需要回头重新审视。

对贡献者的直接要求是：第 1、2、3 桶的任何破坏性变更都必须先联系委员会；不确定归哪一桶时也要联系；即便旧行为"错了"也必须走此流程。这正是治理文档中"任何可能导致破坏性变更的事项必须写 RFC"的具体判据。

六、总结：三层漏斗式的决策架构

把 governance.md 的骨架与各配套文档串起来，PowerShell 的治理体系实质是一个三层漏斗：

1. WG 层（分域过滤）：所有想法先成为 issue，经 Area 标签路由到对应 WG，由领域专家做可行性共识判断。不可行的想法被挡在这里，省下了社区写无效 PR/RFC 的成本；
2. 委员会层（设计裁决）：通过 WG 关隘的想法，小的走 "1 - Planning → 2 - Ready" 的多数签字轻量通道，大的走 RFC + 实验原型双轨、至少两个月讨论、委员会评审、遥测验证的完整通道；破坏性变更按四桶契约强制升级；
3. 维护者层（质量闸门）：只有维护者能写 master，且合并前必须满足 CLA、CI、评审、测试、文档一整套 MUST/SHOULD 检查；CODEOWNERS 再把领域评审强制化。

公司（Corporation）与公司维护者的否决权则作为顶层保险丝存在。这套架构的意图在 WG 设计目标中已写明：既要提升创新速度，又要让 PowerShell 的稳定性不因速度而受损——每一个环节（WG 前置筛选、RFC 两月讨论期、实验性遥测、维护者合并纪律）都是为这个平衡服务的。