玩转GitHub的问题单（issue）-CSDN博客

对于大多数开源项目来讲，问题追踪系统Issue-tracking system是至关重要的。虽然有非常多的开源工具提供了这样的功能，但是大量项目还是选择了 GitHub 自带的问题追踪器Issue Tracker。

它结构简单，可以让其他人可以非常轻松地参与进来，但这才仅仅是开始。

如果没有适当的处理，你的储存库repository会变得很庞大，挤满重复的问题单、模糊不明的特性需求单、含混的 bug 报告单。项目维护者会被大量工作压得喘不过气来，新的贡献者也搞不清楚项目当前的工作重点是什么。

接下来，我们一起研究下，如何玩转 GitHub 的问题单。

问题单就是用户的故事

我的团队曾经和开源专家 Jono Bacon 做过一次对话，他是《社区艺术》The Art of Community一书的作者、一位战略顾问、前 GitHub 社区总监。他告诉我们，高质量的问题单是项目成功的关键。有些人把问题单仅仅看作是一堆你不得不去处理的问题列表，但是如果这些问题单管理完善，进行了分类并打上标签，会令人意想不到的提升我们对代码和社区的了解程度，也让我们更清楚问题的关键点在哪里。

“在提交问题单时，用户不太会有耐心或者有兴趣把问题的细节描述清楚。在这种情况下，你应当努力花最短的时间，尽量多的获取有用的信息。”，Jono Bacon 说。

统一的问题单模板可以大大减轻项目维护者的负担，尤其是开源项目的维护者。我们发现，让用户讲故事的方法总是可以把问题描述的非常清楚。用户讲故事时需要说明“是谁，做了什么，为什么而做”，也就是：我是【何种用户】，为了【达到何种目的】，我要【做何种操作】。

实际操作起来，大概是这样的：

我是一名顾客，我想购买东西，所以我想创建个账户。我们建议，问题单的标题始终使用这样的用户故事形式。你可以设置问题单模板来保证一致性。

问题单模板让特性需求单保持统一的形式这个做法的核心点在于，问题单要清晰的呈现给它涉及的每一个人：它要尽量简单的指明受众(或者说用户)，操作(或者说任务)，和输出(或者说目标)。不过，不需要过分拘泥于这个模板，只要能把故事里的是什么事情或者是什么原因说清楚，就达到目的了。

高质量的问题单

问题单的质量是参差不齐的，这一点任何一个开源软件的贡献者或维护者都能证实。在《The Agile Samurai》中概述过一个良好的问题单所应具备的素质。

好的问题单尽量满足如下条件：

客户价值所在
避免使用术语或晦涩的文字，就算不是专家也能看懂
可以切分，也就是说我们可以逐步解决问题
尽量跟其他问题单没有瓜葛，依赖其它问题会降低处理的灵活性
可以协商，也就说我们有好几种办法达到目标
问题足够小，可以非常容易的评估出所需时间和资源
可衡量，我们可以对结果进行测试

不满足上述条件的问题单呢? 要有约束

如果一个问题单很难衡量，或者很难在短时间内完成，你也一样有办法搞定它。有些人把这种办法叫做“约束”(constraints)。

例如，“这个产品要快”，这种问题单不符合故事模板，而且是没办法协商的。多快才是快呢?这种模糊的需求没有达到“好问题单”的标准，但是如果你进一步定义一下，例如“每个页面都需要在 0.5 秒内加载完”，那我们就能更轻松地解决它了。我们可以把“约束”看作是成功的标尺，或者要实现的里程碑。每个团队都应该定期的对“约束”进行测试。

问题单里面有什么?

敏捷方法中，用户故事里通常要包含验收指标或者标准。在 GitHub 里，建议大家使用 markdown 格式的清单来概括解决这个问题单需要完成的任务。优先级越高的问题单应当包含更多的细节。

比如说，你打算提交一个关于新版网站主页的问题单。那这个问题单的子任务列表可能就是这样的：