バグ修正パッチは誰の責任ですか？

オープンソースプロジェクトで何度か発生した状況は次のようになります。

1. デプロイメントにバグがあり、簡単なハックパッチを見つけました。（たとえば、実際に必要のないコードをコメントアウトするだけです。）
2. 実際のバグを把握し、パッチを作成し、Gitプルリクエストなどを介してそれを送信するために、少しの余分な努力を費やしています。
3. プルリクエストは拒否されます。おそらくパッチは不完全で（たとえば、あるべきではない行が含まれていた）、コーディングスタイルに違反していたか、おそらく他の影響がありました。または、Gitで何か間違ったことをした可能性があります-プルリクエストはリベースされるか、何かでした。メンテナーは、パッチを改善する方法についてのフィードバックを提供し、再送信を要求します。

この時点で、私はどこまで進むべきかについて混乱しています。心配する限り、問題はありません。手順1で修正しました。問題を報告しました。他の人のために修正するための措置を講じました。しかし、それが「私の」プルリクエストだとは思わないので、パッチを改善する責任は私にあるとは思わない。

私を悩ませる特定の状況の1つは、パッチの失敗について議論した後、正しいパッチが何であるか（つまり、コードのすべての行を含む）のメーリングリストで合意に達することです。その後、実際にパッチを生成して送信するのは私の責任であると考えられています。

これらの状況に標準的なエチケットはありますか？それらはどのように解決されますか？私の反応は異常ですか？バグ修正をどこまで受け入れられるのでしょうか？

（「オープンソースプロジェクト」と言うとき、これらのいくつかは非常に小さいですが、趣味ではないかもしれません-開発者のリソースをそれらに取り組むことをコミットするいくつかの組織に役立つ単純なソフトウェアプロジェクトです。 「パッチを修正して再送信する」ということは、雇用主にとって有益なものに取り組む責任があることを理解してください。私たちに影響しないバグの修正に時間を費やすことは間違っているでしょう...）

私に関する限り、バグを発見したり、機能強化のリクエストがあったり、プロジェクトへの貢献者ではなく、適切なチャネルを通じて欠陥レポートを提出した場合は、完了です。コミュニティへの還元という点では、オープンソースプロジェクトを使用していて欠陥を見つけた人は誰でも報告すべきです。

ソリューションを見つけて設計し、実装しようとすることは、プロジェクトのボーナスです。これを行った場合は、プルリクエストを介して送信するか、ファイルデルタを欠陥レポートまたは機能強化リクエストとともに開発チームに送信して、何か作業を提供することをお勧めします。ただし、プロジェクトへの貢献を受け入れる義務はありません。

ユーザーにパッチの提供を期待するのは間違っているように思えます。問題についての議論に参加するのはかなり簡単ですが、解決策を思い付くにははるかに大きな時間の投資です。単一の問題を修正するためだけに、非貢献者が貢献者になることをプロジェクトが期待してはなりません。

あなたがそれを我慢するまで進んでください。パッチを修正し、メイントランクで世界中の人と共有するのは良いことですが、メンテナーがそれを望まない場合は、肩をすくめてください。同じボートにいる他の人が解決策を探すことができるように、問題のどこかとそれを処理するパッチを投稿できます。

そして、あなたは問題がないわけではありません。パッチは次のアップグレードには含まれません。そのため、新しいバージョンを入手するたびに、パッチを適用し、機能することを期待するか、適切な位置にマッサージする必要があります。そのため、メインプロジェクトに導入することで、長期的にはあなたとあなたの会社の時間を節約できます。

それはあなたにとって苦痛ですが、あなたはコミュニティに貢献しています。私は確かにすべての貢献者の貢献に感謝しています。それは質の高いソフトウェアが魔法のように大衆から生み出されたものではないということです。誰かが仕事をしなければなりません。（だから誰がすごいの？あなたはすごい）。気に入らない場合は、コミュニティに、それがどうあるべきかという議論に感謝している間、あなたはそれをするのに忙しすぎていることを発表してください。つまり、彼らは何をするつもりですか？あなたの賃金を削減しますか？

オープンソース文化を理解しやすくする1つの教義があります。仕事をする人が何に取り組むかを決定します。これは、開発者の日常業務と比較した場合の魅力の1つです。あなたの一番の優先順位は、彼らのバックログで＃50かもしれません。プルリクエストを修正しない場合、最終的にはおそらく一番上までトリクルされ、彼らがそれを処理します。しかし、あなたが彼らにとってそれを十分に簡単にするならば、彼らは今それを大事にします。

プルリクエストの修正を依頼するもう1つの理由は、もっと寛大です。彼らはあなたの貢献に対するクレジットを、それが小さいかもしれないほど小さくして欲しいと望んでいます。修正を行う場合、あなたの名前はコミットの著者フィールドの名前です。ほとんどの人は自分の貢献を十分に誇りに思っているので、メンテナのデフォルトの手口はそれらを許可することです。

あなたの雇用主に対するあなたの責任に関しては、あなたのビジネスがこのコードに依存している場合、あなたは彼らに損害を与えていません。雇用主は、時間をかけて自分の道具を研ぐ職人の利益を知っています。

知る限り、オープンソースの方法では、バグを修正する責任は、バグを修正するための負担を処理するのに十分な注意を払う人に任されています。状況に応じて、単に問題を無視することからバトルアップ（パッチを提供し、受け入れられるように議論する）まですべてを行って、修正されたことを確認しました。

すべてが正しい、プロジェクトを管理する人々にあなたから間違ったことを期待させないでください（つまり、ディスカッションオプションで問題を適切に修正してから何もしないことを希望する）、彼らはおそらく彼らよりも多くの問題を認識しています自分自身を処理することができ、可能な場合は、定期的な貢献者を作成しようとします。

元のバグはあなたにしか影響しないかもしれないので、パッチをコンプライアンスにするために必要なことを何でもすることによって提出を得るのは非常に興味があります。それ以外の場合、（他の修正が必要なため）プルする次のバージョンには修正がありません。

プロジェクトの新しいコピーを取得するたびに適用する必要のあるパッチのリストを維持する必要はありません-面倒です。もう少し時間がかかるので、永久に修正するので、再度対処する必要はありません。

オープンソース開発者にとって、2種類の問題があります：

• （a）パッチなしの問題
• （b）パッチが原因の問題

私は、ほとんどのオープンソースパッケージのメンテナー/開発者が、パッチを使ってコア貢献者以外の人をスピードアップさせるというアイデアを気に入っていると思います。

ただし、主な目標は、タイプBの問題の数を最小限にすることです。そのため、バーはかなり高く設定されています。

一部の人々はそれを乗り越えます。彼らは貢献者になるか、あるいは中核的な貢献者になることさえあります。他の人はあきらめます。オープンソースにはダーウィンの性質があります-適者生存。

チームがそれを受け入れるところまで、あなたの貢献を押して、輝かせることをお勧めします。いくつかの貢献をしたら、彼らはあなたをさらに信頼しますが、あなたの貢献が完璧であることを確認する必要があります。

最終結果は完全に価値があります。「私はコーディングしますか？はい...あなたは毎日書いたものを実行しています」と言うことができるようなもの。