问题跟踪系统对于许多开源项目至关重要，虽然有很多开源工具提供此功能，但许多项目选择使用 GitHub 的内置问题跟踪器。
其简单的结构使其他人很容易参与进来，但问题实际上只取决于您如何处理它们。
如果没有流程，您的存储库可能会变得难以管理，充斥着重复的问题、模糊的功能请求或令人困惑的错误报告。项目维护者可能会因组织负担而感到压力，新贡献者可能难以理解优先事项所在。
在本文中，我将讨论如何将您的 GitHub 问题从良好提升到卓越。
作为用户故事的问题
我的团队与开源专家 Jono Bacon 进行了交谈，他是 社区的艺术 的作者，一位战略顾问，以及 GitHub 的前社区主管，他说高质量的问题是帮助项目成功的核心。他说，虽然有些人认为问题只是一大堆您必须处理的问题，但管理良好、经过分类和标记的问题可以为您的代码、您的社区以及问题所在提供令人难以置信的洞察力。
“在提交问题时，用户可能没有耐心或兴趣提供详尽的细节。因此，您应该尽可能使其变得容易，以便在最短的时间内从他们那里获得最有用的信息，”Jono Bacon 说。
一致的结构可以减轻项目维护者的很多负担，特别是对于开源项目。我们发现，鼓励用户故事方法有助于使清晰度成为常态。用户故事的通用结构解决了功能的“谁、什么和为什么”：作为 [用户类型]，我想要 [任务]，以便 [目标]。
以下是实际应用中的样子
作为客户，我想要创建一个帐户，以便我可以进行购买。
我们建议将用户故事放在问题的标题中。您还可以设置 问题模板 以保持一致性。
重点是使问题对于每个参与者来说都清晰明确：它尽可能简单地识别了受众（或用户）、行动（或任务）和结果（或目标）。不过，没有必要过分纠结于这种结构；只要故事的什么和为什么容易发现，您就做得很好。
良好问题的品质
并非所有问题都是平等的——任何 OSS 贡献者或维护者都可以证明这一点。一个结构良好的问题符合 敏捷武士 中概述的这些品质。
问问自己它是否是...
- 对客户有价值的东西
- 避免使用行话或晦涩难懂的语言；非专家应该能够理解它
- “切蛋糕”，这意味着它端到端地交付有价值的东西
- 如果可能，独立于其他问题；相关问题会降低范围的灵活性
- 可协商的，这意味着通常有几种方法可以达到既定目标
- 在时间和所需资源方面，小巧且易于估算
- 可衡量的；您可以测试结果
其他一切呢？处理约束
如果一个问题难以衡量或在短时间内似乎不可行完成，您仍然可以处理它。有些人称这些为“约束”。
例如，“产品需要快速”不符合故事模板，但它是不可协商的。但是多快才算快？模糊的需求不符合“好问题”的标准，但如果您进一步定义这些概念——例如，“产品需要快速”可以改为“每个页面需要在 0.5 秒内加载”——您可以更轻松地处理它。约束可以被视为内部成功指标，或要达到的里程碑。您的团队应该定期对其进行测试。
您的问题中包含什么？
在敏捷开发中，用户故事通常包括验收标准或需求。在 GitHub 中，我建议使用 markdown 检查列表来概述构成问题的任何任务。问题应该随着优先级的提高而变得更加详细。
假设您正在为网站创建一个新主页的问题。该任务的子任务可能如下所示。
如有必要，链接到其他问题以进一步定义任务。（GitHub 使这非常容易。）
尽可能精细地定义功能可以更轻松地跟踪进度、测试成功，并最终更频繁地交付有价值的代码。
一旦您以问题的形式收集了一些数据点，您就可以使用 API 来更深入地了解项目的健康状况。
“GitHub API 在这里非常有用，可以识别您的问题中的模式和趋势，”Bacon 说。“通过一些创造性的数据科学，您可以识别代码中的问题点、社区中的活跃成员以及其他有用的见解。”
一些问题管理工具提供 API，可以添加额外的上下文，例如时间估计或历史进度。
让其他人加入
一旦您的团队确定了问题结构，您如何让其他人接受？将您仓库的 ReadMe.md 文件视为您项目的“操作指南”。它应该清楚地定义您的项目做什么（理想情况下使用可搜索的语言），并解释其他人如何贡献（通过提交请求、错误报告、建议或贡献代码本身。）
这是分享您的 GitHub 问题指南的完美位置。如果您希望功能请求遵循用户故事格式，请在此处分享。如果您使用跟踪工具来组织您的产品积压，请分享徽章，以便其他人可以了解可见性。
“问题模板、合理的标签、关于如何提交问题的文档，以及确保您的问题得到快速分类和响应，这些对于您的开源项目都非常重要，”Bacon 说。
请记住：这不是为了流程而添加流程。而是建立一个结构，使其他人可以轻松发现、理解并放心地为您的社区做出贡献。
“将您的社区增长努力不仅集中在增加程序员的数量上，还要 [关注] 对帮助问题变得准确、最新以及成为积极对话和富有成效的问题解决来源的人感兴趣，”Bacon 说。
评论已关闭。