# GitLab Issues <small>微程式 / 研一 / 戴均民</small> --- 當你建立一個專案以後， 就有 Issues 可以用了。 <style> /* .reveal [data-markdown] code { padding: 0.2em 0.4em; margin: 0; font-size: 75%; background-color: #555; border-radius: 3px; font-family: "SFMono-Regular",Consolas,"Liberation Mono",Menlo,Courier,monospace; }*/ </style> --- ## 別人都怎麼用 ## GitLab Issues？ Note: 允許你、你的團隊、你的協同合作者在開始實作之前和實作時，共享及討論建議。 --- ## Use cases <small>Issues 的使用有無限可能，以下舉出幾個常見的使用情境。</small> * 討論新點子的演進<!-- .element: class="fragment" data-fragment-index="1" --> * 提交一個新功能的建議<!-- .element: class="fragment" data-fragment-index="1" --> * 提問問題<!-- .element: class="fragment" data-fragment-index="1" --> * 回報 Bugs 和故障<!-- .element: class="fragment" data-fragment-index="1" --> * 取得支援 (Obtaining support)<!-- .element: class="fragment" data-fragment-index="1" --> * 簡單描述新的程式流程<!-- .element: class="fragment" data-fragment-index="1" --> --- ### 先來看一個 blog 文章 > Always start with an issue > > [name=Job, GitLab 產品副總裁] [原文文章](https://about.gitlab.com/2016/03/03/start-with-an-issue/) Note: 在你開始任何事情之前, 開一個 issue 總結一下你的想法並分享它。這是一個簡單的規則, 但影響是巨大的。 本文是專注於功能建議的 issue，但這個規則適用於任何的情境。 通常，我們應該要開始（start）一個 issue，而不是建立（create）一個 issue。因為通常 issue 可能已經存在過了。 --- ## Start an issue #### 確保搜尋過所有開啟或關閉的 issue ### 確認之前是否存在過類似的 Note: 我們會說「開始」一個問題，而不是「創造」一個問題，因為問題可能已經存在。確保先在所有問題（打開和關閉）中進行搜索，以查看您的想法是否已被提出。 --- ## 軟體 = 討論 * 軟體開發很難獨自完成<!-- .element: class="fragment" data-fragment-index="1" --> * 協同合作的好處從提出一個 issue 開始<!-- .element: class="fragment" data-fragment-index="2" --> * 讓你的合作者在早期就有發言權<!-- .element: class="fragment" data-fragment-index="3" --> * 把 issue 的演化過程記錄下來<!-- .element: class="fragment" data-fragment-index="4" --> Note: 合作的好處從提出問題開始。通過提出一個問題，你可以在那裡得到你的想法，這讓你的合作者在這個過程的早期就有發言權。 不會寫程式的人可能認為程式設計師就只是不停的在鍵盤上打字來寫出程式。事實上，軟體開發更像是一個討論，它是需要共同合作，而不是獨自開發。 GitLab 提供的工具使您可以更輕鬆地管理討論，並保持會話移動的過程。 --- ## 舉一個實際的例子 ### GitLab 8.5 的 Todos 功能<!-- .element: class="fragment" data-fragment-index="1" --> --- * issue 開始於開始寫程式的五個多月前 * 原本預計 8.4 釋出，延到 8.5 * 第四個月時需求的描述被簡化 * 設計師畫出了二份設計來反映出當前的討論 * title 改過七次，最後定案為 Todos * 30+ 個參與者關注 * 13 個人參加討論 --- 在 issue 的早期時，Job 就決定了怎麼該進行 * 正式的提案 (Job / Darby / other people)<!-- .element: class="fragment" data-fragment-index="1" --> * mockups (Job)<!-- .element: class="fragment" data-fragment-index="2" --> * 設計 (Andriy)<!-- .element: class="fragment" data-fragment-index="3" --> * 實作 (any dev)<!-- .element: class="fragment" data-fragment-index="4" --> <small style="color: gray">(最後是 Douglas 實作的)</small><!-- .element: class="fragment" data-fragment-index="4" --> --- ## 這個 issue 存活了 174 天 --- ### 在釋出的 20 天前 ### 才被指派給 Douglas 實作 --- * 實作時間只佔了 issue 11% 的生命週期 * 在釋出的 7 天前才建立合併請求<!-- .element: class="fragment" data-fragment-index="1" --> <small style="color:gray">（GitLab Flow 要求在寫程式之前就要先建立合併請求）</small><!-- .element: class="fragment" data-fragment-index="1" --> <span>代表 Douglas 花在寫程式的時間上 只佔了 4% 的生命週期</span><!-- .element: class="fragment" data-fragment-index="2" --> --- ## 那他前面幾天時間在做啥？ --- * 他先去看懂以前的程式碼 * 然後寫出他將如何去實作這個功能<!-- .element: class="fragment" data-fragment-index="1" --> --- ## 在合併請求開始以後 ## 也發生了很多的討論 --- ### 例：Douglas 和 Douwe 討論 ### 如何處理極端的使用情境 --- * 他們根據原來的「Why」來決定 如何解決極端的使用情境 * 每天 Douglas 都會做出一些修改<!-- .element: class="fragment" data-fragment-index="1" --> * 然後 Douwe 就會給予一些回饋<!-- .element: class="fragment" data-fragment-index="2" --> --- ## 所以軟體和討論 # 息息相關 --- ## 如果你沒有先開 issue # 會發生什麼事？ --- ## 你會很難去了解這個需求 ## （溝通成本增加） --- 當你沒有徹底瞭解這個需求， 就開始花時間在實作， # 非常危險 --- 因為當你花費了很多時間成本以後， 如果發現自己做錯了，你就會不知道 ## 該放棄還是該繼續 --- 當你拿出你的成品時，別人問你 為什麼你不要做 X， 或是為什麼要做 Y， ### 你可能會需要花更多時間來解釋 --- ## 當你開始使用 issue 之後 ## 你還可以成功避免一些問題 --- * 你可能會不知道你需要考量到的事情 * 系統中可能有你不熟悉的部分 * 可能有你不知道的限制或可能性 * 你可能不知道某些會影響結果的使用者因素 * 可能有一些正在進行的工作與你的想法有關 --- ## issue 開通了溝通的道路 ### 然後你就可以獲益於協同合作 --- ## 什麼時候你不會 ## 開始一個 issue？ --- ## 單純用合併請求 ### 就足以解釋一切的時候 --- * 小小的錯誤修正（錯字） * 小到不需要討論的東西 --- #### 因為 issue 的多數功能 ## 合併請求都有 --- # 小技巧 在合併請求的標題前面 打上 `WIP:` 避免太早被合併 (work in progress) --- ## 接下來 ## 我們來看實際操作 --- * 新增專案 * 新增 issu * 關閉 issue * 刪除 issue * 從 issue 直接開合併請求 * 搜尋 issue --- # End