OSS開発への変更提案の流れを選ぶ

質問、障害報告、開発、リリース、貢献の経路を使い分ける。

本体の履歴を書き換え、レビューなしで直接配布する。

追跡性とレビューを失う。

変更をブランチやパッチとして提出し、レビュー・テスト・合意を経て取り込む。

変更の品質と履歴を保つ一般的な開発フローである。

変更の目的やテスト結果を説明しない。

レビューに必要な情報が不足する。

再現できないバイナリだけを送る。

ソース差分と検証方法を確認できない。

patch

変更差分。

review

他者による確認。