管理项目的问题跟踪器的提示

问题跟踪系统对于许多开源项目都很重要&＃xff0c;并且有许多提供此功能的开源工具&＃xff0c;但是许多项目选择使用GitHub的内置问题跟踪器。

它的简单结构使其他人很容易衡量&＃xff0c;但问题实际上仅与您提出的一样好。

没有流程&＃xff0c;您的存储库可能变得笨拙&＃xff0c;重复问题&＃xff0c;模糊的功能请求或令人困惑的错误报告。 项目维护者可能会受到组织负担的负担&＃xff0c;新的贡献者可能很难理解优先级。

在本文中&＃xff0c;我将讨论如何将您的GitHub问题统统解决。

作为用户故事的问题

我的团队与开源专家Jono Bacon进行了交谈&＃xff0c; Jono Bacon 是社区艺术的作者 &＃xff0c;战略顾问&＃xff0c;GitHub的前社区总监&＃xff0c;他说高质量的问题是帮助项目成功的核心。 他说&＃xff0c;尽管有些人将问题视为您必须解决的一大问题&＃xff0c;但妥善管理&＃xff0c;分类和标记问题可以为您的代码&＃xff0c;社区以及问题所在提供令人难以置信的洞察力。

Jono表示&＃xff1a;“在提交问题时&＃xff0c;用户可能对提供广泛的细节没有耐心或兴趣。因此&＃xff0c;您应该尽可能地轻松地从他们那里获取最有用的信息。”培根说。

一致的结构可以减轻项目维护人员的负担&＃xff0c;尤其是对于开源项目。 我们发现鼓励用户故事方法有助于使清晰度保持不变。 用户故事的通用结构涉及功能的“谁&＃xff0c;什么以及为什么”&＃xff1a;作为[用户类型]&＃xff0c;我想[任务]以便[目标]。

这是实际的情况&＃xff1a;

作为客户 &＃xff0c;我想创建一个帐户以便可以进行购买 。

我们建议在该问题的标题中粘贴该用户故事。 您还可以设置问题模板以保持事物的一致性。

关键是使涉及的每个人都能清楚地定义问题&＃xff1a;它尽可能简单地标识出受众 &＃xff08;或用户&＃xff09;&＃xff0c; 动作 &＃xff08;或任务&＃xff09;和结果 &＃xff08;或目标&＃xff09;。 但是&＃xff0c;无需沉迷于此结构&＃xff1b; 只要能轻松发现故事的内容和原因 &＃xff0c;就可以了。

好问题的品质

并非所有问题都是平等的-任何OSS贡献者或维护者都可以证明。 格式正确的问题符合《敏捷武士》中概述的这些品质。

问问自己是否...

• 对客户有价值的东西
• 避免行话或大笨钟&＃xff1b; 非专家应该能够理解它
• “切片蛋糕”&＃xff0c;这意味着它端到端地交付了有价值的东西
• 尽可能独立于其他问题&＃xff1b; 相关问题降低了范围的灵活性
• 可以协商的&＃xff0c;这意味着通常有几种方法可以实现既定目标
• 在所需的时间和资源上很小并且很容易估算
• 可测量的 您可以测试结果

那其他的呢&＃xff1f; 处理约束

如果问题难以衡量或在短期内似乎无法解决&＃xff0c;您仍然可以使用它。 有人称这些为“约束”。

例如&＃xff0c;“产品需要快速交付”不适合故事模板&＃xff0c;但不可转让。 但是速度有多快&＃xff1f; 含糊的要求不符合“好问题”的标准&＃xff0c;但是&＃xff0c;如果您进一步定义这些概念&＃xff08;例如&＃xff0c;“产品需要快速运输”可以是“每个页面需要在0.5秒内加载”&＃xff09;&＃xff0c;则可以工作它更容易。 约束可以看作是成功的内部指标&＃xff0c;也可以看作是一个里程碑。 您的团队应定期对其进行测试。

您的问题是什么&＃xff1f;

在敏捷中&＃xff0c;用户故事通常包括接受标准或要求。 在GitHub中&＃xff0c;我建议使用markdown清单来概述构成问题的所有任务。 随着优先级的提高&＃xff0c;问题应该更加详细。

假设您正在围绕网站的新主页创建问题。 该任务的子任务可能看起来像这样。

如有必要&＃xff0c;请链接到其他问题以进一步定义任务。 &＃xff08;GitHub使其非常容易。&＃xff09;

尽可能细化地定义功能使跟踪进度&＃xff0c;测试成功并最终更频繁地发布有价值的代码变得更加容易。

一旦以问题的形式收集了一些数据点&＃xff0c;就可以使用API​​来更深入地了解项目的运行状况。

培根说&＃xff1a;“ GitHub API在确定问题的模式和趋势方面可能非常有用。” “借助一些创新的数据科学&＃xff0c;您可以识别代码中的问题点&＃xff0c;社区的活跃成员以及其他有用的见解。”

一些问题管理工具提供了添加其他上下文的API&＃xff0c;例如时间估计或历史进度。

让其他人加入

一旦您的团队决定了问题的结构&＃xff0c;您将如何让其他人参与进来&＃xff1f; 将回购的ReadMe.md文件视为项目的“操作方法”。 它应该清楚地定义您的项目做什么&＃xff08;最好使用可搜索的语言&＃xff09;&＃xff0c;并说明其他人可以如何做出贡献&＃xff08;通过提交请求&＃xff0c;错误报告&＃xff0c;建议或贡献代码本身&＃xff09;。

这是分享您的GitHub问题准则的理想之地。 如果希望功能请求遵循用户故事格式&＃xff0c;请在此处共享。 如果您使用跟踪工具来组织产品积压&＃xff0c;请共享徽章&＃xff0c;以便其他人可以看到。

培根说&＃xff1a;“问题模板&＃xff0c;明智的标签&＃xff0c;有关如何提交问题的文档以及确保对问题进行分类和快速响应都是非常重要的”&＃xff0c;Bacon说。

切记&＃xff1a;这不是为了流程而添加流程。 这是关于建立一种结构&＃xff0c;使其他人可以轻松地发现&＃xff0c;理解和自信地为您的社区做出贡献。

培根说&＃xff1a;“不仅要增加程序员的数量&＃xff0c;还要着重社区的发展&＃xff0c;而且还要对有兴趣帮助人们准确&＃xff0c;及时更新问题&＃xff0c;以及进行积极对话和有效解决问题的人们&＃xff0c;”。

翻译自: https://opensource.com/life/16/7/how-take-your-projects-github-issues-good-great