PowerShell 工作小组（Working Group）职责全解：从 Issue 分诊到 RFC 共识的工程化治理

PowerShell 仓库采用“工作小组（Working Group，WG）”作为技术治理的基本单元：每个 WG 拥有一块明确的代码领地，负责该领域的 issue 分诊、代码审查与 RFC 讨论。本文以 working-group-definitions.md 为核心骨架，逐一梳理仓库中 8 个 WG 的边界定义与成员构成，说明“哪些领域明确不设 WG”，并结合 working-group.md 与 governance.md 解释 WG 在 Issue 分诊、共识决策与 RFC 评审中的实际作用，最后把每个 WG 的职责映射到本仓库真实的源码目录，帮助读者判断“一个问题该找谁”。

1. 什么是工作小组，它在治理体系中处于什么位置

按 working-group.md 的定义，Working Group 是“对 PowerShell 特定组件或技术有深入知识的贡献者集合”，其职责是 issue 分诊/接受、代码审查，以及在 issues、PR 和 RFC 讨论中提供专业意见。它不是独立决策机构，而是与两类角色协同：

• Repository Maintainers：仓库的受信任管理者，负责在所有要求满足后合并 PR，是 master 分支的唯一写权限持有者（见 governance.md）。
• PowerShell Committee：负责设计决策，主要通过投票接受或否决 RFC 文档来治理项目；WG 成员可能与委员会共享成员，且语言类 WG 通常与委员会协作最紧密。

WG 对仓库拥有写权限，但受到明确限制：可以 git push 到 master 以外的所有分支、合并除 master 以外的分支上的 PR、给 issues 分配标签/里程碑/负责人。也就是说，WG 可以驱动绝大多数开发流程，但最终合入 master 仍由 Maintainer 完成。

委员会设计 WG 机制时的四个目标是：在不牺牲稳定性的前提下提高创新速度；减少贡献者在不可行 PR/RFC 上浪费的时间；提升领域专家（无论是否在 Microsoft 内部）的正式话语权；降低需要委员会出面主持的技术讨论数量。

一个 idea 进入 WG 处理后的典型流转（见 working-group.md）：

1. 贡献者提交描述想法的 issue（含动机、用例、期望输入输出示例）；
2. Maintainer 将其分诊为 Area label，标签映射到一个或多个 WG；
3. WG 参与可行性讨论后做出判断：
   • 拒绝：流程终止。贡献者认为理由不充分时，可以 @PowerShell/PowerShell-Committee 上诉，由 Maintainer 加上 Review-Committee 标签重开 issue；
   • RFC Not Required：小组判定想法小而简单，可直接进入代码 PR 阶段；委员会保留对“免 RFC”问题强制要求 RFC 的权力；
   • RFC/Prototype 双轨：有显著设计影响且无法在仓库外原型的想法，必须同时提交 RFC（Draft PR 到 PowerShell-RFC 仓库）与实现原型（Draft PR 到本仓库），RFC 至少经过两个月讨论后才能标记为 ready for review 进入委员会评审队列。

下文按原文档顺序逐个展开每个 WG 的定义。

2. DSC 工作小组：把 Desired State Configuration 当作“语言特性”来治理

原文档对 DSC WG 的定位非常明确：它管理 PowerShell 7 中 DSC 的所有方面，包括语言特性（如 Configuration 关键字）和 PSDesiredStateConfiguration 模块。原文特别强调：“DSC 现在已经整合进 PowerShell 语言本身，因此需要按此方式（即语言级组件）来管理它”——这正是它单独设组的原因：DSC 的改动既涉及语言解析，又涉及模块行为。

从源码结构可以印证这一“语言级整合”：

• Configuration 关键字由引擎解析器直接处理。在 Parser.cs 中，TokenKind.Configuration 分支进入 ConfigurationStatementRule 方法（约第 2893 行起）：它先校验配置名（缺失配置名、非法命名都会通过 ParserStrings 报错），随后在解析期加载 DSC 系统类并导入为关键字，并对受限场景显式报错——例如 ConstrainedLanguage 模式下不允许 Configuration 关键字（受 WDAC 策略审计例外影响）、ARM/ARM64 架构下不支持。
• 配置语法块与节点块等语法树节点定义在 ast.cs 中，DSC 专用解析支持位于 CimDSCParser.cs。

因此，凡是涉及 Configuration 关键字语法、节点语法或 ConstrainedLanguage 下 DSC 行为的 issue，按此定义都归 DSC WG 管辖，而不是泛泛地归给引擎组。

成员

• @TravisEz13
• @theJasonHelmick
• @anmenaga
• @gaelcolas
• @michaeltlombardi
• @SteveL-MSFT

3. Developer Experience 工作小组：模块开发 + 宿主集成

DevEx WG 覆盖两大类体验：

• 模块（module）的开发，包括 C#、PowerShell 脚本等形态；
• 在其他应用程序和语言运行时中宿主化 PowerShell 及其 API 的体验。

原文档还点名了两类需要特别关注的主题：与 Windows PowerShell 的向后兼容（例如 PowerShell Standard），以及与周边开发工具的集成（如 .NET CLI、Visual Studio Code 的 PowerShell 扩展）。

对应到仓库实体：Microsoft.PowerShell.SDK 项目即由 SDK 方向负责人关注的宿主化入口——它是一个元项目，一方面聚合 PowerShell 各子项目以避免重复的引用声明，另一方面打包 PowerShell 运行时必须提供给用户的额外 .NET Core 依赖包；托管方还可以参考 docs/hosting-powershell/README.md。

成员

• @JamesWTruher（PS Standard、模块编写）
• @adityapatwardhan（SDK）
• @michaeltlombardi
• @SeeminglyScience
• @bergmeister

4. Engine 工作小组：核心引擎代码的实现与维护

Engine WG 的职责聚焦于核心 PowerShell 引擎代码的实现与维护。原文档给出的范围清单（非穷尽）是：

• 语言解析器（language parser）
• 命令绑定器与参数绑定器（command and parameter binders）
• 模块与 Provider 系统
  • *-Item cmdlets
  • Providers
• 性能（Performance）
• 组件化（Componentization）
• AssemblyLoadContext

这一清单与本仓库的目录结构高度吻合：

职责项	对应仓库位置
语言解析器	engine/parser/
命令/参数绑定	CommandProcessorBase.cs、ParameterBinderBase.cs、ReflectionParameterBinder.cs、NativeCommandParameterBinder.cs 等
模块系统	engine/Modules/
Provider 系统	namespaces/（如 FileSystemProvider.cs、RegistryProvider.cs）
AssemblyLoadContext	CorePsAssemblyLoadContext.cs

原文档还划了一条重要边界：Engine WG 不负责 PowerShell 语言的定义，语言定义归 Language WG；但许多 issue 需要两个 WG 共同给出意见。这条边界在实践中的意义是：修 bug、做性能优化找 Engine；改语言语义、加语法特性找 Language。

成员

• @daxian-dbw
• @JamesWTruher
• @rkeithhill
• @vexx32
• @SeeminglyScience
• @IISResetMe
• @powercode
• @kilasuit

5. Interactive UX 工作小组：只属于交互场景的体验问题

虽然 PowerShell 的多数能力既可交互使用也可脚本化使用，但一部分体验是“纯交互”的。Interactive UX WG 负责的主题（非穷尽）包括：

• 控制台（Console）
• 帮助系统（Help System）
• Tab 补全 / IntelliSense
• Markdown 渲染
• PSReadLine
• 调试（Debugging）

其中大部分能力在本仓库中有直接对应的实现目录，便于按此划分归属：帮助系统主体位于 src/System.Management.Automation/help/（含 HelpSystem.cs、UpdatableHelpSystem.cs、UpdateHelpCommand.cs、SaveHelpCommand.cs 等）；调试相关逻辑位于 engine/debugger/；交互式控制台宿主位于 Microsoft.PowerShell.ConsoleHost。而 PSReadLine 模块本身托管在其他源码仓库（见第 8 节“外部托管模块”清单），其 issue 在本仓库内对应 WG-Interactive-PSReadline 标签。

成员

• @theJasonHelmick
• @daxian-dbw（PSReadline / IntelliSense）
• @adityapatwardhan（Markdown / 帮助系统）
• @JamesWTruher（cmdlet 设计）
• @SeeminglyScience
• @sdwheeler
• @kilasuit
• @FriedrichWeinmann
• @StevenBucher98

6. Language 工作小组：只关心语言的“抽象定义”

Language WG 与 Engine WG 的区别在于：前者处理 PowerShell 语言本身的抽象定义（语法、语义、语言规范层面的决策），后者处理引擎代码的实现与维护。原文档特别指出：虽然所有 WG 都会与 PowerShell Committee 密切协作（且可能共享成员），但 Language WG 与委员会的协作预计尤其紧密——因为语言决策的长期影响最大。这也与 governance.md 中“新语言特性（如 PowerShell 类、PSRP over SSH 等）必须走 RFC”的规则一致。

从分工看，解析器中的语法文法实现（如 Parser.cs 里以 G 注释标注的 grammar 规则）属于 Engine WG 的实现工作，而“该不该这样定义语法”这类决策属于 Language WG 与委员会的范畴。

成员

• @JamesWTruher
• @daxian-dbw
• @SeeminglyScience

7. Remoting 工作小组：PSRP、传输协议与作业系统

Remoting WG 聚焦三类主题：

1. PowerShell Remoting Protocol（PSRP） 本身；
2. PSRP 之下实现的协议，例如 WinRM 和 SSH；
3. 其他用于远程的协议（例如不走 PSRP 的“pure SSH”）。

此外，原文档基于一个工程事实扩展了职责边界：由于序列化边界（serialization boundaries）是共通的，PowerShell 作业系统（job system）也由 Remoting WG 关注。

本仓库中远程实现的源码集中于 src/System.Management.Automation/engine/remoting/（约 96 个文件），WS-Management 相关组件则位于 Microsoft.WSMan.Management 与 Microsoft.WSMan.Runtime，测试侧还有 test/SSHRemoting/SSHRemoting.Basic.Tests.ps1。涉及 PSRP 语义、SSH/WinRM 传输、作业序列化行为的改动都应路由到该 WG（对应 WG-Remoting 标签）。

成员

• @anmenaga
• @TravisEz13

8. Cmdlets and Modules 工作小组：区分“仓库内模块”与“外部托管模块”

Cmdlet WG 负责源码位于 PowerShell/PowerShell 仓库内的核心/内置（inbox）模块，范围包括：

• 新 cmdlet 与新参数的提案；
• 现有 cmdlet/参数的改进与缺陷修复；
• 破坏性变更（breaking changes）。

本仓库中对应的主要源码目录包括：Microsoft.PowerShell.Commands.Utility（utility cmdlets）、Microsoft.PowerShell.Commands.Management（management cmdlets）、Microsoft.PowerShell.Commands.Diagnostics（diagnostics cmdlets）、Microsoft.PowerShell.Security（证书、签名、凭据等安全 cmdlet），以及用于 Windows 的 Microsoft.Management.Infrastructure.CimCmdlets（Cim* cmdlets）。

同时，原文档明确列出了随 PowerShell 发行包分发、但由其他源码仓库维护的模块——这些模块归各自仓库的维护者所有，不属于 Cmdlet WG 的管理范围：

• Microsoft.PowerShell.Archive
• PackageManagement（原 OneGet）
• PowerShellGet
• PSDesiredStateConfiguration（注意：社区仓库维护的是 Gallery 上略有差异的版本，但应作为该模块未来开发的来源）
• PSReadLine
• ThreadJob

这一边界在提 issue 时很关键：例如 PSReadLine 的 bug 虽然挂着 WG-Interactive-PSReadline 标签由本仓库跟踪，但代码改动发生在 PSReadLine 的独立仓库。

成员

• @JamesWTruher
• @SteveL-MSFT
• @jdhitsolutions
• @TobiasPSP
• @doctordns
• @kilasuit

9. Security 工作小组：以“被咨询者”身份介入安全相关问题

Security WG 的组织方式与其他 WG 略有不同：它不是按固定代码领地划分，而是在一切可能涉及安全影响的 issue 或 PR 中被引入，提供专业意见、关切与指导。也就是说，其他 WG 的 PR 如果触及安全面（如凭据处理、签名、执行策略、JEA 相关行为），都应征询 Security WG。

成员

• @TravisEz13
• @SydneySmithReal
• @anamnavi
• @SteveL-MSFT

10. 明确不设 WG 的领域：Build 与 Quality

原文档为了完整性，还列出了 PowerShell 中明确不设 WG 的领域：

Build

Build 涵盖构建、编译、打包 PowerShell 所需的一切。它不是面向客户的交付物，且已经由 Maintainers 处理，因此不需要纳入 WG 体系：

• Build
  • build.psm1
  • install-powershell.ps1
  • 构建基础设施与自动化
• Packaging
  • 脚本
  • 基础设施

本仓库中可以看到对应的实体：tools/packaging/packaging.psm1、tools/install-powershell.sh、tools/install-powershell.ps1、tools/ci.psm1 等构建与打包脚本。

Quality

与 Build 类似，质量（包括测试代码、测试基础设施、代码覆盖率）应由 PowerShell Maintainers 管理：

• 测试代码
  • Pester 单元测试
  • xUnit 单元测试
• 测试基础设施
  • Nightlies
  • CI
• 代码覆盖率
• Pester

仓库中 test/ 目录即为这一领域的落地：Pester 功能测试按 Language/Modules/engine/Provider 等组织（如 test/powershell/Language/），xUnit 测试位于 test/xUnit/，编写 Pester 测试的规范可参考 docs/testing-guidelines/WritingPesterTests.md 与 docs/testing-guidelines/testing-guidelines.md。

11. 如何使用这份定义：从 Issue 标签反查归属

working-group-definitions 与 issue 管理流程是通过标签衔接的。原文档指明：最新的 WG 关联 issue/PR 标签清单见 issue-management.md。该文档中 WG-* 前缀的功能区标签与本文各 WG 的对应关系如下：

标签	归属 WG	覆盖范围
Area-DSC	DSC	DSC 相关问题
WG-DevEx-Portability	Developer Experience	跨平台/跨架构模块、cmdlet、脚本编写
WG-DevEx-SDK	Developer Experience	宿主化 PowerShell、PowerShell API、PowerShell Standard、模块/cmdlet 开发
WG-Engine	Engine	核心引擎、解释器、运行时
WG-Engine-Performance	Engine	引擎/解释器/运行时性能
WG-Engine-Providers	Engine	FileSystem、Certificates、Registry 等内置 Provider（Get-PSProvider 可见者）
WG-Interactive-Console	Interactive UX	控制台体验
WG-Interactive-Debugging	Interactive UX	脚本调试
WG-Interactive-HelpSystem	Interactive UX	帮助基础设施与帮助格式
WG-Interactive-IntelliSense	Interactive UX	Tab 补全
WG-Interactive-PSReadline	Interactive UX	PSReadLine
WG-Language	Language	解析器、语言语义
WG-Quality-Test	（Maintainers 管辖）	测试代码与测试基础设施
WG-Remoting	Remoting	任意传输层的 PSRP 问题
WG-Security	Security	JEA 等安全相关领域

此外还有一批非 WG 的 Area-* 标签（如 Area-Cmdlets-Core、Area-Cmdlets-Utility、Area-Cmdlets-Management、Area-Documentation、Area-PowerShellGet、Area-SideBySide），用于描述 issue 影响的功能区。PR 侧则使用 Review - Needed、Review - Waiting on Author、Review - Abandoned、Review - Committee 等流程标签；其中 Review - Committee 表示需要 PowerShell 委员会评审，与第 1 节“WG 判定免 RFC 但 Maintainer 或 WG 可加标签请求委员会意见”的流程相对应。

对贡献者的实际意义是：提交 issue 前先按其功能面理解标签命名，即可预判它会被路由给哪个 WG、由哪些成员参与讨论；而 WG 成员的行为准则（对 WG-* 标签 issue 的分诊、与成员沟通协调、决定是否推进、代码审查并留下“LGTM”式结论、确保贡献包含 Pester 测试与文档等 DO/DON'T 清单）见 working-group.md 与 governance.md。若 WG 成员行为越权或不当，治理文档建议通过平台的举报机制提交给 Maintainers 处理。

12. 小结：一套“按代码领地划分、按标签路由”的责任体系

回到 working-group-definitions.md 的核心信息：

• 8 个 WG：DSC、Developer Experience、Engine、Interactive UX、Language、Remoting、Cmdlets and Modules、Security，各自拥有清晰的职责边界（如“语言定义归 Language，引擎实现归 Engine”“仓库内 cmdlet 归 Cmdlet WG，外部仓库模块归各自维护者”）。
• 2 个明确不设 WG 的领域：Build 与 Quality，均由 Maintainers 直接负责。
• 与治理流程的衔接：issue 的 Area/WG 标签是分诊路由的钥匙；WG 负责分诊、讨论、接受或拒绝提案，重大决策上升到委员会；“RFC Not Required”与“RFC + 原型”双轨制决定了想法进入代码的两种路径。

理解这套划分后，无论是判断某个 PR 应由谁审查、某个 issue 该贴哪个标签，还是评估自己提交的改动会触及哪些 WG 的领域，都可以从“代码落在哪个目录、语义属于哪个功能面”反推出正确答案——这正是本文把每个 WG 的职责映射到本仓库真实源码目录的目的所在。