オープンソースプロジェクトへの貢献は、所有者によってどのように管理されるべきですか？

（GitHubなどのサービスを使用して）オープンソースプロジェクトを管理する場合、次のように対応します。

誰かが新しい機能を追加したり、問題に対処するためのパッチを親切に提出してくれました。次のいずれかの状況が発生します。

• ソースコードが1つまたは複数の命名規則などを満たしていません。
• ソースコードは特定の方法で改善できると思います。おそらく、はるかに単純なソースで同じ効果を達成できるか、または別の有用な機能が必要になるでしょう。

Q1。提出されたソースを変更することは受け入れられますか？（これはGitHubで可能ですか？）

Q2。そのような提出はすべて、提出ガイドラインに従って拒否されるべきですか？

Q3。Q2が「はい」の場合、実装が不十分な、本当にすてきなアイデアはどうでしょうか。先に進んで自分で作成しても構いませんか？

私は貢献を奨励したいのですが、同時に特定の基準を維持することが重要です。

プロジェクトの標準を説明するドキュメントをまだ設定していない場合は設定します。プロジェクトにコードを提供する際に重要だと感じるすべてのことを必ず説明してください。

次に、コードを提供した人に、その貢献に非常に感謝しており、パッチを含めたいが、いくつかの問題があることを詳しく説明してください。ドキュメントへのリンクを提供し、表示される特定の問題を引用します。次に、その人に問題を修正してコードを再送信するよう依頼します。

コントリビューターが多すぎず、このコントリビューションがかなり価値がある場合、パッチをそのまま受け入れてから、次のコミットで自分でパッチの一部を書き換えるか、コーディング標準に合わせて再フォーマットすることができます。—その後、投稿者に、行った変更の差分へのリンクを記載したメールを送信します。寄稿者が差分を調べて、次回より良いパッチを提出することを願っていますが、修正する必要はありません。

貢献者ガイドまたはコーディングスタイルのドキュメントをまだ作成していない場合、これは良い考えかもしれません。実際、ほとんどの貢献者が何の間違いをするか気づくまで、しばらくこの方法（パッチを受け入れて修正し、diffへのリンクをメールで送信）を続けることができます。そして、あなたはそれらの間違いだけを貢献者ガイドとスタイリングガイドに含めます 。

この方法で物事を行うと、Q1〜Q3に対する答えは次のようになります。

• Q1：はい、後続のコミットで送信を編集します
• Q2：該当なし（まだガイドラインを作成していないと仮定しました）
• Q3：感謝し、それを書き直してください:-)（おそらく、次のコミットでパッチを完全に書き直しても、パッチを適用しても意味がありません）