おきらくプルリク生活のススメ
この記事は 武蔵野 Advent Calendar の12日目の記事です。
なぜこんな記事を書いたか
この記事を書いた目的は，私の (しょぼい) pull-request (以下「プルリク」) 遍歴を振り返って，「こんなにしょぼくても大丈夫だから，みんな気軽にOSSにプルリクしよう」ということを呼びかけることにある。
技術的な内容を期待して読みに来られた方は，ここで踵を返して明日の記事に期待されることをお勧めする。
とりあえず一覧
私はここ数年 Cloud Foundry というオープンソースPaaSの周辺に生息しているので，プルリクは全部 Cloud Foundry がらみのものになっている。従ってコミュニティについての印象等は，あくまで Cloud Foundry コミュニティに限定されたものと考えてほしい。
当初はこの一つ一つについて思い出話を書こうかと考えていたが，そんなダラダラしたもの読まされてもつまらないだろうと思い直して，上の表にあるプルリクを眺めて感じた「おきらくプルリク生活のススメ」を以下に書いていくことにする。
ススメ1：がんばらない
上の表を見るとわかるように，数がとても少ない。約4年間で16件，年平均4件しかない。
スキル向上や，コミュニティでの知名度向上のために，GitHubのactivitiesを緑で埋めることは素晴らしいことだと思う。だが，別にそういう意識の高い人以外はOSSに貢献してはいけないというわけでもない。年4件でも年1件でも，思いついた時にプルリクを出すくらいで全く問題ないと思う。
ススメ2：しょぼくてもいい
同じく表からすぐわかるが，1件(No.6)以外は全て1コミット。行数も±1行〜多くても数行がほとんどである。
これは，No.5とNo.6以外は，基本的に「何か不具合を見つけたので，それを修正する」プルリクであることが大きな要因になっている。
ちなみにNo.5とNo.6は，組み合わせである程度の規模の機能を提案するプルリクだったが，他に優先度の高い機能の実装作業があるという理由でrejectされた。
実はこのような規模の大きい機能の提案の方が受け入れられにくい傾向があるように思う。なので，プルリク経験が浅くて成功体験がほしい人は，むしろしょぼいプルリクの方がお勧めだと思う。
ススメ3：気負わない
表の result の列を見ると，closed で終わっているものがそこそこあるのが目につく。受け入れられなかった理由はさまざまなのだが，重要なのはあまり結果にくよくよしないことだと思う。
プルリクがrejectされても，別に命を取られるわけではないし，コミュニティで爪弾きにされるわけでもない。だからプルリク出すのに一大決心は必要ない。成否は気にせず気楽に出すのが良いのではないだろうか。
＃ちなみに自分のちっぽけなプライドのために一応補足しておくと，
＃No.12, No.13 はプルリクとしては closed になっているが，
＃修正としては accepted で delivered という扱いになっている。
ススメ4：とはいえ信念は持とう
自分のケースでは特にそうなのだが，
- 実環境や動作検証で不具合らしきものを見つける
- 原因を調査
- コードを読んでその修正方法を決定
という手順を踏んでのプルリクなのだから，最後の「自分の修正方法」が採用されないとしても，最低限「不具合の存在」と「その原因」くらいはわかってもらうよう努力はしたい。
なので，必要だと感じたら，プルリクのコメントで議論することを恐れるべきではない。相手も間違えたりすることもある普通の人間なので，委縮する必要もないと思う。
＃これに関係しそうなプルリクは，上の表でいうと No.13, No.14 あたり。
ススメ5：タイミングを逃さない
「ススメ3：気負わない」を書いていて気付いたのだが，rejectされたプルリクのうちいくつか (No.1, No.10) は，「もうそのコード古いから」という理由で却下されていた。
OSS (特にコミュニティが活発なもの) は，コードの変化が激しい。なのでプルリクを出すならタイミングよく出した方が良い。そういう意味でも，しょぼいプルリクはお勧めだと思う (まあしょぼくてもタイミングを逃すような人間＝自分もいるが)。
ススメ6：英語であまり悩まない
上の表のリンク先のプルリクを見てもらえればわかるが，私のプルリクの英語としての正しさはとてもいいかげんである。
また私は他の人のプルリクを手伝ったことも何度かあるが，英文添削を依頼された時にあまり文章をいじらないように心がけていた。さすがに意図と真逆の意味になってしまうような表現は直したが，動詞の時制や，名刺につける冠詞，単数形複数形の別などは，「間違っている」と自分が感じても修正せず素通しした。
「英語が完璧でなければ恥ずかしくてプルリクが出せない」なんてことはないと思う。プルリクで知性が問われるポイントは，英語の正確さではない。不具合の再現方法やコードの書き方のほうが遥かに重要だと思う。
ススメ7：最後はリポジトリーのオーナーに委ねる
「ススメ3：気負わない」と多少かぶるが，(open のまま放置されることも含めて) 最後はリポジトリーのオーナーに委ねるという気持ちでいる方が，精神衛生上良いと思う。
そもそもOSSへのプルリクは，自分が見つけた／感じた，(他の人がまだ気づいていない) 問題を，解決方法付きで公開して共有するものである。ということは，プルリクを出した段階で，「他の人が同じ問題を踏まないようにする」という目的の大半は達成できていることになる。
プルリクが提示する問題の重要さをどう評価するか，その解決手段として提案された方法を採用するかどうかは，もうリポジトリーのオーナーの問題であり，責任である。
プルリクは「出したら役目は果たした，マージされればラッキー」くらいの気楽さで取り組んでも良いと思う。
終わりに
全く技術のことに触れない，ひたすらエモいだけの文章になってしまったことは，正直，読者にも，この Advent Calendar の他の書き手にもうしわけない。
ただ，これを読んでプルリクを出す人が一人でも増えれば幸甚である。