为 PowerToys 贡献

相关源文件

• .github/ISSUE_TEMPLATE/bug_report.yml
• .github/ISSUE_TEMPLATE/config.yml
• .github/ISSUE_TEMPLATE/documentation-issue.yml
• .github/ISSUE_TEMPLATE/feature_request.yml
• .github/ISSUE_TEMPLATE/translation_issue.yml
• .github/policies/resourceManagement.yml
• .github/pull_request_template.md
• CONTRIBUTING.md
• SUPPORT.md
• doc/devdocs/akaLinks.md
• doc/devdocs/localization.md
• doc/devdocs/modules/keyboardmanager/keyboardeventhandlers.md
• doc/devdocs/modules/keyboardmanager/keyboardmanager.md
• doc/devdocs/modules/keyboardmanager/keyboardmanagercommon.md
• doc/devdocs/modules/keyboardmanager/keyboardmanagerui.md
• src/modules/keyboardmanager/KeyboardManagerEngineTest/MockedInput.cpp
• src/modules/keyboardmanager/KeyboardManagerEngineTest/MockedInput.h

本文档涵盖了 PowerToys 的完整贡献流程，从提交 issue 到提交 pull request，以及对管理社区贡献的自动化工作流的理解。它概述了确保维护者和贡献者之间高效协作所需的步骤、模板和流程。

有关从源代码构建和设置开发环境的信息，请参阅从源代码构建。有关创建新的 PowerToys 模块的指导，请参阅创建新的 PowerToy。

Issue 提交和分类流程

PowerToys 使用结构化的 issue 提交流程，并带有特定的模板，以确保一致的信息收集和高效的分类。所有贡献都必须在任何开发工作开始前，先提交一个 issue。

Issue 模板和类别

项目提供了四个主要 issue 模板，用于捕获不同类型的贡献

bug_report 模板捕获全面的诊断信息，包括版本详细信息、安装方法和受影响的具体 PowerToys 实用程序。它支持从 FancyZones 到 Workspaces 和 ZoomIt 等最新模块的所有主要实用程序。

来源： .github/ISSUE_TEMPLATE/bug_report.yml1-126 .github/ISSUE_TEMPLATE/feature_request.yml1-28 .github/ISSUE_TEMPLATE/translation_issue.yml1-83 .github/ISSUE_TEMPLATE/documentation-issue.yml1-13

Issue 分类和标签

通过模板和自动化策略的组合，对 Issue 进行自动标记和分类

来源： .github/ISSUE_TEMPLATE/bug_report.yml3-6 .github/ISSUE_TEMPLATE/translation_issue.yml4-8 .github/policies/resourceManagement.yml70-76

开发工作流和协议流程

PowerToys 遵循一种结构化方法，强调在实施解决方案之前先理解问题。此流程可确保开发工作高效定向并与项目目标保持一致。

开发前协议流程

在开发开始之前，团队需要就三个关键方面达成一致

1. 问题验证 - 这是值得解决的问题吗？
2. 适用性评估 - 这属于 PowerToys 吗？
3. 解决方案方法 - 拟议的实施是否正确？

对于较大的功能，需要一个规范文档来概述方法，并允许在开始编码之前进行协作式设计讨论。

来源： CONTRIBUTING.md1-8 CONTRIBUTING.md42-47

“求帮助”标签和社区参与

已批准但缺乏即时开发者可用性的 issue 被标记为“求帮助”。贡献者可以通过 GitHub 标签系统找到开发机会

来源： CONTRIBUTING.md48-51 CONTRIBUTING.md36-37

Pull Request 流程和要求

Pull Request 必须遵循一个全面的清单，以确保代码质量、本地化支持以及与构建系统的正确集成。

Pull Request 模板和清单

PR 模板包含多个类别的强制性检查

此清单确保新二进制文件正确集成到签名管道、安装程序和 CI/CD 工作流中。这可以防止构建失败并确保安全合规。

来源： .github/pull_request_template.md1-25

验证要求

Pull Request 必须包含正确的验证步骤，以证明更改可以正常工作

验证类型	要求
自动化测试	所有现有测试通过，为新功能添加了新测试
手动验证	已记录的步骤，显示功能/修复按预期工作
定位	所有面向用户的字符串均使用适当的本地化机制
文档	在适用的情况下更新了开发者文档和用户文档

来源： .github/pull_request_template.md22-24

自动化 Issue 管理

PowerToys 利用复杂的 GitHub 自动化来管理大量的社区 Issue 并保持仓库的健康和整洁。

资源管理自动化

自动化系统处理多个工作流以管理 Issue 生命周期

来源： .github/policies/resourceManagement.yml10-44 .github/policies/resourceManagement.yml59-76

团队响应命令

自动化系统识别团队成员的特殊命令，以简化常见响应

命令	操作	结果
/bugreport 或 /reportbug	请求诊断信息	添加带有说明的回复，设置 Needs-Author-Feedback
/feedbackHub	重定向到 Windows Feedback Hub	关闭 issue，添加 Resolution-Please File on Feedback Hub
/dup #123 或 /duplicate of #123	标记为重复	关闭 issue，添加 Resolution-Duplicate
/needinfo	请求更多信息	设置 Needs-Author-Feedback
/helped	标记为已解决	关闭 issue，添加 Resolution-Helped User
/loc	发送给本地化团队	添加 Loc-Sent To Team 标签

来源： .github/policies/resourceManagement.yml108-235

社区贡献检测

系统会自动检测社区成员何时表达贡献意愿，并提供指导

来源： .github/policies/resourceManagement.yml236-244

本地化贡献流程

本地化贡献遵循与代码贡献不同的工作流程，因为它们仅由微软的内部本地化团队处理。

翻译 Issue 处理

翻译 Issue 通过专门的流程进行管理，将其路由到内部团队

不接受社区的本地化 pull request - 所有翻译工作必须通过微软内部本地化管道进行，以确保一致性和质量。

来源： CONTRIBUTING.md38-41 .github/policies/resourceManagement.yml218-235

支持和文档资源

PowerToys 提供了多种获取帮助和访问文档的渠道

支持渠道

资源	目的	链接
用户文档	所有 PowerToys 实用程序的最终用户指南	aka.ms/powertoys-docs
开发者文档	贡献者的技术文档	GitHub devdocs 文件夹
问题跟踪器	Bug 报告和功能请求	GitHub Issues
支持文档	通用支持指南	SUPPORT.md

文档链接

该项目维护了一系列全面的 aka.ms 链接，方便访问文档

来源： SUPPORT.md1-25 doc/devdocs/akaLinks.md1-45 .github/ISSUE_TEMPLATE/config.yml1-10