前言
本指導內容主要基於：
僅為一家之言，如有偏頗或不全者，歡迎討論或補充，感激不盡。
關於Milestone
- Milestone顧名思義，翻譯成中國話叫做“里程碑”
- 基於上述含義我們一定程度上可以將Milestone理解為一個階段
- 對於Milestone的建立
- 請務必按照相對獨立的局部任務目標進行划分，而不是簡單的以時間節點等非項目因素來划分
- 要設置合理的周期
- 一般周期是1-4周為限度為好
- 對於明顯過短的階段，該考慮是否與其他階段合並；對於明顯過長的階段，該考慮是否進行階段的進一步細分；不過仍然務必需要滿足上述基於目標進行划分的基本要求
- 如果實在難以兩全，則在基本合理的前提下，不必強求任務周期長度（簡而言之：里程碑的目標性優先於時間周期性）
【太長不看版】具體且簡單來說
- Milestone需要按照相對獨立的局部任務目標進行划分，不要簡單地基於時間來設置Milestone
- 對於軟工課程
- Alpha階段可以划分為一個Milestone
- 因為其是一個完整獨立的階段，且時間周期和比較合理
- 在一些常見的開源項目中，也明顯體現着階段這一特性
- 比如這個在Gitlab官方站上的開源項目：https://gitlab.com/arl2/palaestrai/-/milestones，靠上端的幾個Milestone雖然略長於四周，但是很明確的體現着階段的意義與目標
關於Issue
- Issue顧名思義，翻譯成中國話叫做“問題”
- 對於Issue的建立
- 請務必按照相對獨立的局部任務目標進行划分，而不是簡單的以時間節點等非項目因素來划分；且需要以簽入代碼完成某實際模塊為目標導向，標准為在Gitlab系統平台上有Commit/Merge Request等形式的體現
- 要設置合理的周期
- 一般在實際環境下，周期以小時為單位為佳。例如，在現實企業開發中一天的8小時工作，可以設置幾個Issue來跟蹤進度，每個Issue大約2-3小時。
- 其他周期相關與Milestone類似，也是同樣的目標性優先於時間周期性
- 粒度划分要盡可能做到易於跟蹤了解情況，但又不應細到嚴重影響工作手感或失去具體意義
- 要根據分工，設置合理的Assign to，即將Issue具體分配到人；此外對於Issue其他相關的人員，也可以在Issue內容中進行@，以確保通知到相關人員。
- 要根據任務所屬階段，關聯至對應的Milestone，以確保當前Issue進度可以納入Milestone進行計算
- 要根據任務性質和當前狀態，打上合理的標簽，以方便可以在看板上快速了解當前整個項目的進展狀況
- 對於Issue的后續操作
- 在Issue下可以就問題本身展開進一步的討論，並注意合理使用Comment和Discussion
- Commit指評論，意為針對此問題本身的評論，不支持進一步回復等功能
- Discussion指討論，意為針對此問題的討論，支持進一步回復等功能，並且對於discussion而言
- 需要在討論完畢后，在討論宣告終結的那個回復上點擊右上角Resolved，表示問題已經被解決
- discussion的解決程度也是衡量issue進度的重要指標，可以直觀地理解為——“問題下的Discussion未被全部解決意味着對此問題尚有需要進一步商議的問題，並需要盡快討論敲定”
- 因此，建議但凡是因為存在疑問或不明確之處，而需要展開討論和商議的內容，都請使用Discussion
- 注意與倉庫內其他內容的關聯
- 例如Commit、Merge Request等，這些關鍵信息需要與Issue進行充分的綁定，即在Issue中可以觀測到在系統層面上所建立的關聯
- 具體來說可以參考官方文檔：https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically，里面對於Commit和Merge Request如何自動操作Issue有較為詳細的介紹，請各小組務必認真讀一讀，了解一下Gitlab Issue的正確打開姿勢
- 當任務的狀態或者性質發生變化時
- 請及時更新Issue的標簽
- 對於已經解決或者完成的Issue
- 首先確保相關聯的Commit、Merge Request等是否都已經穩定（具體來說，需要確保是期望的版本，並且如果設置了CI的話需要CI也一並通過）
- 其次確保當前Issue下的discussion是否已經被全部解決，Issue問題底部右側區域是否顯示綠色塊（如果discussion數量不少於1的話）
- 在滿足上述基本要求並且確保Issue已被解決或完成的情況下，請務必記得關閉此Issue，以在系統層面上表示該Issue的終結
- 在Issue下可以就問題本身展開進一步的討論，並注意合理使用Comment和Discussion
【太長不看版】具體且簡單來說
- 一個Issue可以視為一個問題或者任務，粒度要小一些以便精准反應各部分進展狀況
- Issue應該保持其問題或者任務的性質，不要基於時間來設置Issue
- Issue需要以簽入代碼完成某實際模塊為目標導向，諸如“學習XXX技術”、“對接XXX需求”等沒有代碼體現的內容不應作為Issue
- Issue的維護是一個完整連貫的過程，請善用Gitlab平台本身的一系列機制以達成更好的效果
- Issue講究實事求是，情況有變則寫清楚原因后增刪即可
- 考慮到可能對長遠一些的內容做不到精確規划，建議先以Issue的形式做粗略規划，后續根據實際情況再做擴充