title: "分类" post_status: publish comment_status: open taxonomy: category: - gutenberg-docs post_tag: - Contributors - Repos - Data

分类

为保持仓库健康，需要定期进行分类处理。分类是指审查现有议题和拉取请求，确保它们具有相关性、可操作性且包含所有必要信息。任何人都可以协助分类，但您需要成为 Gutenberg 仓库分类团队的成员才能修改议题标签或编辑其标题。

除了本页面，如何在 GitHub 上进行分类教程是另一个了解分类工作的绝佳资源

加入分类处理团队

分类处理团队是一个开放的群体，其特殊职责是确保在 Gutenberg 代码库中保持一致的分类处理流程。分类处理有多种形式：

• 成员利用个人时间进行的定期自主分类处理。
• 在固定时间以小组形式组织的分类处理会议。您可以查看会议页面来查找这些分类处理会议及相应的 Slack 频道。
• 针对特定看板、标签或功能的专题分类处理会议。

成为分类处理团队成员有以下期望：

• 您需要至少每周进行一次分类处理，即使是自主处理。
• 在可能的情况下，尝试参加组织的分类处理会议。
• 如果您加入分类处理团队是为了专注于特定标签或看板，期望您将重点放在该领域。请将此告知其他分类处理团队成员。

如果您想加入这个团队，随时可以在 #core-editor Slack 频道中提出申请。

处理你的首个议题

开始时，只需从以下筛选列表中选择一个。注意：你可以在总议题页面选择“排序”选项找到大部分这些筛选条件。

• 所有未分配标签的 Gutenberg 议题。通过简单添加标签进行分类，能帮助关注 Gutenberg 特定方面的人更容易找到相关议题并开始处理。
• 所有未分配标签的 Gutenberg 拉取请求。这需要一定的代码熟悉度。关于使用哪些标签最佳，请查看拉取请求标签部分获取指导。你也可以随时与拉取请求的作者确认，确保标签符合他们的意图。
• 最近更新最少的 Gutenberg 议题。处理那些陈旧且可能过时的议题，能防止重要工作被忽视。
• 所有无评论的 Gutenberg 议题。处理此列表有助于确保所有议题得到关注，并能识别在可操作前可能需要更多信息或讨论的议题。
• 评论最少的 Gutenberg 议题。处理此列表有助于社区确定哪些提案可能仍需关注。
• 评论最多的 Gutenberg 议题。如果你愿意参与且对话已停滞，处理这类议题的最佳方式是总结迄今的讨论，并尽力识别行动项、阻碍等。处理此列表能让重要且复杂议题的解决方案得以推进。
• 你也可以在 GitHub 上创建自定义筛选器集。如果你认为某个筛选器可能对社区有用，欢迎提交拉取请求将其添加到此列表。

通用问题分类流程

在处理问题分类时，无论是针对上述列表还是一般问题，请逐一处理每个问题。以下是为每个问题可以执行的一些步骤：

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

常用标签

Generally speaking, the following labels are very useful for triaging issues and will likely be the ones you use the most consistently. You can view all possible labels here.

Determining priority labels

If you have enough knowledge about the report at hand and feel confident in doing so, you can consider adding priority. Note that it’s on purpose that no priority label infers a normal level.

关闭议题

议题因以下原因被关闭：

• 某个 PR 和/或最新版本已解决所报告的问题。
• 与当前报告重复。
• 更适合在 WordPress.org 论坛处理的帮助请求。
• 无法复现的问题。
• 需要更多信息但议题作者超过两周未回复。
• 被确定为无法修复或按预期工作的事项。

专项问题分类

发布专项分类

以下是在临近发布期间进行问题分类时需遵循的指南。与常规分类相比，这尤为重要，以便准确识别有问题的、阻碍发布的缺陷并找到解决方案。

• 若缺陷在候选发布版（RC）中引入，且将破坏大量工作流程，请将其添加至版本里程碑，并在 WordPress.org Slack 的 #core-editor 频道中标记。
• 若缺陷在最新版本中引入，且尚未发布下一个候选发布版，理想情况下开发者应在候选发布版前推动修复！修复的推动力度应与破坏可能性成正比。此时，请添加至候选发布版里程碑，若情况紧急，可在 WordPress.org Slack 的 #core-editor 频道中提醒。
• 若缺陷并非在最新版本中引入，请勿添加里程碑。相反，若为紧急问题，可使用如 [Priority] High 的标签，必要时可在每周核心会议中提请关注。

专项设计分类

除了之前列出的通用分类流程外，针对参与分类的设计思维人员，还有一些针对设计中心的特定补充流程。

• PR 测试与审查：这应是您每日自我分类的第一站。
• 标签 Needs Design Feedback：检查问题是否确实需要设计反馈，并在可能的情况下提供反馈。您可以按优先级、项目板或评论最少来组织处理。一旦有足够的意见，请移除此标签并决定后续步骤（例如添加 Needs Design 标签）。
• 标签 Needs Design：它真的需要设计吗？是否符合某个重点领域？如果已有设计，请标记为 Needs Design Feedback 以更好地分类问题。

提醒事项：

• 根据需要请求截图。
• 在合并前请求迭代并记录任何更改。
• 如果问题不在任何项目板中，请检查它是否不符合特定的重点领域。
• 如果问题/拉取请求尚未确定优先级，请考虑添加优先级标签以推动问题进展。

有关每周设计分类的更多详细信息以及如何参与，请查阅此指南。