问题关闭说明

问题会基于以下原因被关闭：

某个拉取请求（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 以便更好归类问题。

提醒事项：

必要时请要求提供截图。
在合并前要求进行迭代并记录所有变更。
若问题未在看板中，请检查其是否适用于某个特定重点方向。
若问题或拉取请求尚未确定优先级，可考虑添加优先级标签以推动进展。

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

问题分类

为保持代码库的良好状态，需定期进行问题分类。问题分类是指审查现有议题和拉取请求，确保它们具有相关性、可操作性且包含所有必要信息的实践。任何人都可以协助分类，但若要对议题标签进行修改或编辑标题，您需要成为 Gutenberg 代码库分类团队的成员。

除本页面外，GitHub 问题分类教程也是了解分类工作的优质资源

加入分类团队

分类团队是由志愿者组成的开放团体，其专项职责是确保 Gutenberg 代码库的问题分类工作持续开展。分类工作存在多种形式：

由成员自主安排的定期个人分类时段
在固定时间组织的集体分类会议（可通过查阅会议页面了解这些分类会议及对应的 Slack 频道）
针对特定看板、标签或功能的专项分类会议

分类团队成员需符合以下期望：

每周至少完成一次分类工作（包括自主分类）
尽可能参加组织的集体分类会议
若您为特定标签或看板加入分类团队，请向其他成员说明您的专注领域

若您希望加入该团队，可随时在 #core-editor Slack 频道中提出申请。

处理首次分类任务

请从以下筛选列表中选择一项开始工作（注：在议题总页面点击“Sort”选项即可找到大部分筛选条件）：

所有未贴标签的 Gutenberg 议题。通过添加标签进行分类，可帮助专注特定领域的贡献者更便捷地发现相关议题并着手处理
所有未贴标签的 Gutenberg 拉取请求。此操作需具备代码基础能力，关于标签使用规范请查阅拉取请求标注指南。您也可随时与拉取请求作者确认标签是否准确反映其意图
最近更新日期最早的 Gutenberg 议题。对陈旧且可能过时的议题进行分类，可避免重要工作被遗漏
所有零评论的 Gutenberg 议题。处理此列表可确保所有议题获得关注，并识别需要补充信息或深入讨论的议题
Gutenberg 中评论数最少的议题。处理此列表有助于社区发现需要推动的提案
Gutenberg 中评论数最多的议题。若您能参与停滞的讨论，最佳处理方式是总结当前进展并明确待办事项/阻碍因素等，从而推动重要复杂议题的解决
您还可在 GitHub 上创建自定义筛选器。若您认为某个筛选器对社区有价值，欢迎提交拉取请求将其加入本列表

常规问题分类流程

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

首先搜索重复问题。若问题重复，请评论"重复 #问题编号"并关闭，同时将相关新信息补充至现有问题中（切记同时搜索已关闭问题中的重复项！）。
若问题缺少标签，请补充相应标签以便更好归类（需加入分类团队后获得相应权限）。添加标签时，建议先使用带[Type]前缀的标签（如[Type]功能增强或[Type]程序错误）标明问题类型，随后可添加更具描述性的标签。若问题涉及特定核心区块，可添加[Block]前缀标签；若影响特定功能，可使用[Feature]标签。最后还有针对特定关注领域的标签，如无障碍访问和国际化。可在此处查看所有可用标签。
若标题表述不够清晰，请编辑优化标题（需相应权限）。特别建议将问题相关的主要功能置于标题开头（示例），并尽量使标题简洁且具描述性（示例）。
若是错误报告，请测试确认或添加需测试标签。若信息不足无法确认，请添加[状态]需补充信息标签并索要必要细节。若错误报告缺少重现步骤，请要求提交者补充，这对问题排查尤为重要。
及时移除不再需要的[状态]需补充信息标签，例如当问题作者已提供足够详情的回复时。
若作者超过两周未回复，可备注后关闭未处理的[状态]需补充信息问题。
若问题存在讨论但未明确可执行步骤，请跟进参与者商定行动方案。在评论中回复时务必@每位参与者。
若您有信心进一步处理问题，还可：
- 通过调试验证错误报告有效性，尝试定位技术细节
- 核查问题是否缺少细节并尝试补充（例如当错误报告缺少视觉细节时，可在本地重现问题并上传截图或GIF）
- 若认为该问题适合新手贡献者尝试解决，可考虑添加"新手推荐"标签

常用标签

总体而言，以下标签在问题分类中非常实用，可能是您最常使用的标签。完整标签列表可在此处查看。

标签	适用场景
`[类型]程序错误`	现有功能出现故障时
`[类型]功能增强`	针对现有功能提出改进建议时
`[类型]求助请求`	用户咨询配置/实现相关问题时
`需技术反馈`	出现新功能提案或API变更建议时
`需补充信息`	问题描述不明确或需要补充细节时
`需测试`	新问题需要确认，或旧错误可能已失效时

优先级标签判定

若您对当前报告有充分了解且具备判断信心，可考虑添加优先级标签。请注意，未标注优先级即表示普通级别。

标签	适用场景
`优先级:高`	符合当前重点方向，且导致严重使用故障（包括流程问题、视觉错误和区块故障）
`优先级:低`	非重点方向的增强功能、边缘场景错误、旧版浏览器兼容问题

10 KiB Raw Blame History Unescape Escape