GitHub Issuesのラベリング

GitHub Issuesでどういうラベルを付けると上手くいきやすいかという話について。あまりそういう話をしている人が居なかったので、とりあえず自分のコントロール可能なプロジェクトではどうやっているかについて書こうと思い立ちました。(ちなみにIssueと言っていますがPull Requestのことも含んでいます)

パターン

個人的な体験から言うと、この分け方は上手くいったなというラベルは、以下のようなパターンにあてはまっていることが多いように感じています。

• Issueの分割に寄与する
• 担当者の選択や優先順位付けに寄与する
• Close後も利用価値がある
• 細かすぎない・粗すぎない

逆に、以下のようなパターンのラベルはあまり上手くいきませんでした。

• 一時的な状態を表している
• 他のラベルと重複している（例: ラベル間に包含関係がある）

具体例

これはRailsアップグレード作業で利用したラベルの例で、わりと上手くいった例です。これを例にして、前述したパターンについて説明していきたいと思います。マイナーバージョンごとにラベルを分けているほか、Refactoringというラベルも用意しています。 「Issueの分割に寄与する」というのは、例えばRailsのラベルとRefactoringのラベルが同時に付いていたら要注意で、これはそのIssueやPull Requestは分割すべきという危険信号だと思います。ラベルを付けるタイミングやレビューを行うタイミングで一度考えさせられる、というのは良いところだと思います。

「担当者の選択や優先順位付けに寄与する」というのは、例えばRails 5.2よりRails 5.1の方が先に対応しないといけないとか、そういう話です。

「Close後も利用価値がある」というのは、将来振り返るときに使えるかという話です。ラベルを管理するのにもそこそこコストが掛かるので、将来的に得られる見返りは大きくしないとという話です。今回の例だと、Railsのバージョンアップに各マイナーバージョンごとにどのくらいの工数が掛かったかというのがざっくり分かるというのにも役に立ちました（そのラベル全体での変更行数や作業期間を概算して振り返ったりしていました）。また、不具合発覚時にPull Requestを参照するときにも役に立ちました。

「細かすぎない・粗すぎない」というのは、例えば Rails 5.1.5、Rails 5.1.6 のように細かく分けすぎていると難しすぎただろうし、一方で Rails 5、Rails 6 というように粗すぎるとそれはそれで大変だっただろうという話です。実際のところ、最初は Rails 4, 5, 6 というようにラベルを付けていたリポジトリもあったんですが、他のリポジトリでマイナーバージョンごとに分けてみたところ上手く働いたので、後から全てのラベルを付け直したりしました。粒度については、リリースサイクルの粒度を判断材料として重視すると良いのかなとなんとなく考えていますが、これについてはまだ明確にはパターン化できていません。

注意点として、例えば「5.0で警告が出るようになり、5.1で例外が発生するようになる」というような問題に対しては、Rails 5.1 というラベルを付けています。この辺りの微妙なルールは一貫しておかないと失敗すると思います。

おわり

他の人がどうラベルを付けているかについてもっと知りたいので、こう管理しているよという話があれば教えてください。