コードベースに貢献するためにかなり大きなオープンソースプロジェクトに参加するかどうかを決定するとき、貢献するかどうかの決定にとって、プロジェクトの問題追跡機能 (つまり、バグや機能要求の追跡) はどの程度重要ですか?
まだ多くの重要な (巨大なコード ベース) オープン ソース プロジェクトがあり、それらは正式に問題追跡を行っていません - そして一部の貢献者は実際に雑多な「ToDo」リストの形で個人的にこれを行っているかもしれませんが、私は個人的には可用性の欠如と問題追跡の確立された使用が、組織、構造、およびプロジェクト全体の調整の欠如のかなり信頼できる指標であることがわかりました。
他の人は何を考えていますか？
かなり重要な要素と言えます。
オープンな問題追跡システムは、私が「オープンな開発プロセス」と呼んでいるものの 1 つのコンポーネントです。関心のある人なら誰でも、開発者の意思決定が行われているのを見て、議論に貢献できます。
一部のプロジェクトでは、実際にはオープンな問題追跡システム (または優れたシステム) がありませんが、公開されているディスカッション リスト、おそらく常に人が参加している IRC チャネル、フォーラム/掲示板などがあります。私の意見では、そのようなものです。プロジェクトは、それらに貢献するという点で依然としてかなり魅力的です。
私が個人的に気付いたのは、私は非常に多くの異なるオープン ソース プロジェクトに取り組んでいますが、大きなグループの一員になることは決してないということです。ただし、バグを見つけたので報告したいと思います。また、問題が以前に発見されたかどうか、いつ修正されるかを知りたいと思います。
個人的には、メーリング リストにサインアップしたり、バグ トラッカーに登録したりするよりも、オープン バグ トラッカーまたはメーリング リストを使用して、1 回限りの電子メールを送信してバグを人々に通知できる方が優れています。私はすでにあちこちに十分な数のアカウントを持っています。ソフトウェアのために別のアカウントは必要ありません。
したがって、バグの報告に伴う摩擦は間違いなく問題です。また、バグのステータスを表示して検索できるようにすることは、自分の問題をプロジェクトに報告するかどうかを決定する上で大きな助けになります。
そうです、問題の追跡をオープンにし、使いやすく、見やすく (1 ページを 20 分間掘り下げるのは楽しいとは思いません)、何よりも、必要な機能やバグのレポートを取得するための摩擦が少ないことです。
私が関わっている多くのプロジェクトは、今でもメーリング リストですべてを行っています。バグが発生した場合 (そして確認され、修正できる場合) は、リポジトリ内のある種の BUGS ファイルに入れられます。問題が修正されると、ファイル内のエントリが記録されます。
私の好みではありませんが、他の貢献者が慣れ親しんでいるものです。誰かが、バグ システムをホストしたり、バグ システムに引き寄せられる可能性のある SPAM に対処したりする面倒を望んでいないのかもしれません。プロジェクトにバグや機能のリクエストがあまり寄せられていないのではないでしょうか?
「すべきか」という本当の問題は、実際にはコードを中心に展開しているのではないでしょうか? または、特定のグループと一緒に働くことで、どれだけのことを学び、教えることができますか? 貢献を始めて、友好的で有用であることを示せば、trac や bugzilla のようなものを提案するときに抵抗がないかもしれません。
特定のプロジェクトを避けることを考えさせる唯一のことは、あらゆる種類のバージョン管理が完全に欠如していることです。しかし、それでも、ぎりぎりのマージでパッチを管理する手間と、あきらめなければならないことを比較検討する必要があります。