# 分类

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

> 除了本页面，[如何在 GitHub 上进行分类](https://learn.wordpress.org/tutorial/how-to-do-triage-on-github/)教程是另一个了解分类工作的绝佳资源

## 加入分类处理团队

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

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

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

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

如果您想加入这个团队，随时可以在 #core-editor [Slack](https://make.wordpress.org/chat/) 频道中提出申请。

## 处理你的首个议题

开始时，只需从以下筛选列表中选择一个。注意：你可以在[总议题页面](https://github.com/wordpress/gutenberg/issues)选择“排序”选项找到大部分这些筛选条件。

-   **所有[未分配标签](https://github.com/WordPress/gutenberg/issues?q=is%3Aopen+is%3Aissue+no%3Alabel+sort%3Aupdated-asc)的 Gutenberg 议题**。通过简单添加标签进行分类，能帮助关注 Gutenberg 特定方面的人更容易找到相关议题并开始处理。
-   **所有[未分配标签](https://github.com/WordPress/gutenberg/pulls?q=is%3Aopen+is%3Apr+no%3Alabel)的 Gutenberg 拉取请求**。这需要一定的代码熟悉度。关于使用哪些标签最佳，请[查看拉取请求标签部分](/docs/contributors/repository-management#pull-requests)获取指导。你也可以随时与拉取请求的作者确认，确保标签符合他们的意图。
-   **[最近更新最少](https://github.com/WordPress/gutenberg/issues?q=is%3Aopen+is%3Aissue+sort%3Aupdated-asc)的 Gutenberg 议题**。处理那些陈旧且可能过时的议题，能防止重要工作被忽视。
-   **所有[无评论](https://github.com/wordpress/gutenberg/issues?q=is%3Aissue+is%3Aopen+comments%3A0+)的 Gutenberg 议题**。处理此列表有助于确保所有议题得到关注，并能识别在可操作前可能需要更多信息或讨论的议题。
-   **[评论最少](https://github.com/wordpress/gutenberg/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-asc)的 Gutenberg 议题**。处理此列表有助于社区确定哪些提案可能仍需关注。
-   **[评论最多](https://github.com/wordpress/gutenberg/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc)的 Gutenberg 议题**。如果你愿意参与且对话已停滞，处理这类议题的最佳方式是总结迄今的讨论，并尽力识别行动项、阻碍等。处理此列表能让重要且复杂议题的解决方案得以推进。
-   你也可以**在 GitHub 上创建自定义筛选器集**。如果你认为某个筛选器可能对社区有用，欢迎提交拉取请求将其添加到此列表。

## 通用问题分类流程

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

1. 首先**搜索重复项**。如果问题是重复的，请通过评论“重复于 #”来关闭它，并将任何相关的新细节添加到现有问题中。（别忘了也搜索已关闭问题中的重复项！）。
2. 如果**问题缺少标签，请添加一些**以更好地分类（需要加入分类团队后获得的适当权限）。添加标签时，一个好的起点是应用一个以 [Type] 为前缀的标签（例如 [Type] Enhancement 或 [Type] Bug）来指示问题的类型。之后考虑添加更具描述性的标签。如果问题涉及特定的核心区块，请添加一个以 [Block] 为前缀的标签。或者，如果问题影响特定功能，则有 [Feature] 标签。最后，还有影响特定兴趣领域的标签，如 Accessibility 和 Internationalization。您可以[在此处](https://github.com/WordPress/gutenberg/labels)查看所有可能的标签。
3. 如果**标题未能清晰传达问题，请编辑它以使其更清晰**（需要适当权限）。具体来说，我们建议将问题相关的主要功能放在标题的开头（[示例](https://github.com/WordPress/gutenberg/issues/6193)），并且标题通常应尽可能简洁且具有描述性（[示例](https://github.com/WordPress/gutenberg/issues/6193)）。
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](https://github.com/WordPress/gutenberg/labels).

| Label                      | Reason                                                                                    |
| -------------------------- | ----------------------------------------------------------------------------------------- |
| `[Type] Bug`               | When an intended feature is broken.                                                       |
| `[Type] Enhancement`       | When someone is suggesting an enhancement to a current feature.                           |
| `[Type] Help Request`      | When someone is asking for general help with setup/implementation.                        |
| `Needs Technical Feedback` | When you see new features or API changes proposed.                                        |
| `Needs More Info`          | When it’s not clear what the issue is or it would help to provide additional details.     |
| `Needs Testing`            | When a new issue needs to be confirmed or old bugs seem like they are no longer relevant. |

**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.

| Label                | Reason                                                                                                                                                                                                                                                     |
| -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Priority: High`     | Fits one of the current focuses and is causing a major broken experience (including flow, visual bugs and blocks).                                                                                                                                         |
| `Priority: Low`      | Enhancements that aren’t part of focuses, niche bugs, problems with old browsers.                                                                                                                                                                          |

## 关闭议题

议题因以下原因被关闭：

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

## 专项问题分类

### 发布专项分类

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

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

### 专项设计分类

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

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

提醒事项：

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

有关每周设计分类的更多详细信息以及如何参与，请[查阅此指南](https://make.wordpress.org/design/handbook/workflows/weekly-gutenberg-design-triage/)。