PUB:20160718 Tips for managing your project's issue tracker

@echoma

published/20160718 Tips for managing your project's issue tracker.md

@@ -1,12 +1,13 @@
-管理项目问题追踪器的几个小窍门
+玩转 GitHub 的问题单（issue）
 ==============================================
 
 ![](https://opensource.com/sites/default/files/styles/image-full-size/public/images/business/BUSINESS_opennature_3.png?itok=30fRGfpv)
+
 ***图片来源:***  opensource.com
 
-对于大多数开源项目来讲，问题追踪系统是至关重要的。虽然有非常多的开源工具提供了这样的功能，大量项目还是选择了 GitHub 自带的问题追踪器（Issue Tracker）。
+对于大多数开源项目来讲，问题追踪系统（Issue-tracking system）是至关重要的。虽然有非常多的开源工具提供了这样的功能，但是大量项目还是选择了 GitHub 自带的问题追踪器（Issue Tracker）。
 
-它结构简单，因此其他人可以非常轻松地参与进来，但这才刚刚开始。
+它结构简单，可以让其他人可以非常轻松地参与进来，但这才仅仅是开始。
 
 如果没有适当的处理，你的储存库（repository）会变得很庞大，挤满重复的问题单、模糊不明的特性需求单、含混的 bug 报告单。项目维护者会被大量工作压得喘不过气来，新的贡献者也搞不清楚项目当前的工作重点是什么。
 
@@ -14,8 +15,7 @@
 
 ### 问题单就是用户的故事
 
-我的团队曾经和开源专家 [Jono Bacon][1] 做过一次对话，他是 [The Art of Community][2] 的作者、GitHub 的战略顾问和前社区总监。他告诉我们，高质量的问题单是项目成功的关键。有些人把问题单仅仅看作是一堆你不得不去处理的问题列表，但是如果这些问题单管理完善，进行了分类并打上标签，会令人意想不到的提升我们对代码和社区的了解程度，也让我们更清楚问题的关键点在哪里。
-
+我的团队曾经和开源专家 [Jono Bacon][1] 做过一次对话，他是 [社区艺术（The Art of Community）][2] 的作者、一位战略顾问、前 GitHub 社区总监。他告诉我们，高质量的问题单是项目成功的关键。有些人把问题单仅仅看作是一堆你不得不去处理的问题列表，但是如果这些问题单管理完善，进行了分类并打上标签，会令人意想不到的提升我们对代码和社区的了解程度，也让我们更清楚问题的关键点在哪里。
 
 “在提交问题单时，用户不太会有耐心或者有兴趣把问题的细节描述清楚。在这种情况下，你应当努力花最短的时间，尽量多的获取有用的信息。”，Jono Bacon 说。
 
@@ -28,13 +28,11 @@
 我们建议，问题单的标题始终使用这样的用户故事形式。你可以设置[问题单模板][3]来保证一致性。
 
 ![](https://opensource.com/sites/default/files/resize/issuetemplate-new-520x293.png)
-          
 
 *问题单模板让特性需求单保持统一的形式*
 
 这个做法的核心点在于，问题单要清晰的呈现给它涉及的每一个人：它要尽量简单的指明受众（或者说用户），操作（或者说任务），和输出（或者说目标）。不过，不需要过分拘泥于这个模板，只要能把故事里的是什么事情或者是什么原因说清楚，就达到目的了。
 
-
 ### 高质量的问题单
 
 问题单的质量是参差不齐的，这一点任何一个开源软件的贡献者或维护者都能证实。在[《The Agile Samurai》][4]中概述过一个良好的问题单所应具备的素质。
@@ -49,15 +47,15 @@
 - 问题足够小，可以非常容易的评估出所需时间和资源
 - 可衡量，我们可以对结果进行测试
 
-### 不满足的问题单呢? 要有约束
+### 不满足上述条件的问题单呢? 要有约束
 
 如果一个问题单很难衡量，或者很难在短时间内完成，你也一样有办法搞定它。有些人把这种办法叫做“约束”（constraints）。
 
-例如，“这个产品要快”，这种问题单不符合故事模板，而且是没办法协商的。多快才是快呢？这种模糊的需求没有达到“好问题单”的标准，但是如果你进一步定义一下，例如“每个页面都需要在0.5秒内加载完”，那我们就能更轻松地解决它了。我们可以把“约束”看作是成功的标尺，或者要实现的里程碑。每个团队都应该定期的对“约束”进行测试。
+例如，“这个产品要快”，这种问题单不符合故事模板，而且是没办法协商的。多快才是快呢？这种模糊的需求没有达到“好问题单”的标准，但是如果你进一步定义一下，例如“每个页面都需要在 0.5 秒内加载完”，那我们就能更轻松地解决它了。我们可以把“约束”看作是成功的标尺，或者要实现的里程碑。每个团队都应该定期的对“约束”进行测试。
 
 ### 问题单里面有什么？
 
-敏捷方法中，用户的故事里通常要包含验收指标或者标准。在 GitHub 里，建议大家使用 markdown 的清单来概括解决这个问题单需要完成的任务。优先级越高的问题单应当包含更多的细节。
+敏捷方法中，用户故事里通常要包含验收指标或者标准。在 GitHub 里，建议大家使用 markdown 格式的清单来概括解决这个问题单需要完成的任务。优先级越高的问题单应当包含更多的细节。
 
 比如说，你打算提交一个关于新版网站主页的问题单。那这个问题单的子任务列表可能就是这样的：
 
@@ -71,17 +69,17 @@
 
 以问题单的形式收到到问题所在后，还可以用 API 更深入的了解软件的健康度。
 
-“在统计问题单的类型和趋势时，GitHub API 可以发挥巨大作用”，Bacon告诉我们，“如果再做些数据挖掘工作，你就能发现代码里的问题点，社区里的活跃成员，或者其他有用的信息。”
+“在统计问题单的类型和趋势时，GitHub API 可以发挥巨大作用”，Bacon 告诉我们，“如果再做些数据挖掘工作，你就能发现代码里的问题点、社区里的活跃成员，或者其他有用的信息。”
 
 有些问题单管理工具提供的 API 可以提高额外信息，比如预估时间或者历史进度。
 
 ### 团队协同一致
-团队决定使用某种问题单模板后，如何让所有人都照做？存储库里的 ReadMe.md 其实也可以是你们项目的 “How-to” 文档。这个文档应描述清楚这个项目是做什么的（最好是用可以搜索的语言），以及其他贡献者应当如何参与进来（比如提交需求单、bug 报告、建议，或者直接贡献代码）。
 
+团队决定使用某种问题单模板后，如何让所有人都照做？存储库里的 ReadMe.md 其实也可以是你们项目的 “How-to” 文档。这个文档应描述清楚这个项目是做什么的（最好是用可以搜索的语言），以及其他贡献者应当如何参与进来（比如提交需求单、bug 报告、建议，或者直接贡献代码）。
 
 ![](https://opensource.com/sites/default/files/resize/readme-520x184.png)
 
-*在 ReadMe 文件里增加清晰的说明，供新合作者参考*
+*在 ReadMe 文件里增加清晰的说明，供新协作者参考*
 
 ReadMe 文件是提供“问题单指引”的完美场所。如果希望特性需求单遵循“用户讲故事”的格式，那就把格式写在 ReadMe 里。如果使用某种跟踪工具来管理待办事项，那就标记在 ReadMe 里，这样别人也能看到。