當你建立一個專案以後，
就有 Issues 可以用了。

別人都怎麼用

GitLab Issues？

Use cases

Issues 的使用有無限可能，以下舉出幾個常見的使用情境。

討論新點子的演進
提交一個新功能的建議
提問問題
回報 Bugs 和故障
取得支援 (Obtaining support)
簡單描述新的程式流程

先來看一個 blog 文章

Always start with an issue

Job, GitLab 產品副總裁

原文文章

Start an issue

確保搜尋過所有開啟或關閉的 issue

確認之前是否存在過類似的

軟體 = 討論

軟體開發很難獨自完成
協同合作的好處從提出一個 issue 開始
讓你的合作者在早期就有發言權
把 issue 的演化過程記錄下來

舉一個實際的例子

GitLab 8.5 的 Todos 功能

issue 開始於開始寫程式的五個多月前
原本預計 8.4 釋出，延到 8.5
第四個月時需求的描述被簡化
設計師畫出了二份設計來反映出當前的討論
title 改過七次，最後定案為 Todos
30+ 個參與者關注
13 個人參加討論

在 issue 的早期時，Job 就決定了怎麼該進行

正式的提案 (Job / Darby / other people)
mockups (Job)
設計 (Andriy)
實作 (any dev)
(最後是 Douglas 實作的)

這個 issue 存活了 174 天

在釋出的 20 天前

才被指派給 Douglas 實作

實作時間只佔了 issue 11% 的生命週期
在釋出的 7 天前才建立合併請求
（GitLab Flow 要求在寫程式之前就要先建立合併請求）
代表 Douglas 花在寫程式的時間上
只佔了 4% 的生命週期

那他前面幾天時間在做啥？

他先去看懂以前的程式碼
然後寫出他將如何去實作這個功能

在合併請求開始以後

也發生了很多的討論

例：Douglas 和 Douwe 討論

如何處理極端的使用情境

他們根據原來的「Why」來決定
如何解決極端的使用情境
每天 Douglas 都會做出一些修改
然後 Douwe 就會給予一些回饋

所以軟體和討論

息息相關

如果你沒有先開 issue

會發生什麼事？

你會很難去了解這個需求

（溝通成本增加）

當你沒有徹底瞭解這個需求，
就開始花時間在實作，

非常危險

因為當你花費了很多時間成本以後，
如果發現自己做錯了，你就會不知道

該放棄還是該繼續

當你拿出你的成品時，別人問你
為什麼你不要做 X，
或是為什麼要做 Y，

你可能會需要花更多時間來解釋

當你開始使用 issue 之後

你還可以成功避免一些問題

你可能會不知道你需要考量到的事情
系統中可能有你不熟悉的部分
可能有你不知道的限制或可能性
你可能不知道某些會影響結果的使用者因素
可能有一些正在進行的工作與你的想法有關

issue 開通了溝通的道路

然後你就可以獲益於協同合作

什麼時候你不會

開始一個 issue？

單純用合併請求

就足以解釋一切的時候

小小的錯誤修正（錯字）
小到不需要討論的東西

因為 issue 的多數功能

合併請求都有

小技巧

在合併請求的標題前面
打上 WIP: 避免太早被合併
(work in progress)

接下來

我們來看實際操作

新增專案
新增 issu
關閉 issue
刪除 issue
從 issue 直接開合併請求
搜尋 issue