issue作成の落とし穴: OSS開発での教訓
はじめに
私は現在、「Yamada UI」というOSSプロジェクトのコアメンバーとして活動しています。
このプロジェクトはUIコンポーネントライブラリで、日々新しい機能の追加や改善に励んでいます。
今回はそんな私がissue作成時に犯したミスについて話したいと思います。
背景
私たちは、活動の一環としてテストカバレッジを80%まで上げることを目標に掲げていました。
ただ、プロジェクト内には数十ものコンポーネントがあり、これら全てに対してコアメンバーだけで対応するのは大変と判断し、コントリビューターの方をつのろう！となり、issueを作成しました。
当時作成したissueは以下のような感じです。同様のissueが20個ほどありました。
ミスの内容
しかし、このissue作成についてミスをしまいました。そのミスとは、「内容が抽象的すぎた」というものです。
私が作成したissueは、目標や背景はしっかりと記述していたものの、具体的にどのようなアクションをコントリビューターに期待しているのかが不明瞭でした。
いくらか関心を持ってくれた人も、「何をどうすればいいのか」が伝わらないため、実際に手を動かしてもらうことが難しくなってしまいました。
アドバイス
プロジェクトの開発者である山田さんからは、
issue作成時には「具体的なタスクの分割」と「明確なアクションプラン」を提供した方がいいとアドバイスをいただきました。
確かにコントリビューターが具体的なタスクに取り組みやすくするためには、どのコンポーネントに対するものなのかを明確にし、期待される成果物についても詳しく説明するべきでした。
最後に
そんな現在、改善を経てテストカバレッジ向上のためのissueが多数たてられてます。
issueの内容がより具体的になっていて参加しやすくなっていると思います！
興味のある方は、ぜひ参加をご検討ください！
プロジェクトに関する質問や相談がある場合は、以下のDiscordリンクからご参加いただけます！
参考情報
Discussion