issue的分类办法

[cute-omega]

由于能看得懂代码又有精力维护的人不多了，所以我们必须得对所有issue分个轻重缓急。（主要每天一觉醒来几十个open issue实在吓人并且还分散注意力）

基本上就是引入几个issue tag做分类：

• known issues代表我们确认这的确是个问题（大多指bug，但是我们不用known bugs是为了避免和用户创建issue时选择的bug类型重复），有时候暗示我们一时半会修不了/没空修，先糊弄过去再说/有糊弄的办法了
• seem a problem就是看起来像known issues但是不确定，值得继续关注/等待反馈的
• Todo表示这个issue已经列入开发计划，等待实现/修复，一般不适用斩杀线，往往还会关联PR和版本号
• waiting for reply表示issue进入常规处理阶段（应对-反馈循环），我们已经回复了用户，正在等用户进一步反馈。适用斩杀线
• 斩杀线就是指如果在一定时间内没有进一步反馈就降低优先级，避免issue堆积成山；表现为关闭issue但保留waiting for reply，继续等待用户反馈，若有反馈则可以重新打开以提高优先级。斩杀线时间目前是三天。

现在issue的生命周期如下：

1. 用户提出issue并指明类型（bug/feature request/...）
2. 能直接解决的issue直接解决，重复的issue指路，感谢信收下，垃圾扔掉：然后转4或6
3. 否则，提出意见、分类（known issues/seem a problem）并等待回复，然后转4（有价值的不转）
4. 启动斩杀线，标志是issue打上waiting for reply：三天内若没有进一步反馈意见（有时会附加一些条件，如是否在最新版中复现、提供复现步骤等），则转6
5. 斩杀期内有反馈，则继续讨论（保留waiting for reply）并重新计时、列入开发计划（打上Todo，关联PR，可能还有版本号）并取消斩杀线或其他
6. 关闭issue
7. 检查issue是因为已解决/不成立等问题关闭，还是仅仅因为没有斩杀期内的回复呢？值得继续关注的issue分类为known issues/seem a problem并保留waiting for reply，可以在进一步反馈之后重新打开；否则取消waiting for reply并彻底停止关注

斩杀线也被用来处理年久失修的open issue，在这种情况下直接从第2步开始。

在这种情况下，issue分为：（按优先顺序排列）

0. 没来得及看的
1. 有价值的open issue，不适用斩杀线
2. 一般open issue，适用斩杀线
3. 值得继续关注，但最近没人管的issue，close但保留waiting for reply，一般还有known issues/seem a problem
4. 处理完的、重复的、不成立的、垃圾的issue，close且取消waiting for reply

所以如果你的issue被关掉请不要伤心，它可能只是因为我们没空而沦为二等issue了，如果有进一步进展依旧可以打开