快速在GitHub搭建一个规范的开源项目(二)

上一篇博客快速在GitHub搭建一个规范的开源项目(一)我们讲了如何如何初始一个团队并且制定了规范的开发流程和代码提交流程。
这一篇我们来讲讲如何正确使用Issue。
很多人其实对Issue功能存在误解，认为Issue就是用来提交bug的，其实不然。GitHub上的Issue功能非常强大，使用好了的话完全可以充当一部分JIRA的功能，可以方便做版本复盘，以及收集需求，然后可以可以成为大家讨论问题的地方。

概念

这里我们先来介绍几个概念：

Milestones

一般有这么几种情况可以创建一个里程碑。发布一个新的版本，重新设计，目标冲刺。

Labels

可以标记问题作为不同类型的问题，一个issue可以有很多个标签，以用来筛选。

Assignees

选择一个问题接收人，此人可以负责推动问题的解决。

Notifications

通知可以帮助你了解问题的最新进展，接收通知的方式有两种：通过电子邮件和通过网络。

@mentions

@mentions是在GitHub Issue中引用其他GitHub用户的方式。在问题的描述或任何评论中，包括另一个GitHub用户的@username，向他们发送通知。通知个人语法：/cc @githu用户名。通知团队语法：/cc @组织名/团队名。

References

问题取决于其他问题，或者至少与它们相关，您希望将两者联系起来。您可以通过输入井号和问题编号来引用问题。语法：#问题编号
另外一种有意思的用法是开发人员提交PR到master分支时，commits中包含“Fixes”, “Fixed”or“Fix”or “Closes”or “Closed” or “Close” #问题编号。也将自动关闭问题。

Issue Dashboard

可以用来统计问题版本，label,责任人等等情况。在开源项目中可以充当JIRA作用。

好了，有了上面几个概念的支持。我们可以讲一下Bug修改流程了。
首先由开源软件维护者创建issue模板，标签，里程碑(跟版本计划有关)。
下面我们提供常用的标签以及几个模板，至于如何创建我们可以参考这个文档参考链接。

标签

type/bug
type/feature
type/question
type/duplicate
level/easy
level/medium
level/tricky
reason/version-conflict
reason/code
status/decilined
status/fix-in-next-release

常用模板

bug_report.md

---
name: '报告Bug 🐛'
about: 报告 Extension 的 bug
title: '🐛[BUG]'
labels: '🐛bug'
assignees: ''
---

### 🐛 bug 描述

<!--
详细地描述 bug，让大家都能理解
-->

### 📷 复现步骤

<!--
清晰描述复现步骤，让别人也能看到问题
-->

### 🏞 期望结果

<!--
描述你原本期望看到的结果
-->

### 💻 复现代码

<!--
提供可复现的代码，仓库，或线上示例
-->

### © 版本信息

- Extension 版本: [e.g. 1.0.0]
- JDK 版本: [e.g. 1.8.0_221]
- Spring 版本: 
- 开发环境 [e.g. mac OS]

### 🚑 其他信息

<!--
如截图等其他信息可以贴在这里
-->

feature_request.md

---
name: '功能需求 ✨'
about: 对 Extension 的需求或建议
title: '👑 [需求]'
labels: '👑Feature Request'
assignees: ''
---

### 🥰 需求描述

<!--
详细地描述需求，让大家都能理解
-->

### 🧐 解决方案

<!--
如果你有解决方案，在这里清晰地阐述
-->

### 🚑 其他信息

<!--
如截图等其他信息可以贴在这里
-->

question.md

---
name: '疑问或需要帮助 ❓'
about: 对 Extension 使用的疑问或需要帮助
title: '🧐[问题]'
labels: '🧐question'
assignees: ''
---

### 🧐 问题描述

<!--
详细地描述问题，让大家都能理解
-->

### 💻 示例代码

<!--
如果你有解决方案，在这里清晰地阐述
-->

### 🚑 其他信息

<!--
如截图等其他信息可以贴在这里
-->

创建好了，别人点击你的项目添加Issue时

Issue是由用户/开源软件维护者提供，并且可以绑定对应的Labels,Milestones，Assignees等等。作为开源软件的开发者需要对用户的Issue做出响应，如果用户指定了Bug责任人，作为责任人一定要对此Issue进行跟进。如果Bug无法此版本中解决，可以标记到下一个版本中解决。用户的Issue标签贴错了，可以予以更改。如果用户提的feature觉得合理，可以予以采纳，并再下次团队例会中拿出讨论。

最后，开源软件维护者需要对用户的Issue进行关注。对于需要改动代码的Issue，都要收集起来然后开会讨论，不可以私自拉分支修改。对于已解决的问题记得及时关闭。
下一篇连接：快速在GitHub搭建一个规范的开源项目(三)