分类

为了保持代码仓库的健康状态，需要定期对其进行分类处理。分类处理是指审查现有的问题和拉取请求，以确保它们具有相关性、可操作性，并包含所需的所有信息。任何人都可以参与分类处理，尽管若要在 Gutenberg 代码仓库中修改问题的标签或编辑其标题，你需要成为该仓库分类处理团队的成员。

除了本页面之外，如何在 GitHub 上进行分类处理教程也是了解分类处理的绝佳资源

加入分类处理团队

分类处理团队是一个开放的小组，其特定职责是确保在 Gutenberg 代码仓库中一致地进行分类处理。分类处理主要有以下几种类型：

• 由成员在自己的时间内进行的常规自我分类处理会话。
• 作为小组在固定时间组织的分类处理会话。你可以查看会议页面以找到这些分类处理会话及相应的 Slack 频道。
• 针对特定看板、标签或功能的重点分类处理会话。

以下是作为分类处理团队成员的预期要求：

• 即使只是进行自我分类处理，你也预计每周至少进行一次分类处理工作。
• 尽可能参加组织的分类处理会话。
• 如果你加入分类处理团队是为了专注于特定的标签或看板，那么预期你的精力将集中于此。请告知其他分类处理团队成员这一情况。

如果你想加入这个团队，只需随时在 Slack 的 #core-editor 频道中询问即可。

分类处理你的第一个问题

要开始工作，只需从下面的筛选列表中选择一项。注意：你可以通过从整体 Issues 页面选择“Sort”（排序）选项来找到大部分此类筛选器。

• 所有未分配标签的 Gutenberg issues 。通过简单地添加标签进行分类处理，可以帮助关注 Gutenberg 某些方面的人员更轻松地找到相关问题并开始着手解决。
• 所有未分配标签的 Gutenberg pull requests 。这需要具备一定的代码熟悉度。有关使用哪些标签的最佳指导，请查阅此关于为贡献者标记拉取请求的部分。你也可以随时与创建拉取请求的人核实，以确保标签符合他们的意图。
• 最近更新最少的 Gutenberg issues。对逐渐变旧且可能过时的 issue 进行分类处理，可防止重要工作被忽视。
• 所有没有评论的 Gutenberg issues 。对此列表进行分类处理有助于确保所有 issue 都得到确认，并帮助识别那些可能需要更多信息或在具备可操作性之前需要进行讨论的 issue。
• 评论最少的 Gutenberg issues。对此列表进行分类处理有助于社区弄清楚哪些提案可能仍需要获得支持。
• 评论最多的 Gutenberg issues。如果你觉得可以轻松介入且对话已停滞不前，处理这类 issue 的最佳方式是总结迄今为止的讨论，并尽力找出行动项、阻碍因素等。对此列表进行分类处理有助于推动重要且复杂的问题向前发展并寻找解决方案。
• 你还可以在 GitHub 上创建自己的自定义筛选集。如果你有认为可能对社区有用的筛选器，欢迎提交 PR 将其添加到列表中。

通用分类处理流程

在进行分类处理时，无论是上述列表中的哪一个还是总体上的 issue，请逐一处理每个 issue。以下是你可以对每个 issue 执行的一些步骤：

1. 首先搜索重复项。如果该 issue 是重复的，请通过评论“Duplicate of #”来关闭它，并将任何相关的新细节添加到现有 issue 中。（别忘了也在已关闭的 issue 中搜索重复项！）。
2. 如果issue 缺少标签，请添加一些以便更好地对其归类（需要在加入分类处理团队后获得适当权限）。添加标签的一个好的起点是应用一个带有 [Type] 前缀的标签（例如 [Type] Enhancement 或 [Type] Bug），以表明它是哪种类型的 issue。之后考虑添加更具描述性的标签。如果 issue 涉及特定的核心区块，请添加一个带有 [Block] 前缀的标签。或者，如果 issue 影响特定功能，则有 [Feature] 标签。最后，还有影响特定兴趣领域的标签，如无障碍访问（Accessibility）和国际ization（Internationalization）。你可以在此处查看所有可能的标签。
3. 如果标题未能清晰地传达 issue，请编辑它以使其更清晰（需要适当权限）。具体来说，我们建议将 issue 关联的主要功能放在标题开头（示例），并且标题通常应尽可能简洁且具有描述性（示例）。
4. 如果是Bug 报告，请测试以确认报告或添加 Needs Testing 标签。如果没有足够的信息来确认报告，请添加 [Status] Needs More Info 标签并索取所需的详细信息。当 Bug 报告包含复现步骤时特别有益，因此如果缺失这些步骤，请要求报告人添加。
5. 不再需要时移除 [Status] Needs More Info 标签，例如如果 issue 的作者已经回复了足够的详细信息。
6. 如果作者在 2 周以上未回复，请附带说明关闭不活跃的 [Status] Needs More Info issues。
7. 如果 issue 上有对话但未确定可操作的步骤，请与参与者跟进以查看什么是有操作性的。在评论中回复时，请务必 @ 每位参与者。
8. 如果你觉得可以放心地进一步对该 issue 进行分类处理，那么你还可以：
   • 通过调试来检查 Bug 报告是否有效，看看是否能追踪到技术细节。
   • 检查 issue 是否缺少某些细节，并看看你是否能填补这些细节。例如，如果 Bug 报告缺少视觉细节，那么在本地重现该 issue 并上传截图或 GIF 会很有帮助。
   • 如果你相信这是一个相对容易让首次贡献者尝试解决的 issue，可以考虑添加 Good First Issue 标签。

常用标签

一般来说，以下标签对于对 issue 进行分类处理非常有用，而且很可能是你最常使用的标签。你可以在此处查看所有可能的标签。

确定优先级标签

如果你对当前的报告有足够的知识并有信心这样做，可以考虑添加优先级。请注意，故意没有任何优先级标签意味着正常级别。

关闭 Issues

基于以下原因关闭 issues：

• PR 和/或最新版本解决了报告的 issue。
• 是当前报告的重复项。
• 最好在 WordPress.org 论坛中处理的求助请求。
• 无法复现的 issue。
• 需要更多信息但作者超过 2 周未回复的 issue。
• 确定为无法修复或按预期工作的项目。

特定分类处理

发布特定分类处理

以下是发布前后进行问题分类（triage）时需要遵循的一些准则。这与常规的问题分类有所不同，其重要性在于能够准确识别出阻碍发布的严重缺陷并找到解决方案。

• 如果某个缺陷是在候选版本（RC）中引入的，并且会破坏许多工作流程，请将其添加到该版本的里程碑（milestone）中，并在 WordPress.org Slack 的 #core-editor 频道中标记出来。
• 如果某个缺陷是在最新版本中引入的，且下一个 RC 尚未生成，理想情况下开发者应在 RC 之前推动修复！推动修复的力度应与潜在的中断风险成正比。在这种情况下，请将其添加到 RC 里程碑中；如果被认定为紧急事项，请在 WordPress.org Slack 的 #core-editor 频道中提及相关人员。
• 如果某个缺陷并非在最新版本中引入，请勿添加里程碑。相反，如果是紧迫问题，请使用类似 [Priority] High 的标签；如有必要，你可以在每周的核心会议（core meetings）上引起大家对该问题的注意。

针对设计的具体分类工作

除了前面列出的通用分类流程外，对于参与分类工作的具有设计思维的人员来说，还有一些专门针对设计的附加流程。

• PR 测试和审查：这应是你每日自我分类的首选步骤。
• 标签 Needs Design Feedback：检查该议题是否确实需要设计反馈，如果可能，请提供反馈。你可以按优先级、项目看板（project boards）或评论最少的顺序来整理这些议题。一旦收集到足够的意见，请移除该标签并决定后续步骤（例如添加 Needs Design 标签）。
• 标签 Needs Design：它真的需要设计方案吗？这是否符合当前的关注点？如果已有设计方案，请标记为 Needs Design Feedback 以更好地对议题进行分类。

提醒：

• 根据需要索取截图。
• 要求提供迭代方案，并在合并前记录任何变更。
• 如果议题不在看板上，请检查它是否不属于特定的关注领域。
• 如果议题/拉取请求（pull request）尚未确定优先级，考虑添加优先级标签以帮助推进该议题。

有关每周设计分类的详细信息及加入方式，请查阅本指南。