关于大多数开源项目来讲，问题追寻体系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 格局的清单来归纳处理这个问题单需求完结的使命。优先级越高的问题单应当包括更多的细节。

比方说，你计划提交一个关于新版网站主页的问题单。那这个问题单的子使命列表或许便是这样的：

运用 markdown 的清单把复杂问题拆分红多个部分在必要的情况下，你还能够链接到其他问题单，以进一步清晰使命。(GitHub 里做这个挺便利的)

将特性界说的越细化，越简单盯梢进展、测验，最终能更高效的发布有价值的代码。

以问题单的方式收到到问题地点后，还能够用 API 更深化的了解软件的健康度。

“在计算问题单的类型和趋势时，GitHub API 能够发挥巨大作用”，Bacon 告知咱们，“假如再做些数据发掘作业，你就能发现代码里的问题点、社区里的活泼成员，或许其他有用的信息。”

有些问题单办理东西供给的 API 能够进步额定信息，比方预估时刻或许前史进展。

团队协同共同

团队决议运用某种问题单模板后，怎么让所有人都照做?存储库里的 ReadMe.md 其实也能够是你们项意图 “How-to” 文档。这个文档应描绘清楚这个项目是做什么的(***是用能够查找的言语)，以及其他奉献者应当怎么参加进来(比方提交需求单、bug 陈述、主张，或许直接奉献代码)。

在 ReadMe 文件里添加明晰的阐明，供新协作者参阅ReadMe 文件是供给“问题单指引”的***场所。假如期望特性需求单遵从“用户讲故事”的格局，那就把格局写在 ReadMe 里。假如运用某种盯梢东西来办理待办事项，那就标记在 ReadMe 里，这样他人也能看到。

“问题单模板、合理的标签、提交问题单的辅导文档、保证问题单被分类并及时回应，这些关于开源项目都至关重要”，Bacon 说。

记住一点：这不是为了完结作业而做的作业。这是让其他人更轻松的发现、了解、融入你的社区而建立的规矩。

"重视社区的生长，不只要重视参加开发者的的数量增加，也要重视那些在问题单上协助咱们的人，他们让问题单愈加清晰、坚持更新，这是活泼交流和高效处理问题的力气源泉"，Bacon 说。