【GitHub】ラベルについて【備忘録📝】
はじめに
GitHubでは「issue」「pull requrest」「discussion」をラベルで分類することができます．例えば，次のようにissueに「bug」というラベルをつけることができます．
ラベルはデフォルトで9種類が用意されています．また，ラベルは独自のものを追加することができます．この記事の内容は以下の二つです．
デフォルトの9個のラベル
まず，9個のラベルの名前と意味の表をGitHubドキュメントより示します．
| ラベル名 | 意味 |
|---|---|
bug |
予期しない問題または意図しない動作を示します |
documentation |
ドキュメンテーションに改善や追加が必要であることを示します |
duplicate |
似た issue、pull request、ディスカッションを示します |
enhancement |
新しい機能のリクエストを示します |
good first issue |
初回のコントリビューターに適した Issue を示します |
help wanted |
メンテナーが Issue もしくはプルリクエストに助けを求めていることを示します |
invalid |
issue、pull request、ディスカッションが関係なくなっていることを示します |
question |
issue、pull request、ディスカッションにさらに情報が必要であることを示します |
wontfix |
issue、pull request、ディスカッションに対する作業が続けられないことを示します |
bug
予期しない問題または意図しない動作を示します
これは分かりやすいですね．
何か不具合が見つかって修正したい場合はとりあえずこのタグをつけてissueを作ればよさそうです．
documentation
ドキュメンテーションに改善や追加が必要であることを示します
これも分かりやすいですね．
コード内のコメントやREADMEなどの修正をしたい時に使いそうです．
duplicate
似た issue、pull request、ディスカッションを示します
このラベルは少しユースケースがわかりにくいかもしれません．
というのも，duplicateラベルがついたissue等が，どのissue等と重複しているのかラベルだけだとわからないからです．ところで，issue等のduplicateを示す方法がもう一つあります．
次のように，issue等に「Duplicate of #[識別番号]」とコメントすることで重複をマークします．また，Undoというボタンを押すと重複のマークが解除されます．
メンションされた#39のissueではタイムラインに次のような通知が現れます．
この方法ならどの要素同士が重複しているのか分かりやすいです．
duplicateラベルをつけるよりこの操作をした方がいいかもしれません．
enhancement
新しい機能のリクエストを示します
これは分かりやすいですね．
機能追加をしたい時にはこのラベルを使うとよさそうです．
機能追加をする時は，branch名などに「機能」という意味のfeatureを使うイメージがありますが，ここでは「改善」「強化」という意味のenhancementを使うみたいです．「機能をどうするのか」という部分にフォーカスしている分enhancementの方が分かりやすいような気もします 🤔
good first issue
初回のコントリビューターに適した Issue を示します
これはOSSコントリビュート関連のラベルですね．
初めてOSSコントリビュートする人向けの簡単なissueにつけるラベルです．
あまりこのラベルを使用する意味がないと思う人がいるかもしれません．なぜなら，単にアプリ開発という観点から見るならissueを解決してくれる人はプログラミングに精通していればしてるほどいいと思うのが普通だからです．
このラベルは，プログラマーの先輩が後輩へ試練を課すようなモチベーションで使うのかもしれません 🤔
GitHubの検索バーでlabel:"good first issue"と検索するとgood first issueのラベルがついたissueを検索することができます．
github.com/[ユーザー名]/[リポジトリ名]/contributeにアクセスすると，そのリポジトリのgood first issueのラベルがついたissueのリストが表示されます．また，右上にCONTRIBUTING.mdへのリンクも表示されます．github.com/github/docs/contributeの例を次に示します．
CONTRIBUTING.mdにはリポジトリへコントリビュートする上でのルールなどを記載するそうです（pull requestのフォーマットなど）．
help wanted
メンテナーが Issue もしくはプルリクエストに助けを求めていることを示します
このラベルは分かりやすいですが，誤解が生まれるかもしれません．
字面だけ見ると，困難な課題に直面しており，自己解決できないため助けを求めていると思うかもしれません．しかし，実際のユースケースは少々異なるようです．
Kubernetesのコントリビュータ向けのドキュメントではhelp wantedはgood first issueと同様にOSSコントリビュート初心者向けのラベルに使われています．help wantedにする条件は，「低い参入障壁」「明確なタスク」「ちょうどいい優先度」だとあります．
これを見ると，good first issueほどではないが，簡易なissueにhelp wantedのラベルをつけるのではないかと思われます 🤔
invalid
issue、pull request、ディスカッションが関係なくなっていることを示します
これは分かりやすいですね．
issue等が作成者の誤解などで問題が存在しなかった時などに使われます．
また，issueや pull request がプロジェクトで定められたフォーマットに従っていない場合などに投稿が無効であるとしてこのラベルが使用されるかもしれません 🤔
question
issue、pull request、ディスカッションにさらに情報が必要であることを示します
これも分かりやすいですね．
issueを解決するのに必要な説明が足りておらず，さらなる情報をissue投稿者に求める時などに使われるのだと思われます 🤔
wontfix
issue、pull request、ディスカッションに対する作業が続けられないことを示します
これも分かりやすいですね．
問題は明らかであり，修正を期待するが，手が回らなかったり，解決方法がわからない時に使われるのだと思います．
つまり, コミュニティからのコントリビュートを期待しているので，OSSコントリビュートに興味がありgood first issue, help wantedラベルのissueでは物足りなく感じる人はこのラベルのissueを探すと良さそうです 🤔
デフォルトの9個のラベルのユースケースのまとめ
多くのケースで，bug, enhancement, wontfix, documentationはよく使われると思われます．
duplicate, invalid, questionはチームメンバーがいる時に特に効力が発揮されるラベルだと思うので，個人開発では使われないかもしれません．
good first issue, help wantedは，OSSコントリビュータに貢献することを目的とする人に使用されます．それ以外の人にはまったく使われないでしょう．
デフォルトにはないおすすめのラベル
デフォルトの9個のラベルによる「issue」「pull request」「discussion」の分類は，実際の開発現場で十分に機能するのでしょうか？
ラベルは独自のものを追加することができます．自由に追加して，あなたが思う便利な開発環境を作ればよいと思いますが，よく使われそうなおすすめのラベルについていくつか紹介します．
Priority系のラベル
issue等の優先度を示すラベルです．どのissueから手をつけるべきか分かりやすくなります．例えば次のようなものが考えられます．
| ラベル名 | 意味 |
|---|---|
high priority |
優先度高い |
medium priority |
high priorityより優先度低い |
low priority |
medium priorityより優先度低い |
三つもあると，つけるのめんどくさいという人(✋)は，Priorityのラベルを次のように一つだけにしてもいいかもしれません．
| ラベル名 | 意味 |
|---|---|
high priority |
優先度高い |
もしくは，
| ラベル名 | 意味 |
|---|---|
low priority |
優先度低い |
Refactoringラベル
機能としては正しく動くが，コードの可読性やパフォーマンスの観点から，修正が期待される場合に使われるラベルです．デフォルトで用意されているbug, enhancement, documentationは，リファクタリングタスクに割り当てるにはどれも不適切なため，このラベルを追加することでより適切に分類できそうです．
| ラベル名 | 意味 |
|---|---|
refactoring |
コードのリファクタリングが求められる |
Securityラベル
セキュリティ面で改善が必要な場合に使われるラベルです．機能の追加とも言えるような，バグの修正とも言えるような微妙な部分だと思うので，enhancementやbugとは別のラベルで管理した方が分かりやすそうです．
| ラベル名 | 意味 |
|---|---|
security |
セキュリティの改善が求められる |
UIラベル
html，cssなどでUIを作成，改善するには，関数などを作成するのとはまた違った能力やセンスが必要です．UI作成が得意な人がすばやく問題を探せるようにラベルを作ってもいいかもしれません．
| ラベル名 | 意味 |
|---|---|
ui |
UIの作成・改善が求められる |
ラベルを追加する上での注意点
私たちは，ラベルを追加すればするほど，詳細にissue等を分類することができます．しかし，それらのラベルを十分に活用できなければ意味がありません．そして，多くの人はissue等を作るたびに大量のラベルの中から適切なものを探す作業に負担を感じることでしょう．また，似たような意味合いのラベルが複数ある場合，どちらのラベルをつけるべきか悩んでしまいます．そのようなことは望ましくありません．ラベルは必要最低限の追加をするように心がけるのがよいでしょう．
Discussion