11 KiB
设计评审
若您的拉取请求涉及设计/用户界面改动，请务必添加相应标签以提醒设计团队。如需申请设计评审，请在PR中添加需要设计反馈标签。若存在需要更新设计/用户界面的PR，请使用Figma库更新标签。
需进行设计评审的变更类型指南：
- 基于既有设计的修改，需确认设计在变更后仍然有效
- 任何涉及视觉效果的改动
- 针对某个创意或探索性想法希望获得设计反馈
合并拉取请求
满足以下条件的拉取请求通常可被合并：
- 被认定对代码库具有重要价值
- 符合所有相关代码评审标准
- 必要时配备充分测试覆盖
- 经过所有潜在边界情况验证
- 已正确添加更新日志条目
- 经过原作者以外的成员评审
- 已变基至
trunk分支最新版本
最终合并决定由 @wordpress/gutenberg-core 团队作出。
GitHub上WordPress组织的所有成员均具备评审和合并拉取请求的权限。若您已完成PR评审并对代码质量有信心，请批准该拉取请求并通过评论提及**@wordpress/gutenberg-core**或参与该PR的核心成员。待其确认无异议后，您即可将PR合并至主干分支。
多数拉取请求将自动分配发布里程碑，但请确保已合并的PR获得相应分配。此举可建立代码变更的历史沿革记录，便于所有项目参与者（包括非技术人员）追溯信息。
关闭拉取请求
某些情况下，无论投入多少额外精力（如超出范围），拉取请求可能始终无法合并。此时应在关闭PR时礼貌地与贡献者沟通说明原因，这有助于促进未来的建设性参与。
请确保：
- 感谢贡献者投入的时间与精力
- 完整阐述关闭拉取请求的决策依据
- 尽可能提供相关支持文档链接
参考沟通模板：
感谢____为本次拉取请求付出的时间。
关闭此PR的原因是____。进一步说明，____。
更多详情请参阅____和____。
团队架构
本项目使用两个GitHub团队：
-
Gutenberg核心团队：由积极参与项目的成员组成，包括定期参加会议、参与问题分类会议、执行代码评审、开发功能与修复缺陷、执行插件及npm发布等。
-
Gutenberg团队：由至少完成2-3项重要项目贡献的成员组成。
若您符合多项重要贡献已被代码库采纳的标准，并希望加入Gutenberg团队，欢迎在#core-editor Slack频道提出申请。
项目管理
我们使用GitHub项目来追踪那些当前无需立即执行，但需要保留供未来参考的事项细节。
代码库管理
本文档为动态更新文档，旨在阐述我们如何协作管理 Gutenberg 代码库。若您希望提出修改建议，请通过提交议题进行讨论或直接向文档发起拉取请求。
本文档涵盖以下内容：
议题管理
健康的议题列表应确保议题兼具相关性与可操作性。相关性指议题需符合项目当前优先级；可操作性则要求解决方案清晰明确。
对于无关或不可操作的议题应及时关闭，以免阻碍项目进展。不妨将议题列表视作工作台：堆积的杂物越多，有效工作空间就越受限。
标签分类
所有议题需配置一个或多个标签。
工作流标签以“Needs”开头，可根据需要灵活添加。理想情况下，每个工作流标签应有对应跟进团队（例如无障碍团队负责 Needs Accessibility Feedback，测试团队负责 Needs Testing 等）。
标有优先级-高与优先级-紧急的议题需指定处理人员或纳入活跃里程碑。
求助类或操作指南类问题应首先发布于相关支持论坛。若不确定是否属于程序错误，支持团队或论坛志愿者将协助排查问题，为撰写有效的错误报告收集必要信息。
常见标签示例：
- 初试推荐 - 适合新贡献者处理的议题。请通过评论申领任务，并在提交拉取请求时标注议题编号。
- 初审推荐 - 适合有意参与代码审查的新贡献者处理的拉取请求。
- 需无障碍反馈 - 影响无障碍访问的变更需经专项审查（如标记语言修改）。
- 需设计反馈 - 涉及设计或用户体验的变更需获得设计确认。
- [类型]程序错误 - 现有功能存在异常。
- [类型]功能增强 - 可提升 Gutenberg 使用体验的改进方案。
- [类型]插件兼容性 - 记录 Gutenberg 与插件/扩展的冲突情况。需通知插件作者并提供解决方案文档。
- [状态]需补充信息 - 议题需补充关键信息方可推进处理，通常需要发起者配合完善。
查阅完整标签目录获取所有标签说明。
里程碑
我们将事项归入里程碑以便更好地分类。事项会被添加至以WordPress开头的里程碑，而拉取请求则会被添加至以(Gutenberg)结尾的里程碑。
以下是一些您可能会看到的里程碑：
- WordPress X.Y：为未来WordPress版本需要完成的任务。
- X.Y (Gutenberg)：针对Gutenberg插件X.Y版本的拉取请求。
- 未来：这是经大家一致确认为有益但不属于其他分类的事项。
事项分类
为了保持事项列表的健康状态，需要定期进行分类。_分类_是指审查现有事项，确保它们具有相关性、可操作性，并包含所有必要信息。
任何人都可以帮助分类，但您需要拥有Gutenberg仓库的贡献者权限才能修改事项的标签或编辑其标题。
详情请参阅分类贡献者指南。
拉取请求
Gutenberg针对所有代码和文档变更采用功能分支拉取请求工作流。从高层次看，流程如下：
- 在本地检出一个新的功能分支。
- 进行修改，并彻底测试。
- 对修改满意后提交更改，并推送分支。
- 打开您的拉取请求。
- 如果您是拥有适当访问权限的常规贡献者，请正确标记和命名您的拉取请求（见下文）。
关于拉取请求的标记和命名，以下指南有助于更高效、有条理地编制变更日志。这些指南对常规贡献者尤为重要。但请不要因纠结于这些细节而阻碍您分享工作——出错是难免的，且易于修正！
- 处理实验性界面和功能时，应用
[Type] Experimental标签，而非Feature、Enhancement等。 - 为技术包（脚本、create-block、添加React钩子等）开发新功能时，应用
[Type] New API标签，而非Feature、Enhancement等。 - 修复项目内部工具的缺陷或进行增强时，应用
[Type] Build Tooling标签，而非Bugs、Enhancement等。 - 在拉取请求标题中，与其描述为修复问题所做的代码变更，不如提及实际修复的缺陷。例如：与其说“在组件中检查可为空对象”，不如说“修复点击复制块按钮时编辑器崩溃的问题”。
除上述流程外，还有几点需要强调：
- 重要的拉取请求应有相关事项作为前提，该事项需明确待解决的问题，并允许在实际编写代码前讨论最合适的解决方案。
- 为使代码更易于合并，每个拉取请求应仅包含一个概念性变更。保持贡献的原子性可使拉取请求讨论聚焦于单一主题，并能够逐案审批变更。
- 不同的拉取请求可处理其关联事项中的不同项目或待办事项，若事项较为复杂，无需单个拉取请求覆盖单个事项。
代码审查
每个拉取请求除自动测试外，还需经过人工代码审查。代码审查的目标可概括为：
- 正确性——变更是否实现了预期功能？
- 安全性——恶意方是否会找到利用此变更的途径？
- 可读性——数月后您自己能否理解此变更？
- 优雅性——变更在整体风格和架构中是否协调？
- 利他性——此变更如何为整体做出贡献？
作为审查者，您的反馈应聚焦于想法而非个人。力求理解、保持尊重，并专注于建设性对话。
作为贡献者，您的责任是从建议中学习，并根据反馈迭代您的拉取请求（如有需要）。力求协作，为整体做出最佳贡献。
鼓励所有愿意尝试的人参与代码审查。若您审查了拉取请求并对变更充满信心，请批准它。若您觉得它尚未完全准备好合并，请添加审查意见，说明在最终批准前需要另一组人员复核。这有助于过滤明显缺陷，并简化核心成员的审查工作。关注后续审查也有助于未来提升您的审查信心。
若您尚未准备好进行完整审查，可尝试在PR中评论。关于功能或变更缘由的提问同样有益。您也可以在不进行完整审查的情况下，对您理解的代码部分变更发表评论。
若您在获取审查方面遇到困难，请参阅：如何让您的拉取请求获得审查？