タスク管理（Redmine,GitHub,GitLab等）において各Issueにラベルを付けることが多い．
ラベルの分類やその使い勝手は，タスク管理やスケジュール管理に大きく影響するため，適切なラベル管理は重要である．
GitLabのオンプレミス構築に関しては，下記記事に参照．
ラベルとは
Redmine, GitHub, GitLabなどのチケットやIssue管理において，Issueを分類わけするためのものである．
ラベルを付けておくと，そのIssueに取り掛かる人はどのような内容なのか把握できる．また，後々見直すときも探しやすい．
ラベルの重要性に関しては，ある程度共通認識があると思うが，実際のところどのようなラベルを使えば良いかというのは，案外難しい．
Issueラベル
優先度系
- Priority: Critical
緊急のもの，直ちに対応すべき - Priority: High
優先度：高 - Priority: Medium
優先度：中 - Priority: Low
優先度：低
優先度は，
Critical > High > ラベルなし > Medium > Low
Type系
- Type: Document
ドキュメントに関するIssue - Type: Bug
バグに関するIssue - Type: Feature
新機能に関するIssue - Type: Discussion
議論に関するIssue - Type: Enhancement
機能強化に関するIssue - Type: Test
テストに関するIssue - Type: Refactoring
リファクタリングに関するIssue - Type: Publishing
公開に伴う作業に関するIssue
Status系
- Status: Ready
準備完了，開始前 - Status: Review Needed
レビュー待ち - Status: In Progress
実装中 - Status: Pending
保留中 - Status: Fix Needed
修正待ち - Status: Approved
承認済み
Close系
- Close: Normal
正常に終了したIssue - Close: Wontfix
対応しないIssue - Close: Invalid
誤ったIssue - Close: Duplicate
他のIssueと重複しているもの（他のIssueで対応する）
工数系
工数系に関するラベルをあまり使われていないことが多い気がする．個人開発の場合は，工数系ラベルを使用しなくても問題ないと思うが，チーム開発をしている場合は採用したほうがいい．
工数見積にはフィボナッチ工数見積もりを採用する．
簡単なものからEffort:1で工数のかかりそうなものは値を大きくする．
なぜ，フィボナッチ数列を使うかというと，見積工数が大きくなれば見積もり誤差も大きくなるため，正確な数値を用いても意味がなく，経験的にフィボナッチ数列は見積単位として良いとされている．
Effort:1に対して工数0.5人日など値を直接与えるのではなく，ストーリーポイントとして扱うことが良いとされている．
- Effort: 1
- Effort: 2
- Effort: 3
- Effort: 5
- Effort: 8
- Effort: 13
- Effort: 21
- Effort: 34
その他
- Good First Issue
初心者向けのIssue - Help Wanted
他者のヘルプを求む
使用例
上述したラベルは，GitLabで実際に使用しているので参考にどうそ．
https://gitlab.com/penguin-lab/projecteuler/-/labels
最後に
内容に誤りや不具合，ご意見があればコメントを残して頂けるとありがたいです
コメント