PowerShell 工作组（Working Group）体系：Issue 分诊、RFC 流程与实验特性的治理机制

本篇技术指南解析 PowerShell 仓库 docs/community/working-group.md 所定义的工作组（Working Group, WG）治理体系：工作组如何按领域分诊 issue、决定一个想法是否进入 RFC/原型流程，以及"实验特性"机制如何支撑"先合并实验代码、再凭用户反馈决定 RFC 去留"的决策路径。读完本文，你能理解在 PowerShell 仓库提交一个 feature 提案时，它会被哪些工作组接管、经历哪几个流程阶段，以及实验特性在引擎源码与测试中是如何落地验证的。

工作组体系的核心概念与角色分工

工作组是"聚集了特定组件或技术领域知识贡献者的组织单元"。它们承担三项核心职责：

1. Issue 分诊与受理（issue triage/acceptance）；
2. 代码评审（code reviews）；
3. 在 issue、PR 和 RFC 讨论中向他人提供该领域的专业知识。

原文档明确了一个容易混淆的边界：工作组内某些成员可能对该团队某个子主题有更专精的知识（例如 PSReadLine 成员比其余成员更懂控制台输入），但意图是每个团队作为一个整体对其更大的主题空间负有集体决策责任。这一点在 工作组定义文档 中有体现，例如 Interactive UX 工作组中明确标注了 @daxian-dbw (PSReadline / IntelliSense) 这类子方向分工，但决策仍以 WG 集体名义作出。

要读懂 WG 流程，需要先厘清文档中的四个术语及其相互关系（原文档 "Terms" 一节的完整定义）：

角色	定义	关键权限/职责
Contributor	泛指任何参与 issue、贡献代码、RFC、文档、测试、bug 报告的人，不区分其项目身份	任何人都可以发起流程的第 1、2 步
Repository Maintainers	PowerShell 仓库的可信管理者，负责维护代码的一致性与质量	在满足全部要求后合并 PR 是其主要职责之一，见 维护者文档
PowerShell Committee	负责 PowerShell 项目的设计与治理	主要通过投票接受或否决 RFC 文档行使职权，见 治理文档
Working Group	负责为 PowerShell 特定领域提供专业知识，帮助在社区和委员会间建立共识	分诊 issue、作出"是否继续推进"的裁决

可以推断，这套角色设计的意图是让**领域共识（WG）→ 设计裁决（Committee）→ 代码合入（Maintainers）**三级权限逐级收口：WG 不直接决定 RFC 生死，Committee 不直接合并代码，Maintainers 不决定特性方向。

设计目标：为什么需要工作组流程

文档 "Goals" 一节指出，PowerShell Committee 在设计 WG 流程时有四个明确目标，这四条也是理解整个流程"为什么这么绕"的钥匙：

1. 在不牺牲 PowerShell 稳定性的前提下提升创新速度——即"快"和"稳"要同时保住；
2. 减少贡献者在不可行 PR/RFC 上浪费的编写与评审时间——通过前置分诊，让没有价值的想法尽早止步；
3. 提高 Microsoft 内部与外部领域专家（SME）的正式权威——把散落在社区的经验判断变成有章可循的职权；
4. 降低必须上升到 Committee 层面的技术讨论数量——绝大多数争议应在 WG 层面消化掉。

这四条目标直接决定了后文流程中"可外部原型则拒绝"、"RFC Not Required 快车道"、"实验特性先跑起来看遥测"等机制的存在。

流程总览：从想法到实现的完整路径

整个流程在仓库的 Visio 图 process_diagram.vsdx 及其渲染图 process_diagram.svg 中有可视化表达。文档文字版的流程如下，每一步都给出其判定依据与出口：

第 1–3 步：提出想法并打上 Area 标签

1. 贡献者对 PowerShell 有一个想法；
2. 贡献者非正式地提交一个 issue，描述想法、说明理由与几个用例，并必须附上期望输入/输出的示例，让他人理解该功能在真实世界的行为，同时用于判断可行性与社区价值；
3. Maintainers 将该 issue 分诊到一个 Area 标签，而该标签映射到一个或多个工作组。

Area 标签与 WG 的对应关系是流程的路由键，完整清单见 Issue Management 文档 的 "Feature areas" 小节，例如：

• WG-DevEx-SDK：以运行时方式托管 PowerShell、PowerShell API、PowerShell Standard，或模块/cmdlet 开发相关；
• WG-Engine / WG-Engine-Performance / WG-Engine-Providers：核心引擎、解释器、运行时及其性能、内置 Provider；
• WG-Interactive-Console / WG-Interactive-HelpSystem / WG-Interactive-IntelliSense / WG-Interactive-PSReadline / WG-Interactive-Debugging：交互式体验各方向；
• WG-Language：解析器与语言语义；
• WG-Remoting：任意传输层上的 PSRP 问题；
• WG-Security：安全相关领域。

从源码结构看，这些 WG 的职责范围直接对应仓库代码布局：WG-Engine 对应 src/System.Management.Automation/engine/ 下的 parser、interpreter、模块与 Provider 系统，WG-Engine-Providers 对应 src/System.Management.Automation/namespaces/ 中的 FileSystem/Registry/Environment 等 Provider 实现，WG-Remoting 对应 src/System.Management.Automation/engine/remoting/ 目录。

第 4 步：外部原型分流

如果工作组判断该想法可以在 PowerShell 仓库之外被原型化或构建（例如作为一个 module），贡献者应该在 PowerShell 项目之外启动它，issue 因不再与主项目直接相关而关闭（如有新项目则附链接）。

原文档还给出了这条"外部路径"的回流机制：如果外部实现最终被证明成功且特别流行，贡献者认为将其并入主 PowerShell 包有压倒性价值时，可以用一个新 issue 重启整个流程，提议把该功能直接纳入主包。这实际上是一个低成本的市场验证漏斗：先用外部模块试探需求，验证通过才进入主仓库的正式流程。

第 5–6 步：可行性讨论与 WG 裁决

Issue 提交后，感兴趣的贡献者在 issue 中讨论想法的可行性与实现路径，拥有该 Area 的工作组被期望参与这场讨论。工作组可能有自己领域内的额外评审标准。

经过"足够穷尽"的讨论（判据：工作组认定没有新论点了），工作组对该想法是否应继续走完流程作出裁决。原文档强调三点：

• 裁决应通过工作组内部共识的最佳努力达成；
• 目前没有硬性规定达成共识的方式，文档给出的参考做法包括：
  • 由工作组的一名成员以评论形式提出动议，其他成员在 GitHub 上以**拇指上/下反应（thumbs up/down react）**表态；
  • 工作组通过自己既有的私有渠道沟通以达成结论；
• 有一条明确的纪律约束：反复未经授权代表工作组发言的成员，可能被谴责（censured）或从团队中移除。

分支一：工作组拒绝提案

如果工作组认为想法不应继续推进，流程终止。原文档列举的拒绝理由包括（但不限于）：

• 该想法可以在主 PowerShell 仓库/包之外实现并验证其有用性与流行度（呼应第 4 步的外部原型分流）；
• 该想法难以实现或无法实现；
• 实现会引入对 PowerShell 的 undesirable（可能是破坏性）变更；
• 各个工作组各自领域的其他理由。

拒绝并非终点，原文档规定了明确的上诉通道：

1. 如果贡献者认为自己有 compelling arguments 证明工作组判断错误，可以通过在 issue 中 mention @PowerShell/PowerShell-Committee 向 PowerShell Committee 上诉；
2. 之后一名 maintainer 会给该 issue 加上 Review-Committee 标签并重新打开；
3. PS Committee 随后与工作组及其他相关方进一步讨论，对 issue 是否应继续推进作出最终裁决。

注意一个细节：原文档要求务必逐条列出上诉理由——没有理由支撑的上诉（unfounded appeals）可能在给出理由之前直接被 Committee 拒绝受理。

从仓库文档可以印证，Review - Committee 正是 Issue Management 文档 中 "Process Tags" 定义的官方 PR/issue 标签之一（"The PR/Issue needs a review from powershell-committee"），也就是说上诉标签与治理文档中的流程是同一套标签体系在运转。

分支二：工作组认为提案有价值

如果想法通过了工作组的初步受理标准，流程沿以下两条路径之一继续：

路径 A："RFC Not Required" 快车道

某些情况下，工作组判定某个想法小、无争议或简单，不需要走 RFC。此时工作组将该 issue 标记为 "RFC not required"，issue 即可直接进入代码 PR 阶段，由工作组与 Maintainers 评审。

两条制衡规则需要牢记：

• Committee 保留强制要求 RFC 的权力：只要 Committee 认为某个 "RFC Not Required" issue 在合入前还需要更多论述（exposition），他们可以随时要求补 RFC；
• 小破坏性变更可请 Committee 加看：遇到 minor breaking changes 时，Maintainers 或工作组可以加 Review - Committee 标签以获取 Committee 的额外意见。

路径 B：RFC + 原型双轨流程

如果一个想法有显著的设计或生态影响、不能在 PowerShell 仓库之外原型化、且社区与工作组一致认为值得推进，那么某位贡献者（可以不是原 issue 提交者）必须同时完成两件事：

1. 以 Draft PR 的形式，把 RFC 写入 PowerShell/PowerShell-RFC 仓库；
2. 以 Draft PR 的形式，把实现原型提交到 PowerShell/PowerShell 仓库。

两个 Draft PR 的目的都是给工作组和其他关心该想法的贡献者一个对设计与实现提供反馈的机会。原文档明确：

• 这两步可以先做任意一步，但两者都是代码被 PowerShell 仓库接受的前提，包括以实验特性形式接受；
• 文档中大写 "Draft" 专指 GitHub 的 Draft Pull Request 功能，团队有意广泛使用 Draft 状态来标记一个想法从提出到实现的生命周期——Draft 是贯穿 issue 讨论、RFC 评审、原型验证的统一状态语言。

RFC 的三阶段生命周期

原文档指出，旧的 RFC 流程用文件夹来推进多阶段状态（Draft → Experimental → Accepted/Final），但这种做法与 PR 评审机制难以调和。引入 GitHub Draft PR 后，受理流程围绕 PR 本身重新组织，RFC 从此只有三个阶段：

1. Draft PR 阶段：RFC 仍在评审期内，公开征求评论，可因社区反馈与顾虑而持续大幅迭代（修订、编辑、回应）；
2. Ready for review 阶段：在至少两个月的讨论期之后，RFC/PR 作者将 PR 标记为 "ready for review"。此时 RFC 进入 Committee 评审队列，讨论 RFC 内容与评论，决定是否值得继续推进。若 Committee 认为 RFC 意图不合理（例如设计存在不可调和的矛盾，或意图与 PowerShell 原则不符），将拒绝该 PR，流程终止；
3. 等待代码合入阶段：多数情况下，Committee 会选择等待代码 PR 以实验特性形式合入，并借助**用户反馈或遥测（telemetry）**来判断 RFC PR 是否应当合并。最后 Committee 选择合并或关闭 RFC PR，分别把 RFC 标记为 accepted 或 rejected。

这条"等代码先飞、看遥测再定稿"的路径是整个治理设计中最有特色的一环，它把设计决策中的不确定性转移到了真实用户的运行数据上。

实验特性：为什么原型是实现先行的强制要求

原文档 "Experiments" 一节给出了原型强制化的理由：

• 实现一个想法常常会暴露出想法成形时未能充分理解的机遇与挑战；
• 一个"简单"的代码改动可能产生深远影响，直到能在可运行代码中实验才能被理解。

因此规则是：在 Committee 考虑接受任何 RFC 之前，必须存在某种形式的实现。贡献者可以编译 PR 分支，在一个可工作的迭代版本上把玩该想法，从而理解特性是否按预期工作、是否真正有价值。

原文档补充了几个执行细节：

• 只要 RFC 已经写好并作为 draft 发布，工作组或 Committee 通常批准将该功能作为实验特性合入，使其能在 preview 发布中以更大使用范围试用；
• 扩大真实世界反馈来源的同时，这还让我们能用遥测来理解用户是否在大量关闭该特性；
• 目前"何时以实验形式合入 PR"是逐案判断的，但原文档预告：随着时间推移，Committee 会就"PR 何时应当以实验形式合并"建立更明确的指引；
• 实验应当完整到足以成为用户体验的合理指示；若特性要求破坏性变更，破坏应当直接在原型中做出，让用户实验该 break 是否造成显著负面影响。

源码印证：实验特性机制在仓库中的落地

文档中"以实验特性形式合入代码、用遥测观察用户是否关闭"的机制，在仓库源码中有完整实现，可以对照验证：

• 核心类型 ExperimentalFeature 定义在 System.Management.Automation 引擎程序集内，每个特性携带 Name、Description、Source（如引擎来源常量 PSEngine）与 Enabled 状态，特性定义处还引用了遥测组件 Microsoft.PowerShell.Telemetry——与文档"用遥测理解用户是否大量关闭该特性"的描述直接对应；
• 面向用户的 cmdlet 实现于同目录下的 GetExperimentalFeatureCommand.cs 与 EnableDisableExperimentalFeatureCommand.cs，即用户可通过 Get-ExperimentalFeature / Enable-ExperimentalFeature 在会话中开关实验特性；
• 当前各平台启用的实验特性清单直接以 JSON 文件形式维护在仓库根目录：experimental-feature-linux.json 列出了 PSFeedbackProvider、PSLoadAssemblyFromNativeCode、PSNativeWindowsTildeExpansion、PSProfileDSCResource、PSSerializeJSONLongEnumAsNumber、PSRedirectToVariable、PSSubsystemPluginModel 等特性，experimental-feature-windows.json 则维护 Windows 侧清单。从这两个文件的差异可以看出"实验特性按平台分批试用"正是该流程的常态形态；
• Pester 测试覆盖了该机制的完整行为，见 EnableDisable-ExperimentalFeature.Tests.ps1、Get-ExperimentalFeature.Tests.ps1 与 ExperimentalFeature.Basic.Tests.ps1，其中资产目录 assets/ExpTest 甚至包含一个用模块形式注册的测试用实验特性（ExpTest.psd1 / ExpTest.psm1 / ExpTest.cs），验证"模块来源"的实验特性同样可被引擎发现。

现有工作组清单与职责范围

原文档将工作组列表指向 working-group-definitions.md，该文档是"列表、描述与成员"的事实来源，按文档骨架完整梳理如下：

工作组	职责范围	典型领域举例
DSC	管理 PowerShell 7 中 DSC 的全部面向	Configuration 关键字等语言特性、PSDesiredStateConfiguration 模块
Developer Experience	模块开发（C#、PowerShell 脚本等）+ 在其他应用/语言运行时中托管 PowerShell 及其 API	与 Windows PowerShell 的向后兼容（PowerShell Standard）、与 .NET CLI 及 VS Code PowerShell 扩展等开发工具集成
Engine	核心 PowerShell 引擎代码的实现与维护	语言解析器、命令与参数绑定器、模块与 Provider 系统（*-Item cmdlets）、性能、组件化、AssemblyLoadContext
Interactive UX	纯交互式体验	控制台、Help 系统、Tab completion/IntelliSense、Markdown 渲染、PSReadLine、调试
Language	PowerShell 语言本身的抽象定义（与 Engine WG 明确区分）	语言决策影响深远，与 Committee 关系最紧密
Remoting	PowerShell Remoting Protocol（PSRP）及之下实现的协议	WinRM、SSH、"pure SSH"（非 PSRP 之上的 SSH）、PowerShell 作业系统（因序列化边界共性）
Cmdlets and Modules	源码在 PowerShell/PowerShell 仓库内的核心/内置模块	新 cmdlet/参数提案、现有 cmdlet 改进与 bugfix、破坏性变更
Security	任何可能有安全影响的 issue 或 PR	提供专业知识、关切与指导

其中两个边界值得强调：

1. Engine WG 不负责定义 PowerShell 语言——语言定义归 Language WG，但许多 issue 预计需要两个 WG 共同输入；
2. Cmdlets WG 只管辖源码在本仓库内的模块。一部分随包分发的模块由其他源码仓库管理、由各自仓库维护者拥有，包括 Microsoft.PowerShell.Archive、PackageManagement（原 OneGet）、PowerShellGet、PSDesiredStateConfiguration（社区仓库同时维护 Gallery 上略有差异的版本，但未来开发应使用该仓库）、PSReadLine、ThreadJob。

明确不设工作组的领域

working-group-definitions.md 还专门列出了"Explicitly not Working Groups"的领域，理由都指向"已有人负责"：

• Build：构建、编译、打包所需的一切——build.psm1、install-powershell.ps1、构建基础设施与自动化、打包脚本与基础设施。理由：Build 不是面向客户的交付物，且本就由 Maintainers 负责，无需纳入 WG 体系。
• Quality：测试代码（Pester 单元测试、xUnit 单元测试）、测试基础设施（Nightlies、CI）、代码覆盖率、Pester。理由：与构建类似，质量由 PowerShell Maintainers 管理。

从仓库结构看，这两块确实由仓库级机制而非某个 WG 目录承载：质量侧对应 test/ 目录下的 Pester 测试、test/xUnit 单元测试与 test/tools/CodeCoverageAutomation 等覆盖率自动化；构建侧对应 tools/ci.psm1、PowerShell.Common.props 等 CI/构建脚本。

工作组成员的日常职责与纪律约束

治理文档 governance.md 的 "Working Group Responsibilities" 一节补充了 WG 成员的权限与行为准则，可与主文档的裁决规则互为印证：

权限边界：WG 成员拥有仓库的 write 权限，但仅限于：

1. 向 master 之外的所有分支 git push；
2. 合并到 master 之外的所有分支的 PR（鉴于 master 是唯一长期存活分支，这不应常见）；
3. 为 issue 分配标签、里程碑与人员。

也就是说，向 master 合入代码的最终权力只在 Maintainers 手中，WG 的裁决权体现为标签、评论与流程推动，而非直接合并。

成员行为准则（DO 部分摘要）：

• 分诊并参与带有 WG-* 标签的 issue 与 PR 讨论；
• 定期与同组沟通，就 issue 是否应推进协调决策；
• 就 issue 是否应继续进入实现或 RFC 阶段作出决策；
• 为 issue 分配正确标签；仅当自己正在处理或实现某个 issue/PR 时才把自己指派上去；
• 评审自己指名下或本 WG 的 PR（即使一切正常也留下 "Looks good to me" / "LGTM" 类评论，让他人知道已有人看过）；
• 确保贡献包含针对所有新增/变更功能的 Pester 测试与文档，鼓励 PR 描述中引用 issue（如 Resolves issue #123）、为 PR 拟有信息量的标题、并符合 编码规范。

唯一的 DON'T：不遵循 RFC 或审批流程就创建新特性、新设计或改变行为。

滥用举报机制：主文档 "Reporting Working Group members abuse" 一节指出，工作组成员多为个人与志愿者，可能存在不当行为、越权或违反 行为准则 的情况，建议通过 GitHub 的 Report Content 机制向维护者举报以触发审查。结合上文"反复未经授权代表工作组发言可能被谴责或移除"的条款，可以看到该体系对"专家权威"的约束是双向的：既赋权（正式 SME 地位），又设问责（consensus 要求、censure、举报通道）。

小结

PowerShell 工作组体系是一套"分诊 → 共识裁决 → 双轨（RFC + 原型）→ 实验验证 → 委员会终裁"的治理流水线：

1. 想法以带输入/输出示例的 issue 起步，由 Maintainers 打上映射到 WG 的 Area 标签完成路由；
2. 能外部原型化的想法被分流到仓库之外做低成本验证，验证成功后可回流重启流程；
3. WG 以内部共识作出"继续/拒绝"裁决，拒绝后可凭充分理由上诉至 Committee（Review-Committee 标签是正式通道）；
4. 通过受理的想法要么走 "RFC Not Required" 快车道（Committee 保留强制补 RFC 的权力，小破坏性变更可加 Review - Committee 标签），要么走 RFC Draft PR + 实现原型 Draft PR 双轨；
5. RFC 经历"Draft PR → 至少两个月讨论后 ready for review → Committee 评审 → 等实验代码合入后凭遥测决定合并/关闭"的阶段演进，其中实验特性的源码实现（ExperimentalFeature.cs 及配套 cmdlet）与 实验特性清单文件 是"遥测决定设计生死"这一设计在仓库中的直接物证。

对于希望向 PowerShell 主仓库贡献新特性的开发者，理解这套流程的实用价值在于：它清楚地告诉你想法会在哪一步被哪个角色拦截、哪些证据（输入/输出示例、外部原型数据、Draft PR 讨论、实验遥测）能帮你走到下一步，以及越权发言或无理由上诉这类行为会被体系如何处理。