上一篇博客快速在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搭建一個規範的開源項目(三)