Github 新的項目管理模式——Projects
Issues
Github 中傳統的項目管理是使用 issue 和 pull request 進行的，這部分內容不是本文重點，不再贅述。 但有一些功能需要提及：
- Tag： 每個 issue 可以添加不同的 tag，可以用於標記 issue 的種類和 issue 的處理進度；
- MileStone：每個 issue 只屬於一個 milestone，用於顯示 issue 的處理進度。
Projects 概述
這是Github 2016年9月份新的功能，如圖所示：
Project 提供了真正的管理 issue 的能力；而傳統的 tag 方式只能以手工的方式管理分類（如 Q&A，bug，duplicate，feature 這些標簽🏷），或者以手工的方式管理 issue 進度（need test, in progress, wait approval 等這些標簽）。
不過在開始討論這個之前，有必要先討論一下看板方法。
看板（Kanban）
什么是看板？
看板管理，起源於豐田的生產模式中，指為了達到及時生產（JIT）方式控制現場生產流程的工具。及時生產方式中的拉式（Pull）生產系統可以使信息的流程縮短，並配合定量、固定裝貨容器等方式，而使生產過程中的物料流動順暢。
需要詳細了解的請看Wiki。
如果還是沒看懂，這里有幾個看板的例子：
KanbanFlow & Trello
可以看出，所謂看板，就是把一塊木板上分成幾列，然后在每一列上貼上不同內容的卡片。 木板上的這幾列一般是有順序的，卡片可以在不同的列之間移動來表明所處的狀態。
以上的兩個例子，看板並不是針對軟件工程的，他們的市場也是一般的企業（比如豐田這樣的）。
Zenhub & Github Projects
下面的兩個例子則是針對軟件開發做了優化，准確的說，它們都是對 Github 做了適配。
Zenhub 是個瀏覽器插件，就是把 Github 的 issues 當作卡片，以 Kanban 的形式展現 issue，也提供了一個比較雞肋的 Epic 的功能，同時針對個人也有 TODO 項管理。
而 Github 最近推出的 Project 不僅可以使用 issues 作為卡片，還可以使用Note（左側的三個），這樣我們就沒有必要為了在看板上記錄可能的需求而創建一個新的 issues 或者把問題記錄在個人的 TODO 列表上了。
Github Projects
一個倉庫可以包含多個項目；最初，這個設定讓我疑惑，直到使用之后才明白， 一個代碼倉庫通常有很多事情要做，比如：
- 擬定線路圖
- 增加一個新功能
- 發布一個新版本
因此，我們可以為以上每一件事創建一個 Project，由於 Github 中並沒有類似 Epic 的機制，因此使用不同的 Project 則很有用了。
可以看到，有了 Project 的 Kanban 之后，原來 tag 的部分功能（如標記處理進度等）可以被看板替代。 Github Project 提供的 Note 可以在需要的時候單項轉換為 issue：
同時，Kanban 不僅可以包含 issue 和 note，還可以包含 pull request。
Github 終於有了比較靠譜的項目管理工具，開源項目的又有了更好的工具。 撒花o(^▽^)o
祝願我自己早日完成我的第一個開源項目（IMAP Server）。
本文首發於我的個人博客 (https://hudingyuan.cn/a/11)