Zenn
🐦

GitHubのラベルについて

2024/08/09に公開
GitHub
tech

はじめに

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」の分類は十分に機能するのでしょうか？
おそらく，9個のラベルだけでは分類できないケースは，ままあるような気がします👀
ラベルは独自のものを追加することができます．自由に追加して，あなたが思う便利な開発環境を作りましょう．ここでは，（いろんなネット記事を参考にしつつ）僕が考えたおすすめのラベルについていくつか紹介します．

Priority系のラベル

issue等の優先度を示すラベルです．どのissueから手をつけるべきか分かりやすくなります．例えば次のようなものが考えられます．

ラベル名 意味
high priority 優先度高い
medium priority high priorityより優先度低い
low priority medium priorityより優先度低い

三つもあると，つけるのめんどくさいという人(✋)は，Priorityのラベルを次のように一つだけにしてもいいかもしれません．

ラベル名 意味
high priority 優先度高い

もしくは，

ラベル名 意味
low priority 優先度低い

Refactoringラベル

機能としては正しく動くが，コードの可読性やパフォーマンスの観点から，修正が期待される場合に使われるラベルです．デフォルトで用意されているbug, enhancement, documentationは，リファクタリングタスクに割り当てるにはどれも不適切なため，このラベルを追加することでより適切に分類できそうです．（enhancemnetに分類してもいいのかもしれませんが，僕は少し違和感を感じました🧐）

ラベル名 意味
refactoring コードのリファクタリングが求められる

Securityラベル

セキュリティ面で改善が必要な場合に使われるラベルです．機能の追加とも言えるような，バグの修正とも言えるような微妙な部分だと思うので，enhancementやbugとは別のラベルで管理した方が分かりやすそうです．

ラベル名 意味
security セキュリティの改善が求められる

UIラベル

html，cssなどでUIを作成，改善するには，関数などを作成するのとはまた違った能力やセンスが必要です．UI作成が得意な人がすばやく問題を探せるようにラベルを作ってもいいかもしれません．

ラベル名 意味
ui UIの作成・改善が求められる

ラベルを追加する上での注意点

私たちは，ラベルを追加すればするほど，詳細にissue等を分類することができます．しかし，それらのラベルを十分に活用できなければ意味がありません．そして，多くの人はissue等を作るたびに大量のラベルの中から適切なものを探す作業に負担を感じることでしょう．また，似たような意味合いのラベルが複数ある場合，どちらのラベルをつけるべきか悩んでしまいます．そのようなことは望ましくありません．ラベルは必要最低限の追加をするように心がけるのがよいと思われます．
（と，偉そうに言ってますが，僕は実は実務経験がないので，この記事は全体的に僕の勝手な想像が含まれてます）

Discussion