Github可以成为最强大的售票工具吗？

与所有其他票务 工具 相比 ， GitHub Issues是唯一使您可以完全自由地定义所需标签类型的平台。 所有其他工具都对标签类型有意见，例如优先级，严重性，组件，史诗等。现在，如果考虑到 2017年底 GitHub公共活动存储库的数量现在已达到 2500万 ，那么，这些公共（理解开源）项目中的大多数都是通过GitHub管理的，那么您可能想知道是否出现了任何最佳实践。 是否有无法应用于其他工具的独特最佳实践？ 我们都应该切换到GitHub在那里管理我们的项目吗？

在过去的几年中，我为两个开发人员平台CodinGame和Tech.io的开发做出了贡献。 他们在一起的开发人员总数超过100万。 我最近与他人共同创建了一个项目智能平台Anaxi 。 将其视为整个软件工程组织的可行的商业智能。 因此，我的工作之一就是确定软件开发工具的增长趋势。 换句话说，我很想这种事情！

首先，我们将分析20个最受欢迎的开源项目，它们的结构和使用的标签。

然后，我们将尝试找到常见的模式，以帮助我们了解何时以及如何将这些最佳实践应用于您的项目。

最后，我们将与其他现有的项目管理工具进行比较，以便您可以确定GitHub是否值得用作您的项目管理工具。

GitHub上的热门项目

我们分析了Linux基金会列出的GitHub上速度最高的30个开源项目，并选择了我们认为组织最完善的项目。 然后，我们分析了他们用来组织问题的标签，尤其是我们称之为标签类别的标签 。

我们如何称呼标签类别 ？ 一些标签显示以下模式：区域/网络，区域/主机，区域/备份。 “区域”是标签类别，可以有很多标签。

像上面的示例一样，某些项目使用“ /”来定义类别，而其他项目则使用“：”来定义（例如Tensorflow和Angular）。

这是我们选择的项目的列表以及它们使用的标签类别：

顺便说一句，您是否注意到大多数项目都是由大公司支持的？ Tensorflow和AngularJS由谷歌阵营的脸谱， 白鲸的码头工人， Ansible由RedHat和ElasticSearch的弹性。 在我们分析的30个清单中，有9个由基金会​​支持，只有6个没有实体支持。 我们对它们全部进行了分析，并在项目组织方面保持了一流的水平，最后每项都有一个（不是故意的）： CNCF的Kubernetes（基金会）和DefinitelyTyped （不支持）。

好的，让我们深入研究一下，看看现在有什么有趣的事情。

模式和最佳做法

我们确定了那些项目使用的7种不同类型的标签类别。 如果您认为以不同的方式组织类别会更有意义，请随时做出回应-我们都很高兴。 但是，这是我们的看法：

类型或种类：

在其他项目管理工具中，您将在此处获得错误，功能，任务或子任务。 但是正如您所看到的，GitHub项目可以通过实验 ， 讨论 ， 技术债务 ， 失败测试 ， 文档等进行更多扩展。 这对任何公司来说都可能很有趣。 现在，我们通常将不是错误或功能的所有内容都视为任务，但是无论团队规模如何，都能指定票证应该是有价值的。

状态/状态或分类/解决方案或生命周期：

我们将这些标签类别归为一组，因为它们都可以告知故障单的状态。 但是每个人都有细微差别。 这就是Kubernetes同时使用状态，分类和生命周期这三者的原因！ 分类和解决方案的用法类似； 他们解释了机票如何到达此状态/状态。 而Lifecycle在票证状态中描述票证的状态，并具有活动 ， 冻结 ， 腐烂 ， 陈旧的值 。 如果您要处理大量票证，这将变得非常方便，因为您可以使用一个过程来重新显示票证或只是将其收起以使更多的注意力集中在重要的事情上。

优先级，严重性或频率或解决方法：

我们将所有这四个问题放在一起，因为它们解决了相同的整体问题。 但是也有一些细微的差别。 您实际上可能认为严重性，频率和变通方法是3个不同的主题，可以更好地说明优先级。 更好的优先级划分会对您的业务产生重大影响。

组件或区域或特征：

与大多数其他方式不同，这些方式的使用方式相似。 例如，您将不会看到使用Component and Area或Feature的项目。 但是，有趣的部分是某些项目使用子类别，例如area / platform / …或area / os /… ，或者只是不同的标签类别，但用途相同，例如browser：..或cli：..这使您能够有2个级别的标签，可以更精确地定义代码真正涉及的部分。 在您的团队中，您可能需要一个人负责一个子类别，另一个人负责一个完整的类别及其所有子类别。 因此更好的授权和问责制。 这对于具有大型项目的大型团队特别有用。

难度，规模或经验或需求：

这部分涉及解决此票证所需的条件。 可能是时间，经验或其他依赖性。 其他项目管理工具（例如Pivotal Tracker）使您可以对故障单进行估算。 这里的要点是，您还可以添加有关票证所需经验水平的信息，这对于开源项目非常重要。 您将希望新手从简单的任务开始。 Angular还使用标签类别“需要”，其值包括更改，浏览器修复，文档，反馈，调查，jQuery修复，合并，更多信息，公共api，审阅，压榨，测试，工作 。 它使您可以更明确地说明将工单向前推进的工作。 通常，了解更改非常有用，因此您可以为社区或整个团队做好准备以进行更改。

里程碑相关：

在GitHub上，您可以添加里程碑。 但是某些项目添加了与里程碑相关的其他标签类别，例如里程碑/需要批准，里程碑/需要注意或里程碑/已删除 。 这创造了讨论和决定的机会。 实际上，一些每周会议的一部分可以专门用于里程碑/需求注意 。 Ansible还使用标签来指示票证可能影响的版本（即fects_1.2，受影响_2.3等）。 当您的客户和客户使用以前的版本（向后兼容性问题）时，这是非常重要的，除非软件是云托管的SaaS产品，否则这是每一种软件。

拉取请求相关：

GitHub首先用于代码版本控制，因此用于拉取请求。 Angular通常具有以下标签类别：

• 公关行动： 清理，讨论，合并，合并协助，审查
• PR状态： WIP，已阻止
• PR目标： 仅母版，母版和补丁，仅补丁

Kubernetes有拒收合并/与像阻塞的道路，保持和工作在进度值。

这样可以弄清楚票证状态的原因。 我个人的感觉是，这不适用于大多数非开源软件项目。 随时不同意！

那么哪种售票工具是最好的呢？

首先，请注意，您要求团队提供的任何其他信息对他们来说都是额外的努力。 如果他们觉得不值得，他们自然不会付出努力，这将毫无用处！ 因此，如果您正在考虑编辑工具和流程，则最好只考虑特定项目的价值。

让我们以3个不同的例子来说明这一点。 我绝不声称以下几点适用于您的特定情况； 只有您知道什么对您的团队有效。

如果您的初创企业少于30名工程师

我认为将票证类型扩展到文档和重构仍然可以提供价值。 您的部署过程不会那么复杂，因此您不需要在状态和请求请求周围添加任何其他标签。 同样，里程碑不应包含太多复杂性。 能够详细说明频率，严重性以及是否有解决方法仍然很有价值，但是在启动模式下，您宁愿将花费在输出上的时间最大化，而不是将其花费在干净的过程上。 最后，对于拥有多层组件的产品来说，它应该不会太复杂。 因此，总的来说，GitHub提供的灵活性是一个不错的选择，但是显然，如果没有它，您可以使用其他提供更好用户体验的工具（例如Trello）来拥有非常干净的流程。

如果您有几个团队从事多种产品

如果您希望对所有项目都具有某种可见性，那么如果希望团队在此基础上构建一致的报告，则最好在所有团队中使用相同的工具。 好吧，实际上，我们正在Anaxi解决这个问题。 稍后再说。 我认为这与启动案例非常相似。 这实际上取决于团队规模。

如果您有大型团队使用相同的产品

通常，这将适用于任何复杂的软件或实际的开源项目。 在这种情况下，标签类别中列出的所有点均适用。 并且任何其他标签类别都可以增加价值。 重点不再是个人输出，而是最佳沟通，以实现最佳集体输出。 这就是为什么许多企业构建自己的内部售票工具但收效甚微的原因。 GitHub对他们来说可能是一个很好的解决方案。 但是，GitHub存在UX和可见性问题，但可以解决。 怎么样？ 继续阅读。

但是GitHub缺少了很多……？

就项目管理功能而言，尽管最近在GitHub 方面取得了很大进步 ，但GitHub并未提供最佳体验。 但是我们仍然遗漏了很多东西：

• 该界面允许您将标签输入为文本。 没有选择器。 因此，您必须了解标签的基本结构。
• 创建问题时，您无法制作任何必需的标签
• 如果您要监视分配给它们的票证，则标签非常有用。 不幸的是，您不能在GitHub上执行此操作。
• 老实说，在GitHub上没有项目的可见性。

这就是为什么Jira是世界上最常用的工具。 您可以部分自定义您的工作流程（不幸的是，在GitHub范围内）； 它提供了足够好的UX，可以每天管理票证和一组报告，因此您具有某种可见性。

如果我告诉您有一个工具可以集成GitHub，并让您使用标签类别，就像它们最初是GitHub的一部分一样（带有选择器），该怎么办？ 您还可以监视每个标签的问题，并获得缺少的可见性。 这实际上就是 Anaxi 所做的。 还有更多。

希望本文能帮助您考虑一下您的流程，更准确地说，是您使用的标签。

你走之前…

您觉得这篇文章有趣吗？ 请按住????说“谢谢”并帮助其他人找到它！
如果您对有关工程和产品领导力，生产力以及如何扩大团队规模的文章感兴趣，请订阅我们的新闻通讯！

或加入我们的工程领导社区 。

您还可以查看我的最新文章：

最初于 2018 年9月25日 在 anaxi.com 上 发布 。

From: https://hackernoon.com/how-github-can-be-the-most-powerful-ticketing-tool-bca51f038d21