为了保持存储库的健康，需要定期对其进行分类。分类是审查现有问题和拉取请求的做法，以确保它们相关、可操作，并具有所需的所有信息。任何人都可以帮助分类，但您需要成为古腾堡存储库分类团队的成员才能修改问题的标签或编辑其标题。
除此之外如何在GitHub上进行分类教程是介绍分诊的另一个很好的资源
分诊团队是一个开放的团队，负责确保在古腾堡回购协议中始终进行分诊。有各种类型的分诊：
- 成员在自己的时间内定期进行自我分类。
- 在规定的时间内，以小组形式组织分诊。你可以查看会议页面找到这些分类会话和适当的空闲通道。
- 针对特定的板、标签或功能进行重点分类。
以下是作为分诊团队成员的期望：
- 即使是每周至少一次自我分诊，你也需要做一些分诊。
- 尽你所能，尝试参加有组织的分诊会议。
- 如果你加入分诊团队专注于某个特定的标签或板，期望你的注意力会在那里。请将此告知其他分诊团队成员。
如果你想加入这个团队，只需在#core-editor中询问即可松弛（Slack）任何时候。
要开始，只需从下面的筛选列表中选择一个即可。注意：您可以通过从总体问题页面.
- 所有古腾堡问题没有指定标签通过简单地添加标签进行分类，可以帮助专注于古腾堡某些方面的人更容易地发现相关问题，并开始着手解决这些问题。
- 所有古腾堡拉动请求没有指定标签。这需要代码的舒适度。有关最佳使用哪些标签的更多指导，请查看有关标记拉入请求的本节供贡献者使用。您还可以随时与创建拉取请求的人进行检查，以确保标签与他们的意图相符。
- 最近更新最少的古腾堡问题。对越来越老、可能已经过时的问题进行分类，可以防止重要工作被忽视。
- 所有古腾堡问题没有评论。试用此列表有助于确保所有问题都得到确认，并有助于确定可能需要更多信息或讨论才能采取行动的问题。
- 评论最少的关于古腾堡问题。对该列表进行分类有助于社区了解哪些内容可能仍然需要某些建议的支持。
- 评论最多的关于古腾堡问题。如果你觉得很自在，而且对话已经停滞，那么分类这些问题的最佳方法是总结到目前为止的讨论，并尽最大努力确定行动项目、阻碍因素等。分类此列表可以找到重要而复杂问题的解决方案，以便继续前进。
- 你也可以在GitHub上创建您自己的自定义过滤器集。如果你有一个你认为可能对社区有用的过滤器，请随时提交一份PR，将其添加到此列表中。
在进行分类时，无论是上述列表之一还是一般问题，都要逐个解决问题。您可以针对每个问题执行以下步骤：
- 弗斯特搜索重复项。如果问题是重复的，请用“重复的#”注释将其关闭，并向现有问题添加任何相关的新详细信息。（不要忘记在已关闭的问题中搜索重复项！）。
- 如果问题是缺少标签，请添加一些以更好地对其进行分类（需要在加入分诊团队后给予适当的权限）。添加标签时，一个很好的起点是应用前缀为[Type]的标签之一（例如[Type]Enhancement或[Type]Bug）来指示问题的类型。然后考虑添加更多描述性标签。如果问题涉及特定的核心块，请添加前缀为[block]的标签之一。或者，如果问题影响特定功能，则会有[feature]标签。最后，还有一些标签会影响特定的兴趣领域，如可访问性和国际化。您可以查看所有可能的标签在这里.
- 如果标题没有足够清楚地传达问题，请编辑以清晰明了（需要适当的权限）。具体来说，我们建议在标题开头添加与问题相关的主要功能(例子)标题要尽可能简明扼要(例子).
- 如果是错误报告、测试以确认报告或添加
需要测试标签。如果没有足够的信息来确认报告，请添加[状态]需要更多信息标记并询问所需的详细信息。当错误报告有复制步骤时，这尤其有益，因此如果缺少这些步骤，请让记者添加。
- 删除
[状态]需要更多信息何时不再需要例如，如果问题的作者已经给出了足够的细节。
- 关闭非活动
[状态]需要更多信息带有注释的问题如果作者在2周以上没有回复。
- 如果有关于这个问题的对话，但没有确定可行的步骤，与参与者一起跟进，看看哪些是可行的。请确保在回复评论时@每个参与者。
- 如果您觉得可以进一步尝试该问题，那么您还可以：
- 通过调试来检查错误报告是否有效，看看是否可以跟踪技术细节。
- 检查问题是否缺少一些细节，看看您是否可以填写这些细节。例如，如果错误报告缺少视觉细节，则在本地重现问题并上传屏幕截图或GIF会很有帮助。
- 如果你认为这对于首次投稿人来说是一个相对容易解决的问题，那么可以考虑添加Good First Issue标签。
常用标签
一般来说，以下标签对于分类问题非常有用，并且可能是您使用得最为一致的标签。您可以查看所有可能的标签在这里.
| 标签 |
原因 |
[类型]Bug |
当预期特征被破坏时。 |
[类型]增强功能 |
当有人建议增强当前功能时。 |
[类型]帮助请求 |
当有人要求提供设置/实施方面的一般帮助时。 |
需要技术反馈 |
当您看到建议的新功能或API更改时。 |
需要更多信息 |
当不清楚问题是什么或提供更多详细信息会有所帮助时。 |
需要测试 |
当需要确认新问题或旧错误似乎不再相关时。 |
确定优先级标签
如果你对手头的报告有足够的了解，并且有信心这样做，你可以考虑增加优先级。请注意，没有优先级标签是故意推断正常级别的。
| 标签 |
原因 |
优先级：高 |
适合当前的焦点之一，并正在导致重大破坏体验（包括流、视觉错误和块）。 |
优先级：低 |
不是焦点的增强功能、利基错误、旧浏览器的问题。 |
由于以下原因，问题被关闭：
- 公关和/或最新版本解决了报告的问题。
- 当前报告的副本。
- 最好在WordPress.org论坛中处理的帮助请求。
- 无法复制的问题。
- 一个需要更多信息的问题，而该问题的作者已有2周多没有回复。
- 被确定为无法修复或按预期工作的项目。
以下是在发布期间进行分类时需要遵循的一些指导原则。这一点很重要，可以将其与常规分类进行区分，从而正确识别出有问题的发布阻塞错误并找到解决方案。
- 如果在候选版本（RC）中引入了一个bug，它将破坏许多工作流，将其添加到版本里程碑和#核心编辑器WordPress.org中的频道松弛。
- 如果在最新版本中引入了错误，而下一个RC尚未发生，理想情况下，开发人员可以在RC之前进行修复！推动修复的力度应与破坏的可能性成比例。在这种情况下，添加到RC里程碑，如果认为紧急，则在#核心编辑器WordPress.org中的频道松弛。
- 如果最新版本中没有引入错误，不添加里程碑。相反，使用标签，如
[优先级]高如果这是一个紧迫的问题，如果需要，你可以在每周的核心会议上提请注意。
除了前面列出的一般分诊流程外，还有一些对流程的特定添加，用于对参与分诊的具有设计意识的人员进行更以设计为中心的分诊。
- 公关测试和评论：这应该是你每天自我分类的第一站。
- 标签
需要设计反馈：检查问题是否需要设计反馈，如果可能，给出反馈。可以按优先级、项目板或最少评论来组织。一旦有足够的意见，请删除此标签并决定下一步行动（即添加需求设计标签）。
- 标签
需求设计：它真的需要设计吗？这符合焦点吗？如果其设计标记为需要设计反馈以便更好地对问题进行分类。
提醒：
- 根据需要要求提供屏幕截图。
- 要求迭代并在合并之前记录所有更改。
- 如果问题不在董事会中，请检查它是否不符合特定的重点。
- 如果问题/拉动尚未确定优先级，请考虑添加优先级标签，以帮助将问题向前推进。
有关每周设计分类的更多详细信息，请参加查看本指南.