GitHub Issues 当成轻量需求池时，要先定标签
· 阅读需 2 分钟
GitHub Issues 一开始用起来很简单，谁发现问题谁就开一条，评论、补充截图、贴 commit，都很顺手。可只要项目稍微多一点需求，Issue 一多，列表就会迅速变成一锅粥。到了 2013 年我自己开始比较频繁地用它协作时，最明显的感受就是：Issue 系统如果没有最基础的标签约定，很快就会从“记录问题的地方”变成“堆问题的地方”。
为什么标签比里程碑更值得先做
很多人喜欢一上来就规划 milestone、版本节奏、复杂看板，但小团队初期真正最缺的，往往不是宏大规划，而是最基础的分类能力。
只要标签先立住，你至少能快速看清：
- 哪些是 bug
- 哪些是新需求
- 哪些只是优化建议
- 哪些是暂时不做但值得保留的想法
没有这层分类，Issue 再多一点就只能靠记忆。
我后来比较喜欢的最小标签集
我不太赞成一开始就做十几二十种标签，那样维护成本太高。
更够用的一套是：
bugfeatureimprovementdiscussionwontfix或later
这些标签不炫，但能很快把问题池分层。
标签一旦立住，讨论质量也会变
一个 Issue 被打成 discussion，大家就更容易接受它暂时没有明确结论；被打成 bug，大家天然会关注复现和影响范围；被标成 feature，讨论重心也会偏向需求本身。
也就是说，标签不只是筛选工具，它还是在帮团队定义讨论语境。
我最不喜欢的一种状态
就是所有 Issue 都只有标题，没有分类，靠评论不断往下滚。
这种状态短期看似自由，长期其实很难沉淀。因为一旦要开下一轮开发、回头找历史决策或者统计哪些问题反复出现，信息几乎是散的。
小结
GitHub Issues 很适合做轻量需求池，但前提是它得先能被整理。
对 2013 年那种小团队、小项目、快速试错的节奏来说，标签比复杂流程更重要。先把标签定好，Issue 才会从“留言板”慢慢变成真正能用的协作面板。