Review issue 并为其打上标签
当 issue 被创建后，应该等待项目的 owner （owner 指项目的所有者，是对项目各方面都比较了解的人，可以为多个人） 对 issue 进行 Review。
Review 时，如果 owner 觉得这个 issue 满足下面的任意条件：
- 与项目本身的功能、市场定位有冲突
- 与现存 issue 有重复
- 其他不应该被保留的情况
则应该在评论中说明相关情况，并关闭该 issue。如果经过上面的过滤后，觉得 issue 应该被继续跟进，那就应该为它打上标签，方便之后的筛选、排期等工作。
“标签”是 issue 的核心特性，为了更好的使用它，我建议采用 “{type}/{value}” 这样的二维标签来取代传统的 “{value}” 单维标签，下面是一些常用的 issue 标签：
优先级：priority
优先级（priority）是最重要的标签之一。它直接影响 bug 需要被响应的速度、或需求的具体排期。 （经由 @云掩大椿 提醒，已修改为更符合惯例的定义）
priority/P0：十分紧急priority/P1：较为紧急priority/P2：普通priority/P3：不紧急
类型：kind
kind（类别）表示 issue 属于哪种类型。
kind/bug：软件缺陷kind/feature：新功能kind/enhancement：改进项，模块代码重构等不影响项目功能但是改善工程质量的 issue 可归入此类kind/research：技术调研类，一般以输出某类结论或报告视为结束
工作量：size
size（工作量）表示 issue 需要大约花费多少时间/精力，可以用来做简单的工作量评估参考。
size/XLsize/Msize/SM
领域/模块：area
area用于标记当前 issue 属于项目中的什么领域/模块。这个分类下的具体标签由项目本身决定。比如 area/apiserver、area/controller 等。给 issue 打上 area 标签后，项目不同模块的相关负责人可以更方便的找到自己负责的相关 issues。
GitLab 的标签是一个非常灵活的功能，在具体使用中，不必拘泥于上面列出来的这几种标签，可以根据当前项目特点随意调整。
issue 的后续操作
当 issue 被创建、打上标签以后，就可以进行后续操作了。issue 的后续操作主要包括下面几种：
认领 issue：每一个 issue 都有一个 Assignee（受理人），表示当前 issue 由谁在处理。在你准备开始具体的工作前，一定要记得将 issue 认领为自己所有。在 issue 下进行讨论：在 issue 下可以围绕 issue 进行讨论，在讨论过程中，可以通过 @USERNAME 的方式通知其他人关注当前 issue。
使用 issue 做项目里程碑管理
除了为 issue 打上标签以外，你还可以为 issue 绑定上 milestone（里程碑），来将 issue 与某些特定的项目节点关联起来。之后便可以在 milestones 页面查看每一个里程碑的进展。
和 labels 一样，里程碑也是一个十分灵活的功能，你可以根据项目需要建立不同的里程碑，比如：
基于软件版本号：基于未来将要发布的版本号建立里程碑，比如v1.0.3、v2.0.1等等基于时间周期：基于特定的时间周期 - 比如敏捷开发中的一个 sprint - 来建立里程碑，比如Y2017-M7W3、Y2017-M7W4等等
使用 issue board
使用 issue board（类似于敏捷开发中的“看板”），可以在一个页面看到当前处于不同阶段的所有 issues。这个功能非常适合站立晨会时使用。
勤于关闭 issues
随着项目越来越大，项目累积的 issue 也会越来越多。而这些 issue 中有很多已经失去它的价值。
所以，为了避免有价值的 issue 淹没在这些过时的信息当中，我们应该定期 Review 现有的 issues，关闭掉那些已经过时的 issues。