@vvakame氏によるGitHubで簡単！コントリビューション！

わかめ@毎日猫がいる @vvakame

GitHubで簡単！コントリビューション！という記事を書こうかなーと一瞬思ったけどめんどくさいのでやめた。スクリーンショット撮って貼るのがめんどくさいのだ。

わかめ@毎日猫がいる @vvakame

GitHubで簡単！コントリビューション！オープンソースなプロジェクトに君も貢献しよう！

わかめ@毎日猫がいる @vvakame

コントリビュートのコツとしては、CONTRIBUTING.mdが存在したらそれを読むこと。README.mdもなんとなく読むこと。

わかめ@毎日猫がいる @vvakame

あとは、"必ずレビューされる"ことを意識すること。会社でレビュー受ける時とさほど変わらないだろう。APIの互換性を壊さないこと。テストがある場合テストを壊さないこと。diffを変に大きくしないこと。

わかめ@毎日猫がいる @vvakame

最近のOSSはTravis-CIとかdrone.ioとかなんかかやでテストされているので、README.mdにビルド状況のバッヂが付いていることが大半です。そのバッヂをクリックするとどういう手順でテストが実行されているかわかるので、それを見てローカルでテストが通るのを確認しよう。

わかめ@毎日猫がいる @vvakame

さらに、pull requestを投げた後に、自分のpull requestに×マークが出ないか、チェックしよう。ビルドサービスの都合上pull requestを出してからしばらくかかる。×になったのを確認したら修正コミットを作って追加で同じブランチにpushしよう。

わかめ@毎日猫がいる @vvakame

コレを忘れてると、めんどくさがりのメンテナ(俺だ)の場合、レビューせずに放置することすらあります(テスト直してくれって英語で書くのめんどくさいんだよ！！！

わかめ@毎日猫がいる @vvakame

APIの互換性を壊さないことは大事だ。イケてない名前やクラスを見つけても、気軽に修正してpull requestを投げても通らない確率のほうが高い。とはいえpull request投げないと始まらないのも事実なので、そういう修正を投げる時はかならず単独の変更として投げよう。

わかめ@毎日猫がいる @vvakame

というのも、APIに非互換を持ち込む変更とまともなリファクタリングを一緒くたのpull requestにして出すと、まとめてrejectするしかないからだ。非互換な変更を含ませたい時は必ずその部分だけ単独のpull requestにしたほうが僕としては嬉しい。

わかめ@毎日猫がいる @vvakame

あとはテストを追加すること。テストを追加しない場合、プロジェクトの性質やメンテナの性格にもよるが、内心「あー、直してって言ってすぐやってくれるかなー…」みたいな気持ちになることが多いので、最初っから含まれていたほうがまぁ無難だ。

わかめ@毎日猫がいる @vvakame

でもまぁ「テストやり方わかんなかったんだけどどーすりゃいいの？教えてくれたら追加してpushするよ」みたいなことを書いてもいいと思う。そしたら参考になるソースとかを適当に提示したりしてくれるはずだ多分。

わかめ@毎日猫がいる @vvakame

あとはdiffを大きくしないことだな。コミット単位ではなくてpull request単位で。例えばインデントを整えたり改行コード変えたりするのと、普通のコード修正が混じってたりするとかなりげんなりする。

わかめ@毎日猫がいる @vvakame

なんでかっつーとGitHubはpull request全部まとめてのdiffが見やすいUIになってる。つまり、コミット単位でのレビューって僕はあんまりしないんだね。コミットログを綺麗にするぞという気合入ったプロジェクトだとまた別の運用かもしんないけど。

わかめ@毎日猫がいる @vvakame

だもんで、普通の変更と改行コードやインデントの変更が入り乱れているとかなりレビューがつらい。ぶっちゃけ後回しにして、気が乗らなかったら次の日に回したりする。GitHubの場合、URL末尾に ?w= ってパラメータ生やすとある程度空白系diff殺してくれる機能がある。

わかめ@毎日猫がいる @vvakame

だもんで、 ?w= つけて見やすければさほど気にはしないんだけど、まぁコミット作る時点で変なdiffが入らないようにしたほうがまぁpull request送る側も楽でしょ多分。

わかめ@毎日猫がいる @vvakame

こんだけやっとけばとりあえず問題ないんじゃないかなぁ。一番重要でかつ各プロジェクト共通なのが twitter.com/vvakame/status… ね。これはきっちりやろう。これだけこなしておけば少なくとも無視されるレベルでめんどくさがられはしないと思う。

わかめ@毎日猫がいる @vvakame

あと、英語でdescription書くのがめんどくさい場合。 environment: (デバッグに重要そうな情報書く) reproduction: (問題が具体化するコード例書く) expected: (こう動くと思ってた的なコード例書く) で十分だと思う。

わかめ@毎日猫がいる @vvakame

とりあえず、何か要望がある場合はIssue書く、pull request出す。それで具体的な対応してくれなかったらとりあえず作者をdisるかそのプロジェクトをdisって見限ろう！！！

わかめ@毎日猫がいる @vvakame

みたいな感じのことをQiitaに書きたかったけどめんどくさかった。