他の人々のオープンソースプロジェクトをフォークするためのネチケットは何ですか？
私はオープンソース開発にますます従事するようになり、フォークを適切に文書化して維持する方法に関するガイドラインがあるかどうか疑問に思っていましたか？
たとえば、プロジェクトにforkして、特定のものを追加するとします。たぶん、あなたはプルリクエストを元のプロジェクトに送りたくないでしょうか、あるいはあなたの追加がマージされないものかもしれません。これで、実際には自分のバージョンではないプロジェクトのバージョンができました。おそらく、それを維持したくないし、本当に理解したくないでしょう。
ただし、元のプロジェクトが成長し続ける場合は、パッチや新機能を組み込んでおくとよいでしょう。それで、あなたは何をしますか？常にリベースするか、変更を継続的にマージしますか？ブランチはどのように設定しますか？変更前のブランチは常に変更されていないマスターブランチを、変更用の別のブランチに保持していますか？
ドキュメントはどうですか？プロジェクトをかなりよく説明しているので、オリジナルのreadmeを保持する必要があります。ただし、フォークの動作を別の方法または追加で指定する必要もあります。自動ビルドサーバーへの参照は、元のプロジェクトに関連しているため、Readmeから削除する必要があるかもしれません。
コードをforkして変更するのは簡単ですが、それだけでは十分ではありません。適切で健全なオープンソース開発に関するあなたの意見、経験、推奨事項を聞きたいと思います。
私は、DVCSサービス（GitHubなど）でホストされているプロジェクトを参照していると想定しています。フォークとマージが通常の方法です...
コードをforkして変更するのは簡単ですが、それだけでは十分ではありません。
何のために十分ですか？
自分の利益のためだけにこれを行っている場合、これは簡単なことではありません。好きなようにしてください。ただし、分岐したプロジェクトを損なうことがないように、静かに実行してください。
他の人の利益のためにこれを行っている場合、マージするつもりがないときにフォークして変更することはおそらく悪いことです：
あなたは必然的に元のプロジェクトに取り組んでいる人々と対立します。
あなたは、開発者の努力が必然的にもっと薄く広がる状況を作り出しています。それは非効率的です。
ユーザーに不確実性と混乱を引き起こしています。彼らはどのバージョンを使うべきですか？彼らは彼らのフォークで働き続けるために誰を信頼すべきですか？物事を正しく行うには？
長期的なパブリックフォークを維持する本当に本当に正当な理由がない限り、常に元に戻すことを目指してください。そして、あなたのプルリクエストが受け入れられるためには、あなたは貢献のためのプロジェクトの書かれたガイドラインに従うべきです。ガイドラインがない場合は、既存のコードベースの最良の部分を例として扱います。 （ドキュメンテーションがある場合は、それを追加/更新します。ユニットテストがある場合は、変更のユニットテストを含めます。）それ以外の場合、これらのことを行うと、プルリクエストが受け入れられる可能性が高くなります。
プルリクエストを受け入れるためのもう1つの戦略は、開発者と何をしようとしているのかについて話し合い、コーディングを始める前に問題について話し合うことです。そして、彼/彼女が言うことを聞いてください。礼儀正しく、敬意を払い、辛抱強くお待ちください。 prima donnaにならないでください。
私は死んでいないように見え、その意図が何であるかを示す適切なドキュメントがある健康なプロジェクトフォークを維持する方法について尋ねました。
さて、私の最初のアドバイスはしないでください...あなたが正当な理由がない限り...上記の理由により、長期的なパブリックフォークは不健康です。
それ以外は、健全なフォークを維持することは、健全なプロジェクトを維持することと同じです。たとえば、ドキュメントを作成し、活動を維持し、サポートを提供し、他の貢献者を募集します...目的と計画を持っています。
たぶんあなたは元のプロジェクトにプルリクエストを送りたくないでしょう、あるいはあなたの追加はマージされないものかもしれません
それで終わりです。
マージやプルを気にしないのに、変更を元のプロジェクトに組み込むことを気にするのはなぜですか？深刻な人のためにそれを保存してください。これは、フォークを再配布する意図がない場合や、フォークを組織内でのみ配布する場合に特に当てはまります。
要するに、真剣な貢献者になるか、そうではありません。
貢献者であることを真剣に考えている場合、それに取り組む最善の方法は、プロジェクトオーナーに連絡することです。一般に、有用な変更を提供することによって信頼できることを実証した場合、プルリクエストを作成できます。プロジェクトオーナーは、適切なドキュメント、リリーススケジュールなどに関して期待することを伝えることができます。