見事な記事。ヤラレタ。

パッチの拒否率をさげる10の方法 - TokuLog 改め だまってコードを書けよハゲ
作者/メンテナにはパッチをうけとる義務も義理もない

さらによくするべく追補。

svn HEAD でパッチをつくる

これは「最新版に対して」の方がいいでしょう。というのも、svnを使っていない人たちもまだまだ多いので。また、patchを送る前に、最新版を入手して確認しておくのも忘れないようにしましょう。

作者のスタイルにあわせる

その通り。あえて追補すると、patchを送る側でなくて受取側の方。行頭tab/spaceのおかげでpatchがきれいに当たらない場合は、patch -l、行頭の空白を無視するオプションを試してみましょう。そのあとで、Cならindentをかけるなりperlならperltidyするなりすればよし。

テストを書く

これ、重要。今や patch そのものよりうぇるかむです。バグを「見える化」するだけでも、怠惰なオープソースプログラマーの傲慢に訴えることができます。

信用される

そのために一番いいのは、日頃から見えるように活動しておくこと。何かしたら開発者MLに報告する、カンファレンスにまめに顔を出す、などなど。

パッチの粒度に気をつける

これは上との兼ね合いで、信頼がすでに確立されている場合は、むしろデカpatchを一つ送ってえいやっしてもらうのがかえって歓迎されたりします。このあたりは別の意味で「作者のスタイルにあわせる」になりますか。

なぜパッチが必要なのかを書く

これに最も役立つのが、「テストを書く」です。メンテナーにとって最もむずがゆいのは、報告されたバグが再現しないこと。テストであれば(作者に環境があれば、ですが)再現性問題の8割が解消します。

この「テストを書く」は、少し広義にうけとってもらってかまいません。それはperlの場合は*.tファイルが理想ではありますが、code snippet でも充分です。とにかく「こうしたらこうなったけどこれどうよ?」というのが一目見て分かればOKです。

というわけでまとめると....

patches welcome, tests more welcome!
and commits the most welcome! (where applicable)

Dan the Open Source Programmer