Repository Management

This is a living document explaining how we collaboratively manage the Gutenberg repository. If you’d like to suggest a change, please open an issue for discussion or submit a pull request to the document.
This document covers:
Issues
Labels
Milestones
Triaging Issues
Pull Requests
Code Review
Design Review
Merging Pull Requests
Closing Pull Requests
How To Get Your Pull Request Reviewed?
Projects
问题管理
一个健康的问题列表应确保所有问题都具备相关性和可操作性。_相关性_指问题与项目当前优先级相符；_可操作性_指解决该问题所需采取的行动清晰明确。
任何无关或不可操作的问题都应被关闭，因为它们会阻碍项目进展。不妨将问题列表想象成办公桌：桌上杂物越多，有效利用空间完成工作就越困难。
标签
所有议题都应具有一个或多个标签。
工作流标签以“Needs”开头，可根据需要应用。理想情况下，每个工作流标签都应有一个对应的跟进小组，例如无障碍团队负责 
Needs Accessibility Feedback，测试团队负责 
Needs Testing 等。
Priority High 和 Priority OMGWTFBBQ 议题应指定负责人和/或处于活跃的开发里程碑中。
帮助请求或“如何操作”类问题应首先发布在相关的支持论坛中。如果某问题可能是错误但不明确，支持团队或论坛志愿者可以帮助排查，以获取有效错误报告所需的所有正确信息。
以下是一些您可能常见的标签：
Good First Issue - 被确定为适合新贡献者处理的议题。请评论说明您打算处理该议题，并在提交的拉取请求中引用议题编号。
Good First Review - 被确定为适合有兴趣进行代码审查的新贡献者处理的拉取请求。
Needs Accessibility Feedback - 影响无障碍性的变更，需要相应审查（例如标记更改）。
Needs Design Feedback - 以某种方式修改设计或用户体验的变更，需要批准。
[Type] Bug - 现有功能在某些方面出现问题。
[Type] Enhancement - 添加此改进将使 Gutenberg 变得更好。
[Type] Plugin Interoperability - 记录 Gutenberg 与插件或扩展之间的冲突。应通知插件作者并提供如何解决的文档。
[Status] Needs More Info - 该议题需要更多信息才能具有可操作性和相关性。通常这需要原始报告者的跟进。
查看标签目录以获取所有标签的列表。
里程碑
我们将议题归入里程碑以便更好地分类。以 
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 中发表评论。关于功能或变更缘由的提问同样很有帮助。你也可以仅针对你理解的代码部分发表意见，无需进行完整审查。
如果你在获取审查时遇到困难，请参阅：如何让你的拉取请求获得审查？
设计评审
如果你的拉取请求涉及设计/用户界面，需要正确添加标签以提醒设计团队。如需申请设计评审，请在 PR 上添加 Needs Design Feedback 标签。若存在需要更新设计/用户界面的 PR，请使用 Figma Library Update 标签。
作为参考，以下变更应接受评审：
基于先前设计的变更，需确认设计在变更后仍然有效。
任何视觉层面的改动。
若你希望就某个想法或探索获得设计反馈。
合并拉取请求
当拉取请求满足以下条件时，通常可以合并：
被认为是对代码库有价值的更改。
符合所有相关的代码审查标准。
在必要时，有足够的测试覆盖。
已针对所有潜在边缘情况进行审查。
已正确添加更新日志条目。
已由原作者以外的其他人审查。
已变基到 
trunk 分支的最新版本。
最终的拉取请求合并决定由 @wordpress/gutenberg-core 团队做出。
GitHub 上 WordPress 组织的所有成员都有能力审查和合并拉取请求。如果您已审查某个 PR 并对代码有信心，请批准该拉取请求并发表评论，提及 @wordpress/gutenberg-core 或参与该 PR 的特定核心成员。一旦他们确认没有异议，您就可以自由地将 PR 合并到主干分支。
大多数拉取请求会自动分配一个发布里程碑，但请确保您合并的拉取请求已分配一个。这样做可以创建代码何时落地的历史记录，并使所有项目贡献者（甚至是非技术贡献者）都能访问此信息。
关闭拉取请求
有时，无论付出多少额外努力，拉取请求可能都无法合并（例如超出范围）。在这种情况下，最好在说明关闭原因的同时，礼貌地与贡献者沟通，这有助于鼓励他们未来继续积极参与。
请确保：
感谢贡献者付出的时间和努力。
充分解释关闭拉取请求的决策理由。
尽可能链接相关的支持文档。
如果您需要参考模板：
感谢 ____ 在此拉取请求上花费的时间。
我关闭此拉取请求是因为 ____。进一步说明，____。
更多详情，请参阅 ____ 和 ____。
团队
该项目使用两个 GitHub 团队。
Gutenberg Core：由积极参与项目的人员组成的团队：定期参加会议、参与问题分类会议、定期执行代码审查、处理功能开发和错误修复，以及执行插件和 npm 发布。
Gutenberg：由对项目至少做出 2-3 次有意义贡献的贡献者组成的团队。
如果您符合此标准，即有多项有意义的贡献已被仓库接受，并希望加入 Gutenberg 团队，请随时在 #core-editor Slack 频道中提出。
项目
我们使用 GitHub 项目 来跟踪那些暂时无法立即执行，但希望保留以备将来参考的详细信息。