尧图网页设计 
PowerShell 仓库 Maintainer 机制全解角色职责、Issue 标签体系与 PR 合并工作流规范【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell本文以 PowerShell 开源仓库的 Maintainer 文档docs/maintainers/README.md为主线系统讲解 Repository Maintainer 的角色定位、强制与禁止性职责、完整的 Issue/PR 标签体系以及从 PR 提交到最终合并的整套评审与合并规范。读完本文你可以完整理解一个 PR 在 PowerShell 仓库中从提交到进入master的全流程、维护者每一步的合规检查点以及仓库中 CODEOWNERS、治理文档等文件如何将这些规范落地。一、Repository Maintainer 是谁角色定位与权限边界根据 docs/maintainers/README.md 的定义Repository Maintainers are trusted stewards of the PowerShell repository responsible for maintaining consistency and quality of PowerShell code. One of their primary responsibilities is merging pull requests after all requirements have been fulfilled.即 Maintainer 是 PowerShell 仓库的受信任守护者负责维护仓库代码的一致性与质量其首要职责就是在所有前置条件满足后合并拉取请求PR。Maintainer 拥有仓库的 write access写权限具体可以向官方 PowerShell 仓库执行git push合并mergePR为 Issue 和 PR 分配标签labels、里程碑milestones和负责人。在 docs/community/governance.md 的治理文档中这一权限的排他性被进一步强调Repository Maintainers 是唯一拥有master分支写权限的人。作为对比Working Group工作组成员可以git push到除master之外的所有分支、合并除master之外的分支上的 PR——因为master是仓库中唯一的长生存分支。也就是说合入主干的权力是 Maintainer 的专属权限这是整个治理体系中权限分层的核心。二、现任与前任 Maintainer 名单以下为 docs/maintainers/README.md 中维护的名单按字母序维护现任 Maintainer姓名用户名Aditya PatwardhanadityapatwardhanAndrew MenagarishvilianmenagaDongbo Wangdaxian-dbwIlya SazonoviSazonovRobert HoltrjmholtTravis PlunkTravisEz13前任 Maintainer姓名用户名Andy JordanandyleejordanJason ShirklzybkrMike RichmondmirichmoSergei Vorobevvors这份名单本身也是一个治理工件新增 Maintainer 时会通过 PR 更新该文件见第七节。三、Maintainer 职责MUST、SHOULD 与 SHOULD NOT 三层义务docs/maintainers/README.md 用 RFC 风格的 MUST / SHOULD / SHOULD NOT 三级义务完整列出了 Maintainer 在快速接受社区贡献与保持高质量之间需要执行的检查点。以下逐条继承并展开。3.1 必须做到MUST遵守并维护行为准则必须遵守 CODE_OF_CONDUCT.md并将疑似违规行为上报 PowerShell Committee。CLA 检查必须确保每位贡献者已签署有效的 Microsoft Contributor License AgreementCLA。第三方代码许可合规如果贡献包含第三方代码必须核对其许可证条款的合规性例如是否要求保留署名 attribution。RFC/审批流程核验必须确保任何需要 PowerShell Committee 审批的变更都已走过正式的 RFC 或审批流程。需要走 RFC 的情形包括新语言特性/新能力、可能造成破坏性变更breaking change的改动、新增核心模块/cmdlet/参数、新增 Committee 成员或 Maintainer、以及维护流程本身的变更。无代码变更也要验证评审合并任何未包含代码变更的 PR如文档、配置调整之前必须验证已经进行过代码评审。新功能的测试与文档合并包含新功能的 PR 之前必须验证测试和文档都已编写。3.2 应当做到SHOULD打正确的标签应当为 Issue 和 PR 添加正确的标签标签体系见第四节。指派 Area Expert应当确保相关的 PR 和 Issue 指派给了正确的 Area Expert包括在合理时追加额外评审人——例如一个增加 remoting 能力的 PR 可能需要安全专家参与评审。身份一致性核验应当验证 git commit 中的姓名与邮箱和提交 PR 的本人身份基本匹配。遵守贡献指南应当确保贡献者遵循贡献者指南.github/CONTRIBUTING.md。纠正目标分支如果 PR 没有以master为目标分支应当要求贡献者重新提交。等待 CI 通过应当等待 CI 系统构建通过后再合并例外PR 本身就是用来修复坏掉的 CI 的。鼓励引用 Issue鼓励贡献者在 PR 描述中引用对应 Issue如Resolves issue #123若用户没有先建 Issue 就直接提 PR不应拒绝但应提醒其今后先建 Issue 以便前置暴露问题、减少重复工作。鼓励有意义的 PR 标题必要时由维护者直接修改标题以清晰表达所解决的问题。鼓励描述性 commit鼓励贡献者写有意义的、描述性的 git commit。3.3 禁止事项SHOULD NOT不得合并 CI 失败的 PR例外该 PR 正是为了修复坏掉的 CI。不得在 CLA bot 状态检查未通过时合并 PR例外CLA bot 本身故障且可通过其他方式确认 CLA 已签署。不得在 PR 提交后过快合并即使 PR 已满足所有要求也应留出时间让他人提供反馈除非该 PR 有特别紧急的原因。不得合并自己的 PR如果 Maintainer 自己开了 PR应由另一位 Maintainer 合并只有在极端且短期的紧急情况下或另一位 Maintainer 已给出明确的sign-off 但不代合授权时才可例外。从治理结构看第 4 条不得自合自 PR与 docs/community/governance.md 中Maintainer 是唯一可以写入master的人相互约束既防止单人集权合并又保留紧急通道。四、Issue 管理完整的标签体系Maintainer 的日常工作之一是 Issue 分诊。完整的标签体系定义在 docs/maintainers/issue-management.md此处完整继承。安全漏洞前置流程如果你认为 PowerShell 存在安全漏洞应先遵循仓库根目录下的漏洞报告策略.github/SECURITY.md之后再提交 Issue。4.1 Issue 分类标签标签含义Issue-Announcement用于讨论项目公告Issue-Bug报告缺陷Issue-Code Cleanup不影响功能性的代码清理Issue-Discussion尚未明确分类可能演化为 RFC也可能被重分类为 bug 或 enhancementIssue-Enhancement更接近功能请求而非 bugIssue-Meta用于跟踪多个 Issue 的元 IssueIssue-Question咨询类问题理想情况下可通过其他支持渠道解决4.2 解决结果标签Resolution-*标签含义Resolution-Answered问题是Issue-Question且已得到解答Resolution-By Design不算 bug行为符合设计Resolution-Duplicate重复问题——必须有评论链接到原始 IssueResolution-External本仓库无法解决需外部处理Resolution-Fixed已修复且应被某个 PR 引用Resolution-Wont Fix可能是 bug 或增强但不修若关闭时解释不充分任何人都可以重新打开该 Issue4.3 功能区域标签Area-*描述 Issue 影响的功能区域Area-Maintainers-Build构建问题Area-Cmdlets-CoreMicrosoft.PowerShell.Core模块中的 cmdletArea-Cmdlets-UtilityMicrosoft.PowerShell.Utility模块中的 cmdletArea-Cmdlets-ManagementMicrosoft.PowerShell.Management模块中的 cmdletArea-Documentation本仓库文档问题通用 PowerShell 文档问题应到独立的文档仓库Area-DSCDSC 相关问题Area-PowerShellGetPowerShellGet 相关问题Area-SideBySide多版本并存支持。4.4 工作组标签WG-*由工作组Working Group定义见 docs/community/working-group-definitions.md负责的区域标签标签覆盖范围WG-DevEx-Portability跨平台、跨架构编写模块/cmdlet/脚本WG-DevEx-SDK以运行时方式托管 PowerShell、PowerShell API、模块与 cmdlet 开发WG-Engine核心引擎、解释器、运行时WG-Engine-Performance核心引擎性能WG-Engine-ProvidersFileSystem、Certificates、Registry 等内置 Provider即Get-PSProvider返回的一切WG-Interactive-Console控制台体验WG-Interactive-DebuggingPowerShell 脚本调试WG-Interactive-HelpSystem帮助基础设施与格式WG-Interactive-IntelliSenseTab 补全WG-Interactive-PSReadlinePSReadline 相关WG-Language解析器、语言语义WG-Quality-Test测试或测试基础设施问题WG-Remoting任意传输层的 PSRP 问题WG-Security安全相关区域4.5 操作系统标签OS-Linux、OS-macOS、OS-Windows、OS-WSLWindows Subsystem for Linux。4.6 PR 流程标签标签含义Review - NeededPR 正在等待/进行评审Review - Waiting on Author团队已评审需要作者修改或回应评论后才能接受Review - Abandoned作者长期未更新具体天数随时间调整Maintainer 应复查并重新评估Review - CommitteePR/Issue 需要 PowerShell Committee 评审4.7 其他常用标签Blocked因外部因素暂时无法处理但因外部因素是暂时的而不关闭BVT/DRT由未开源的测试影响或暴露的问题Changelog NeededPR 需要补记 changelog补充后应移除该标签Committee-Reviewed已经过 PowerShell Committee 评审Compliance合规问题必须在规定期限内修复Issue 中应标明时间框架这是项目作为官方 Microsoft 包持续发布的必要条件Documentation NeededPR 的变更需要同步修改或新增官方文档First-Time-Issue已识别为简单、适合首次贡献者的问题Hackathon/Hacktoberfest适合黑客松等集中开发活动的候选问题Porting影响尚未移植到其他平台的功能Up-for-Grabs已确认但暂无立即处理计划——寻找贡献切入点的好起点Usability用于过滤出因更直接影响某功能可用性而可能优先级更高的 IssueWaiting - DotNetCore等待 .NET Core 侧修复/变更的问题。五、Pull Request 工作流从提交到合并docs/maintainers/README.md 将 PR 工作流指向贡献指南.github/CONTRIBUTING.md 中定义了完整的 PR 生命周期。以下按阶段展开。5.1 提交前Before submitting若变更修复安全漏洞先遵循漏洞报告策略再提交 PR将分支 rebase 到本仓库的master分支避免合并冲突确保现有测试不能有效覆盖被改动代码时补充新测试清理 commit 历史每个 commit 应是单一且完整的变更——这一纪律对评审、git bisect和git revert都很重要。5.2 提交 PRSubmission核心规则PR 永远以master分支为合并目标。其他要点避免过大 PR大 PR 拉长评审时间且更难发现问题应拆分为多个小 PR大型特性宜增量推进每个 PR 不要太大若变更影响用户或开发者体验须记录这些变更文档贡献要求标题要有意义不要直接写 Fix issue #5也不要照抄 Issue 标题——Issue 标题描述哪里错了PR 标题描述改了什么。更好的示例是Add Ensure parameter to New-Item cmdlet并在 PR 正文中写 Fix #5PR 描述用于生成 changelog第一句应解释对最终用户的好处若关联已有 Issue在描述中引用如Fix #11使用现在时 祈使句描述变更不要写 Adding support for Windows Server 2012 R2要写 Add support for Windows Server 2012 R2不要写 Fixed for server connection issue要写 Fix server connection issue若变更针对特定资源用资源名作为描述前缀不写 New parameter ConnectionCredential in New-SqlConnection要写 New-SqlConnection: add parameter ConnectionCredential若变更需要更新用户面向文档Maintainer 会给 PR 加Documentation Needed标签并到官方文档仓库建 Issue 跟进新增源码文件必须带头部版权/许可证注释.cs文件用//风格、.ps1与.psm1文件用#风格注释后空一行新增模块清单.psd1时头部须包含Author PowerShell Company Microsoft Corporation Copyright Copyright (c) Microsoft Corporation.5.3 Work in Progress 约定PR 尚未准备好合并时在标题前加WIP:前缀准备好后移除。5.4 自动检查Automatic Checks首次贡献者可能需要先签署 Microsoft CLACLA bot 会在 PR 上执行状态检查已签署则passing未签署则停留在pending签署一次后该用户所有存量与未来的 PR 检查自动变为passing提交 PR 后CI 系统Azure DevOps Pipelines见 docs/testing-guidelines/testing-guidelines.md会运行测试套件并自动更新 PR 状态CI 包含对 Markdown 的自动拼写检查与链接检查出现误报时可用交互式拼写检查工具把词加入.spelling文件。5.5 评审工作流WorkflowPR 作者从 fork 创建 PR作者确保 CI 构建通过。若构建失败Maintainer 给 PR 加Review - waiting on author标签作者持续更新直到构建通过若作者知道评审对象主动添加否则添加推荐的评审人构建通过后若评审不充分Maintainer 加Review - needed标签Area Expert 也应评审该 PR若不达标评审人留下评论Maintainer 移除Review - needed、改加Review - waiting on author作者必须回应评论后回到第 2 步若达标评审人 ApproveMaintainer 移除need review标签代码评审完成后Maintainer 在评审完成后的一个工作日one business day合并 PR为关键反馈留出窗口。5.6 角色与职责Roles and Responsibilities作者负责推动 PR 走向批准包括及时回应反馈、并添加评论点名具体评审人以表明反馈已被处理。更新 PR 时必须新建 commit不要重写 commit 历史——重写历史会让评审者难以看出各轮迭代间的 diff拖慢评审评审人任何想参与贡献的人都可以。职责是确认代码解决了目标问题、不引入新问题功能、性能、可靠性、安全且设计得当。使用Review changes下拉框表态Request changes认为反馈不解决就不应合并Approve反馈已解决或代码本身没问题附一句 LGTM 是惯例但非必需Comment提出作者可不必须接受的建议。 评审早期可基于公开的编码规范反馈格式问题但 PR 批准后一般不再纠结格式除非违反编码规范非关键的迟来反馈可另行开 Issue 或 PRAssignee被指派人恒为 Maintainer确保发生了充分的评审认为一个批准不够时负责追加评审人。Assignee 可以兼做评审人但两种角色相互独立。PR 获批准且 CI 通过后Assignee 留出一个工作日的关键反馈窗口后合并。5.7 废弃 PR 的处理Pull Requests - Abandoned一个挂着Review - waiting on author标签超过两周且作者毫无音讯的 PR 被视为废弃。处理路径Assignee 先 ping 作者提醒待处理变更若作者回应则不再是废弃流程照常推进若作者一周内仍无回应按情况分支评审意见很轻微合并该变更、立即修好代码再开一个新 PR 处理那些轻微评论修改量大但确有必要Assignee 新建分支承载该变更开 Issue 说明要把代码合入目标分支Issue 描述中注明原 PR 编号然后关闭原废弃 PR变更已不再需要如因重构或设计变更直接关闭该 PR。六、合并 PR 的最佳实践Maintainer Best Practicesdocs/maintainers/best-practice.md 给出了 Maintainer 在评审与合并环节的具体操作规范。6.1 PR 类型Feature-work PR实现某个 RFC 的 PR通常涉及相对大的变更集合Regular PR没有 RFC 支撑的 bug fix 或增强变更。6.2 评审 PR 时的操作要求作者按贡献指南改写 PR 标题必要时让作者给 PR 加[feature]标签以触发完整测试构建视情况给 PR 打Breaking-Change、Documentation Needed、Area-XXX标签给 PR 打Review - Committee标签时留下详细评论总结希望委员会关注的问题建议附示例来解释/演示行为。6.3 选择合并策略默认使用Squash and merge以在master分支上保持干净的 commit 历史仅在 PR 的 commit 历史足够干净时对 Feature-work PR 使用Create a merge commit。注意使用该选项后GitHub 会将其设为你合并 PR 的默认选项记得把默认值改回Squash and merge避免使用Rebase and merge除非你有非常充分的理由。下图为 best-practice 文档中演示两种合并选项的操作截图6.4 点击Confirm之前的三项检查Commit 标题应是 PR 的简短总结使用Squash and merge时PR 标题默认成为 commit 标题——按需改写确保它可直接无修改地用在 CHANGELOG.md 中使用Create a merge commit时默认标题是Merge pull request XXX from YYY——替换为 PR 的简短总结并在末尾加上 PR 编号形如(#1234)扩展描述extended description对 Feature-work PR或含破坏性变更的 Regular PR 是必需的对其他 PR 非必需但由 Maintainer 判断后建议补充。若 PR 引入了相对上一个稳定版的 breaking change扩展描述的第一行必须写[breaking change]标签正文从第二行开始commit 标题与描述都使用现在时 祈使句。七、如何成为 Repository Maintainerdocs/maintainers/README.md 对 Maintainer 的增补流程描述如下现任 Maintainer 目前以 Microsoft 员工为主预期随着时间推移仓库中持续受信任的社区贡献者会陆续成为 Maintainer资格高度取决于贡献水平与专业能力以有意义的方式持续贡献的个人会得到相应认可提名机制在任何时间点现任 Maintainer 可以一致提名unanimously nominate一位优秀的社区成员提名会提交给 PowerShell Committee 听取理由与论证委员会需要简单多数才能否决该提名公开公告方式候选人获批后由一位现任 Maintainer 提交 PR 更新本文档把候选人名字加入 Current Repository Maintainers 名单PR 描述即提名理由兼作公开公告。这一流程本身也体现了文档即治理工件的思路Maintainer 名单的可信来源就是仓库内的这份 Markdown 文件。八、规范如何落地仓库中的治理实现证据上述流程性规范在仓库中均有对应的可检查文件便于 Agent 与开发者按图索骥Area Expert 机制.github/CODEOWNERS 把SHOULD 指派正确 Area Expert的义务落成了路径级规则。例如默认规则*指向PowerShell/powershell-maintainers团队src/System.Management.Automation/security/wldpNativeMethods.csWindows 安全指定安全领域专家src/System.Management.Automation/help帮助系统指定对应 Maintainersrc/System.Management.Automation/engine/parser语言解析器与src/System.Management.Automation/engine/remoting远程处理分别指定相应领域的 Maintainer构建相关路径*.config、*.props、*.yml、*.csproj、build.*、tools/指定 Maintainer 团队与 CI 构建负责人。 这意味着改动 remoting 的 PR 从源码结构上就会被路由给远程处理与安全的领域专家——这正是增加 remoting 能力的 PR 可能需要安全专家这条 SHOULD 义务的自动化载体。PR 生命周期与 CLA完整提交/评审/合并规则在 .github/CONTRIBUTING.md 的 Lifecycle of a pull request 一节委员会与 RFC 流程PowerShell Committee 的组成、需要走 RFC 的变更类型定义在 docs/community/governance.mdCI 系统基于 Azure DevOps 的 CI 体系与测试结果查看方式见 docs/testing-guidelines/testing-guidelines.md仓库 README 顶部的 CI 徽章即指向master分支最近一次构建状态行为准则Maintainer MUST 遵守的准则文本见 CODE_OF_CONDUCT.md从目录结构看仓库的.github/workflows与.github/actions目录表明 CI 流程中还有 GitHub Actions 工作流组件与 CODEOWNERS 中Area: CI Build的评审路由相呼应。九、小结PowerShell 仓库的 Maintainer 体系可以概括为权限上只有 Maintainer 能写入master流程上PR 必须经历 rebase 到master、CLA 检查、CI 通过、充分评审含 Area Expert、一个工作日的反馈窗口后才能合并形式上默认Squash and merge、commit 标题可直接用于 changelog、破坏性变更需以[breaking change]首行标注治理上Maintainer 的产生走现任 Maintainer 一致提名 委员会简单多数否决 PR 公示的透明流程。这些规范与其在 CODEOWNERS、CONTRIBUTING、governance 等文件中的实现共同保证了快速接受贡献与保持主干质量两个目标的平衡。【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PowerShell 仓库 Maintainer 机制全解：角色职责、Issue 标签体系与 PR 合并工作流规范
PowerShell 仓库 Maintainer 机制全解角色职责、Issue 标签体系与 PR 合并工作流规范【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell本文以 PowerShell 开源仓库的 Maintainer 文档docs/maintainers/README.md为主线系统讲解 Repository Maintainer 的角色定位、强制与禁止性职责、完整的 Issue/PR 标签体系以及从 PR 提交到最终合并的整套评审与合并规范。读完本文你可以完整理解一个 PR 在 PowerShell 仓库中从提交到进入master的全流程、维护者每一步的合规检查点以及仓库中 CODEOWNERS、治理文档等文件如何将这些规范落地。一、Repository Maintainer 是谁角色定位与权限边界根据 docs/maintainers/README.md 的定义Repository Maintainers are trusted stewards of the PowerShell repository responsible for maintaining consistency and quality of PowerShell code. One of their primary responsibilities is merging pull requests after all requirements have been fulfilled.即 Maintainer 是 PowerShell 仓库的受信任守护者负责维护仓库代码的一致性与质量其首要职责就是在所有前置条件满足后合并拉取请求PR。Maintainer 拥有仓库的 write access写权限具体可以向官方 PowerShell 仓库执行git push合并mergePR为 Issue 和 PR 分配标签labels、里程碑milestones和负责人。在 docs/community/governance.md 的治理文档中这一权限的排他性被进一步强调Repository Maintainers 是唯一拥有master分支写权限的人。作为对比Working Group工作组成员可以git push到除master之外的所有分支、合并除master之外的分支上的 PR——因为master是仓库中唯一的长生存分支。也就是说合入主干的权力是 Maintainer 的专属权限这是整个治理体系中权限分层的核心。二、现任与前任 Maintainer 名单以下为 docs/maintainers/README.md 中维护的名单按字母序维护现任 Maintainer姓名用户名Aditya PatwardhanadityapatwardhanAndrew MenagarishvilianmenagaDongbo Wangdaxian-dbwIlya SazonoviSazonovRobert HoltrjmholtTravis PlunkTravisEz13前任 Maintainer姓名用户名Andy JordanandyleejordanJason ShirklzybkrMike RichmondmirichmoSergei Vorobevvors这份名单本身也是一个治理工件新增 Maintainer 时会通过 PR 更新该文件见第七节。三、Maintainer 职责MUST、SHOULD 与 SHOULD NOT 三层义务docs/maintainers/README.md 用 RFC 风格的 MUST / SHOULD / SHOULD NOT 三级义务完整列出了 Maintainer 在快速接受社区贡献与保持高质量之间需要执行的检查点。以下逐条继承并展开。3.1 必须做到MUST遵守并维护行为准则必须遵守 CODE_OF_CONDUCT.md并将疑似违规行为上报 PowerShell Committee。CLA 检查必须确保每位贡献者已签署有效的 Microsoft Contributor License AgreementCLA。第三方代码许可合规如果贡献包含第三方代码必须核对其许可证条款的合规性例如是否要求保留署名 attribution。RFC/审批流程核验必须确保任何需要 PowerShell Committee 审批的变更都已走过正式的 RFC 或审批流程。需要走 RFC 的情形包括新语言特性/新能力、可能造成破坏性变更breaking change的改动、新增核心模块/cmdlet/参数、新增 Committee 成员或 Maintainer、以及维护流程本身的变更。无代码变更也要验证评审合并任何未包含代码变更的 PR如文档、配置调整之前必须验证已经进行过代码评审。新功能的测试与文档合并包含新功能的 PR 之前必须验证测试和文档都已编写。3.2 应当做到SHOULD打正确的标签应当为 Issue 和 PR 添加正确的标签标签体系见第四节。指派 Area Expert应当确保相关的 PR 和 Issue 指派给了正确的 Area Expert包括在合理时追加额外评审人——例如一个增加 remoting 能力的 PR 可能需要安全专家参与评审。身份一致性核验应当验证 git commit 中的姓名与邮箱和提交 PR 的本人身份基本匹配。遵守贡献指南应当确保贡献者遵循贡献者指南.github/CONTRIBUTING.md。纠正目标分支如果 PR 没有以master为目标分支应当要求贡献者重新提交。等待 CI 通过应当等待 CI 系统构建通过后再合并例外PR 本身就是用来修复坏掉的 CI 的。鼓励引用 Issue鼓励贡献者在 PR 描述中引用对应 Issue如Resolves issue #123若用户没有先建 Issue 就直接提 PR不应拒绝但应提醒其今后先建 Issue 以便前置暴露问题、减少重复工作。鼓励有意义的 PR 标题必要时由维护者直接修改标题以清晰表达所解决的问题。鼓励描述性 commit鼓励贡献者写有意义的、描述性的 git commit。3.3 禁止事项SHOULD NOT不得合并 CI 失败的 PR例外该 PR 正是为了修复坏掉的 CI。不得在 CLA bot 状态检查未通过时合并 PR例外CLA bot 本身故障且可通过其他方式确认 CLA 已签署。不得在 PR 提交后过快合并即使 PR 已满足所有要求也应留出时间让他人提供反馈除非该 PR 有特别紧急的原因。不得合并自己的 PR如果 Maintainer 自己开了 PR应由另一位 Maintainer 合并只有在极端且短期的紧急情况下或另一位 Maintainer 已给出明确的sign-off 但不代合授权时才可例外。从治理结构看第 4 条不得自合自 PR与 docs/community/governance.md 中Maintainer 是唯一可以写入master的人相互约束既防止单人集权合并又保留紧急通道。四、Issue 管理完整的标签体系Maintainer 的日常工作之一是 Issue 分诊。完整的标签体系定义在 docs/maintainers/issue-management.md此处完整继承。安全漏洞前置流程如果你认为 PowerShell 存在安全漏洞应先遵循仓库根目录下的漏洞报告策略.github/SECURITY.md之后再提交 Issue。4.1 Issue 分类标签标签含义Issue-Announcement用于讨论项目公告Issue-Bug报告缺陷Issue-Code Cleanup不影响功能性的代码清理Issue-Discussion尚未明确分类可能演化为 RFC也可能被重分类为 bug 或 enhancementIssue-Enhancement更接近功能请求而非 bugIssue-Meta用于跟踪多个 Issue 的元 IssueIssue-Question咨询类问题理想情况下可通过其他支持渠道解决4.2 解决结果标签Resolution-*标签含义Resolution-Answered问题是Issue-Question且已得到解答Resolution-By Design不算 bug行为符合设计Resolution-Duplicate重复问题——必须有评论链接到原始 IssueResolution-External本仓库无法解决需外部处理Resolution-Fixed已修复且应被某个 PR 引用Resolution-Wont Fix可能是 bug 或增强但不修若关闭时解释不充分任何人都可以重新打开该 Issue4.3 功能区域标签Area-*描述 Issue 影响的功能区域Area-Maintainers-Build构建问题Area-Cmdlets-CoreMicrosoft.PowerShell.Core模块中的 cmdletArea-Cmdlets-UtilityMicrosoft.PowerShell.Utility模块中的 cmdletArea-Cmdlets-ManagementMicrosoft.PowerShell.Management模块中的 cmdletArea-Documentation本仓库文档问题通用 PowerShell 文档问题应到独立的文档仓库Area-DSCDSC 相关问题Area-PowerShellGetPowerShellGet 相关问题Area-SideBySide多版本并存支持。4.4 工作组标签WG-*由工作组Working Group定义见 docs/community/working-group-definitions.md负责的区域标签标签覆盖范围WG-DevEx-Portability跨平台、跨架构编写模块/cmdlet/脚本WG-DevEx-SDK以运行时方式托管 PowerShell、PowerShell API、模块与 cmdlet 开发WG-Engine核心引擎、解释器、运行时WG-Engine-Performance核心引擎性能WG-Engine-ProvidersFileSystem、Certificates、Registry 等内置 Provider即Get-PSProvider返回的一切WG-Interactive-Console控制台体验WG-Interactive-DebuggingPowerShell 脚本调试WG-Interactive-HelpSystem帮助基础设施与格式WG-Interactive-IntelliSenseTab 补全WG-Interactive-PSReadlinePSReadline 相关WG-Language解析器、语言语义WG-Quality-Test测试或测试基础设施问题WG-Remoting任意传输层的 PSRP 问题WG-Security安全相关区域4.5 操作系统标签OS-Linux、OS-macOS、OS-Windows、OS-WSLWindows Subsystem for Linux。4.6 PR 流程标签标签含义Review - NeededPR 正在等待/进行评审Review - Waiting on Author团队已评审需要作者修改或回应评论后才能接受Review - Abandoned作者长期未更新具体天数随时间调整Maintainer 应复查并重新评估Review - CommitteePR/Issue 需要 PowerShell Committee 评审4.7 其他常用标签Blocked因外部因素暂时无法处理但因外部因素是暂时的而不关闭BVT/DRT由未开源的测试影响或暴露的问题Changelog NeededPR 需要补记 changelog补充后应移除该标签Committee-Reviewed已经过 PowerShell Committee 评审Compliance合规问题必须在规定期限内修复Issue 中应标明时间框架这是项目作为官方 Microsoft 包持续发布的必要条件Documentation NeededPR 的变更需要同步修改或新增官方文档First-Time-Issue已识别为简单、适合首次贡献者的问题Hackathon/Hacktoberfest适合黑客松等集中开发活动的候选问题Porting影响尚未移植到其他平台的功能Up-for-Grabs已确认但暂无立即处理计划——寻找贡献切入点的好起点Usability用于过滤出因更直接影响某功能可用性而可能优先级更高的 IssueWaiting - DotNetCore等待 .NET Core 侧修复/变更的问题。五、Pull Request 工作流从提交到合并docs/maintainers/README.md 将 PR 工作流指向贡献指南.github/CONTRIBUTING.md 中定义了完整的 PR 生命周期。以下按阶段展开。5.1 提交前Before submitting若变更修复安全漏洞先遵循漏洞报告策略再提交 PR将分支 rebase 到本仓库的master分支避免合并冲突确保现有测试不能有效覆盖被改动代码时补充新测试清理 commit 历史每个 commit 应是单一且完整的变更——这一纪律对评审、git bisect和git revert都很重要。5.2 提交 PRSubmission核心规则PR 永远以master分支为合并目标。其他要点避免过大 PR大 PR 拉长评审时间且更难发现问题应拆分为多个小 PR大型特性宜增量推进每个 PR 不要太大若变更影响用户或开发者体验须记录这些变更文档贡献要求标题要有意义不要直接写 Fix issue #5也不要照抄 Issue 标题——Issue 标题描述哪里错了PR 标题描述改了什么。更好的示例是Add Ensure parameter to New-Item cmdlet并在 PR 正文中写 Fix #5PR 描述用于生成 changelog第一句应解释对最终用户的好处若关联已有 Issue在描述中引用如Fix #11使用现在时 祈使句描述变更不要写 Adding support for Windows Server 2012 R2要写 Add support for Windows Server 2012 R2不要写 Fixed for server connection issue要写 Fix server connection issue若变更针对特定资源用资源名作为描述前缀不写 New parameter ConnectionCredential in New-SqlConnection要写 New-SqlConnection: add parameter ConnectionCredential若变更需要更新用户面向文档Maintainer 会给 PR 加Documentation Needed标签并到官方文档仓库建 Issue 跟进新增源码文件必须带头部版权/许可证注释.cs文件用//风格、.ps1与.psm1文件用#风格注释后空一行新增模块清单.psd1时头部须包含Author PowerShell Company Microsoft Corporation Copyright Copyright (c) Microsoft Corporation.5.3 Work in Progress 约定PR 尚未准备好合并时在标题前加WIP:前缀准备好后移除。5.4 自动检查Automatic Checks首次贡献者可能需要先签署 Microsoft CLACLA bot 会在 PR 上执行状态检查已签署则passing未签署则停留在pending签署一次后该用户所有存量与未来的 PR 检查自动变为passing提交 PR 后CI 系统Azure DevOps Pipelines见 docs/testing-guidelines/testing-guidelines.md会运行测试套件并自动更新 PR 状态CI 包含对 Markdown 的自动拼写检查与链接检查出现误报时可用交互式拼写检查工具把词加入.spelling文件。5.5 评审工作流WorkflowPR 作者从 fork 创建 PR作者确保 CI 构建通过。若构建失败Maintainer 给 PR 加Review - waiting on author标签作者持续更新直到构建通过若作者知道评审对象主动添加否则添加推荐的评审人构建通过后若评审不充分Maintainer 加Review - needed标签Area Expert 也应评审该 PR若不达标评审人留下评论Maintainer 移除Review - needed、改加Review - waiting on author作者必须回应评论后回到第 2 步若达标评审人 ApproveMaintainer 移除need review标签代码评审完成后Maintainer 在评审完成后的一个工作日one business day合并 PR为关键反馈留出窗口。5.6 角色与职责Roles and Responsibilities作者负责推动 PR 走向批准包括及时回应反馈、并添加评论点名具体评审人以表明反馈已被处理。更新 PR 时必须新建 commit不要重写 commit 历史——重写历史会让评审者难以看出各轮迭代间的 diff拖慢评审评审人任何想参与贡献的人都可以。职责是确认代码解决了目标问题、不引入新问题功能、性能、可靠性、安全且设计得当。使用Review changes下拉框表态Request changes认为反馈不解决就不应合并Approve反馈已解决或代码本身没问题附一句 LGTM 是惯例但非必需Comment提出作者可不必须接受的建议。 评审早期可基于公开的编码规范反馈格式问题但 PR 批准后一般不再纠结格式除非违反编码规范非关键的迟来反馈可另行开 Issue 或 PRAssignee被指派人恒为 Maintainer确保发生了充分的评审认为一个批准不够时负责追加评审人。Assignee 可以兼做评审人但两种角色相互独立。PR 获批准且 CI 通过后Assignee 留出一个工作日的关键反馈窗口后合并。5.7 废弃 PR 的处理Pull Requests - Abandoned一个挂着Review - waiting on author标签超过两周且作者毫无音讯的 PR 被视为废弃。处理路径Assignee 先 ping 作者提醒待处理变更若作者回应则不再是废弃流程照常推进若作者一周内仍无回应按情况分支评审意见很轻微合并该变更、立即修好代码再开一个新 PR 处理那些轻微评论修改量大但确有必要Assignee 新建分支承载该变更开 Issue 说明要把代码合入目标分支Issue 描述中注明原 PR 编号然后关闭原废弃 PR变更已不再需要如因重构或设计变更直接关闭该 PR。六、合并 PR 的最佳实践Maintainer Best Practicesdocs/maintainers/best-practice.md 给出了 Maintainer 在评审与合并环节的具体操作规范。6.1 PR 类型Feature-work PR实现某个 RFC 的 PR通常涉及相对大的变更集合Regular PR没有 RFC 支撑的 bug fix 或增强变更。6.2 评审 PR 时的操作要求作者按贡献指南改写 PR 标题必要时让作者给 PR 加[feature]标签以触发完整测试构建视情况给 PR 打Breaking-Change、Documentation Needed、Area-XXX标签给 PR 打Review - Committee标签时留下详细评论总结希望委员会关注的问题建议附示例来解释/演示行为。6.3 选择合并策略默认使用Squash and merge以在master分支上保持干净的 commit 历史仅在 PR 的 commit 历史足够干净时对 Feature-work PR 使用Create a merge commit。注意使用该选项后GitHub 会将其设为你合并 PR 的默认选项记得把默认值改回Squash and merge避免使用Rebase and merge除非你有非常充分的理由。下图为 best-practice 文档中演示两种合并选项的操作截图6.4 点击Confirm之前的三项检查Commit 标题应是 PR 的简短总结使用Squash and merge时PR 标题默认成为 commit 标题——按需改写确保它可直接无修改地用在 CHANGELOG.md 中使用Create a merge commit时默认标题是Merge pull request XXX from YYY——替换为 PR 的简短总结并在末尾加上 PR 编号形如(#1234)扩展描述extended description对 Feature-work PR或含破坏性变更的 Regular PR 是必需的对其他 PR 非必需但由 Maintainer 判断后建议补充。若 PR 引入了相对上一个稳定版的 breaking change扩展描述的第一行必须写[breaking change]标签正文从第二行开始commit 标题与描述都使用现在时 祈使句。七、如何成为 Repository Maintainerdocs/maintainers/README.md 对 Maintainer 的增补流程描述如下现任 Maintainer 目前以 Microsoft 员工为主预期随着时间推移仓库中持续受信任的社区贡献者会陆续成为 Maintainer资格高度取决于贡献水平与专业能力以有意义的方式持续贡献的个人会得到相应认可提名机制在任何时间点现任 Maintainer 可以一致提名unanimously nominate一位优秀的社区成员提名会提交给 PowerShell Committee 听取理由与论证委员会需要简单多数才能否决该提名公开公告方式候选人获批后由一位现任 Maintainer 提交 PR 更新本文档把候选人名字加入 Current Repository Maintainers 名单PR 描述即提名理由兼作公开公告。这一流程本身也体现了文档即治理工件的思路Maintainer 名单的可信来源就是仓库内的这份 Markdown 文件。八、规范如何落地仓库中的治理实现证据上述流程性规范在仓库中均有对应的可检查文件便于 Agent 与开发者按图索骥Area Expert 机制.github/CODEOWNERS 把SHOULD 指派正确 Area Expert的义务落成了路径级规则。例如默认规则*指向PowerShell/powershell-maintainers团队src/System.Management.Automation/security/wldpNativeMethods.csWindows 安全指定安全领域专家src/System.Management.Automation/help帮助系统指定对应 Maintainersrc/System.Management.Automation/engine/parser语言解析器与src/System.Management.Automation/engine/remoting远程处理分别指定相应领域的 Maintainer构建相关路径*.config、*.props、*.yml、*.csproj、build.*、tools/指定 Maintainer 团队与 CI 构建负责人。 这意味着改动 remoting 的 PR 从源码结构上就会被路由给远程处理与安全的领域专家——这正是增加 remoting 能力的 PR 可能需要安全专家这条 SHOULD 义务的自动化载体。PR 生命周期与 CLA完整提交/评审/合并规则在 .github/CONTRIBUTING.md 的 Lifecycle of a pull request 一节委员会与 RFC 流程PowerShell Committee 的组成、需要走 RFC 的变更类型定义在 docs/community/governance.mdCI 系统基于 Azure DevOps 的 CI 体系与测试结果查看方式见 docs/testing-guidelines/testing-guidelines.md仓库 README 顶部的 CI 徽章即指向master分支最近一次构建状态行为准则Maintainer MUST 遵守的准则文本见 CODE_OF_CONDUCT.md从目录结构看仓库的.github/workflows与.github/actions目录表明 CI 流程中还有 GitHub Actions 工作流组件与 CODEOWNERS 中Area: CI Build的评审路由相呼应。九、小结PowerShell 仓库的 Maintainer 体系可以概括为权限上只有 Maintainer 能写入master流程上PR 必须经历 rebase 到master、CLA 检查、CI 通过、充分评审含 Area Expert、一个工作日的反馈窗口后才能合并形式上默认Squash and merge、commit 标题可直接用于 changelog、破坏性变更需以[breaking change]首行标注治理上Maintainer 的产生走现任 Maintainer 一致提名 委员会简单多数否决 PR 公示的透明流程。这些规范与其在 CODEOWNERS、CONTRIBUTING、governance 等文件中的实现共同保证了快速接受贡献与保持主干质量两个目标的平衡。【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考