🎩

小規模チーム開発におけるissue templateアンチパターン

# Summary

• 厳格な運用は、小規模なチーム開発ではメリットを感じにくく、issue template だけでなく issue 自体の運用が上手くまわらなくなることも考えられる。
• 最小限かつ単一の issue template を用いることで、利用する上での負荷を抑え、チーム開発における issue の健全な運用を促す。

# アンチパターン：項目の多い issue template

小規模のチームでは、issue を立てる人と対応する人が同じであることも多いため、何らかの強制力がなければチームメンバーは記入をサボるようになるでしょう。

そして記入をサボる癖を放置すると、結果として何も記入しないという事態を招きかねません。

# issue に情報を残すことは大切

自分とチームメンバーそして将来のチームメンバーのために、issue や PR などには出来る限りの情報を残すべきです。

メリットとして以下のようなものがあります。

• 情報共有に使える
• 同様の問題が発生した場合の手引きになる
• 思い出す助けになる

# アンチパターン：ジャンルに応じた issue template

Github で複数の issue template を配置すると選択画面が挟まるようになってしまいます。一般に、選択というのは億劫なものです。結果としてチームメンバーは issue template を使わずに issue を立てるようになってしまうでしょう。

# どうすればいいの？

• 項目は最低限にする
  • 例えばタイトルに What を記入するとして、body は Why や Context のみなど
• issue template は1つのみ配置する

## Why

## Context (Optional)

# OSS などの issue template

issue を立てる人と開発する人が基本的に一致しないようなプロジェクトでは、issue template の項目はある程度多い方がいいですし、ジャンルに応じた issue template があると便利です。

# 項目の多い issue template

普段開発に関わっていない人が、そのプロジェクトの詳しい仕組みを理解し、問題は正確に理解するための情報をまとめて issue に記載することは困難です。また足りない情報を埋めるために、追加で質問をしていくのは双方にとって不幸でしょう。 そこで必要な情報を前もって埋めてもらえるように issue template を用意しておきましょう。

# ジャンルに応じた issue template

プロジェクトによっては、issue を label で管理したかったり、monorepo なため問題のある箇所によって必要な情報が異なります。全てのケースを対応するために issue template の項目を増やすのは大変なので、状況に合わせた issue template を複数配置しておきましょう。