问题分类

概述

RAPIDS 项目使用的问题分类方法总结。

目标受众

开发者

项目负责人

分类目标

RAPIDS 项目持续分类新问题并频繁重新分类现有问题。这是为了确保高优先级问题得到及时解决，并且社区能够获得所提交问题的频繁更新。

分类流程

时间安排

在2个工作日内标记并确定新问题的优先级
使用项目的问体跟踪看板每周重新确定现有问题的优先级

跟踪看板

每个项目有3个问题跟踪看板和1个发布跟踪看板

Bug Squashing (错误压制) - 跟踪并确定错误的优先级
Feature Planning (特性规划) - 跟踪并确定特性请求的优先级
Other Issues (其他问题) - 跟踪文档、问题和其他问题
Release (发布) - 跟踪当前发布的进展

Bug Squashing、Feature Planning 和 Other Issues 是永久性的跟踪看板，用作发布规划的基础。Release 看板不是永久性的，在发布完成后关闭。上面的示例看板来自 cuDF 项目。

每个永久性项目看板（Bug Squashing、Feature Planning 和 Other Issues）包含以下列

列	目的
需要确定优先级	已通过 `Initial triage (初始分类)` 阶段，现在需要确定优先级的问题
热修复 - 当前发布	需要立即为当前 `M.A` 发布解决的热修复问题
下个发布	应在当前开发周期内为下个 `M.B` 发布解决的问题
未来发布	应为下个 `M.C` 或 `M.D` 发布确定优先级的问题
待办事项	所有其他未解决的问题
已关闭	已关闭的问题将自动移至此列

请参阅发布看板，了解与发布看板相关的列定义。

重要提示：通过利用跟踪看板进行问题管理，项目负责人可以通过将问题放入适当的列来安排问题，然后通过将问题从列顶部的最高优先级拖动并排序到底部的最低优先级来确定问题的优先级。我们还可以使用问题/PR 上的标签来过滤和确定工作的优先级。

通过将问题放入这些永久性看板（Bug Squashing、Feature Planning 或 Other Issues）中的一个，提交者和社区将看到问题的更新，并可以大致了解何时能收到反馈。例如，对于某个特定问题，用户可能会看到 Future release in Other Issues (Other Issues 看板中的未来发布)，这允许提交者或社区评论他们是否认为该问题应更快得到解决。

流程周期

每个问题的一般流程周期是

                                                  /------------> Hotfix --> Assign developer --> Link to PR --> Automatically close issue on PR merge
                                                  |
New issue filed --> Initial triage --> Prioritize & schedule --> Next release --> Prioritize in release --> Assign developer --> Link to PR --> Automatically close issue on PR merge
                                                  |
                                                  \------------> Future release --> Re-prioritize every week

问题可以在 Initial triage (初始分类) 步骤中关闭，并将适当地记录关闭原因。例如：重复问题、确定超出范围的问题和/或不会修复的问题。

提交新问题

新问题通常使用项目的问题模板提交。这会自动为问题标记问题类型和 ? - Needs Triage (需要分类) 标签。这有助于识别问题并将其移动到正确的项目看板进行分类。

对于未使用问题模板提交的问题，应标记 ? - Needs Triage (需要分类) 标签和正确的问题类型标签。标记后，应将其移动到与给定问题类型相应的项目看板。

查找问题

每种跟踪看板类型都有一个过滤器，在使用 Add cards (添加卡片) 功能时可以使用。这会将显示的结果限制为仅与该跟踪看板相关的问题，不显示拉取请求。

看板	过滤器
Bug Squashing (错误压制)	`is:open is:issue label:bug no:project`
Feature Planning (特性规划)	`is:open is:issue label:"feature request" no:project`
Other Issues (其他问题)	`is:open is:issue -label:bug -label:"feature request" no:project`

初始分类

项目负责人 - 每日

确保问题类型正确，即该问题是真的错误还是特性请求？
审查问题内容，提交者是否提供了该问题类型所需的所有信息？如果不是，请请求澄清。
添加任何相关的项目标签，例如 cuda、python 等。
如果适用，考虑为问题添加 good first issue (适合新手) 或 help wanted (需要帮助) 标签。
移除 ? - Needs Triage (需要分类) 标签。
将问题移动到其关联的跟踪看板。这将把问题放入该看板的 Needs prioritizing (需要确定优先级) 列，为下一阶段做好准备。

确定优先级并安排

问题分类后，我们可以确定其优先级并为发布安排时间。

重要提示：通过利用问题跟踪看板，项目负责人可以通过将问题放入适当的列来安排问题，然后通过将问题从列顶部的最高优先级拖动并排序到底部的最低优先级来确定问题的优先级。

项目负责人 - 每日

对于 Needs prioritizing (需要确定优先级) 列中的每个问题，审查并确定其优先级。
对于已添加到 Hotfix (热修复) 和 Next release (下个发布) 列的问题，请遵循以下步骤。
对所有3个跟踪看板重复此过程。

项目负责人 - 每周

归档 Closed (已关闭) 列中的所有问题。
审查 Next release (下个发布)、Future release (未来发布) 和 Backlog (待办事项) 各列中的所有问题，确保问题仍然得到适当的安排。
确定 Future release (未来发布) 和 Backlog (待办事项) 列中任何问题的优先级。Hotfix (热修复) 和 Next release (下个发布) 无需重新确定优先级，因为它们应该已经在积极开发中。
与团队讨论 Hotfix (热修复) 和 Next release (下个发布) 列中所有问题的状态，以确保开发正在取得进展且没有阻碍。
对所有3个跟踪看板重复此过程。

热修复

验证该问题是否是热修复。
确定解决热修复所需的项目负责人。
与干系人和运营团队就提议的热修复召开会议，以确定前进方向。
尽快指定一名开发者或团队来修复该问题。

下个发布

确保将每个问题添加到发布看板项目中。
将问题的优先级传达给团队。
在发布看板上根据商定的优先级更新问题。
根据问题的优先级指定一名开发者，或者等待其他更高优先级的问题先完成。

分配开发者

应将开发者分配给他们负责交付的问题。尽量限制开发者的工作负担。一般规则是，限制活跃开发的问题数量为5个或更少。

重要提示：这对社区参与至关重要，因为已分配的问题看起来像有人负责了，不会收到任何输入或帮助。

链接到 PR

每个拉取请求的描述中应包含问题编号，使用 Addresses #[issue number]，这样当 PR 合并时，创建该 PR 的问题也会自动关闭。