OSS Contribution とは

メンテナチームやコミュニティ内で該当箇所について訳知りな人は誰かという人間関係の把握から入って、その人とできるだけ早くコンタクトできる経路はどれかなーと思慮をめぐらして、初めて話す人ならpoliteな説明と自己紹介から入り、何ならリリース計画みたいなものがあればそれも考慮に入れて話す。（そのほうが受け止められやすい）

そんなんやってらんないよー、とならないために、よく使うOSSのコミュニティには日常的に入り浸って雰囲気を把握しておくのが便利

「ときどき話してるあの人か、じゃあ事情はだいたい知ってるだろう」となっていれば受け入れも速い。そうでない場合「この人はちゃんとメンテナ側の事情を把握しているだろうか、コードの過去事情を把握してるだろうか」という防御的な視点で見られることになってしまい、mergeは遅れるだろう

規模の大きなソースであれば特にそうだが、基本的に開発者は（どんなに優秀であれ）昔書いたコードのことはどんどん忘れてしまう。「お前が書いたんだからすぐレビューできるだろ」はそんなに通用しない。誰だってそうだ。そもそも「書いた人」がずっとチームやコミュニティにとどまっているわけでもない

もちろん、小規模な変更であればPRを一発送り、descriptionに細かく事情説明などを書き込んでおけばしばらくすればmergeされることも多い。が、人気のライブラリであればPRは毎日のように届いているはずなのでtriageも楽じゃない。

事前に「こういう事情があってこういうパッチ送りたいんだがどうだろう」と担当者と議論済みの上で送るパッチのMTTM（mean time to merge）と、その事前協議にかけた時間との合計

特に事前協議はしてないが、細かく事情説明などをdescriptionに添えてあって、それだけ読めばわかるようになってるPRのMTTM

↑この2つはだいたい「正味時間」では近しいものになるだろう。が、いろんなリポジトリをメンテしているチームのOSSだと、PRの通知は埋もれがちで、それだけではすぐに処理されないことのほうが多い。よって、急ぐ場合は先に「速い窓口」を探して協議してからパッチを送るのがベター、となる

特に事前協議しておらず、事情説明などもあまり詳しくないPRはメンテナ側視点だと実に度し難い。レビュー負荷が高く、下手すりゃありがた迷惑だ。

そうするとここまで書いてきたようなコミュニケーションを（多くの場合）英語でやるのが億劫な人は気後れしてしまうことになる

とはいえ「誰か」がコミュニケーションコストを払わざるを得ないのだとすれば、「変更を導入したい側」が負担するしかない

結論：ContributionとはCommunicationにほかならない