@vvakame氏によるGitHubで簡単!コントリビューション!
- suda_hiroshi
- 4729
- 0
- 47
- 4
GitHubで簡単!コントリビューション!という記事を書こうかなーと一瞬思ったけどめんどくさいのでやめた。スクリーンショット撮って貼るのがめんどくさいのだ。
2014-08-11 00:31:45コントリビュートのコツとしては、CONTRIBUTING.mdが存在したらそれを読むこと。README.mdもなんとなく読むこと。
2014-08-11 00:36:26あとは、"必ずレビューされる"ことを意識すること。会社でレビュー受ける時とさほど変わらないだろう。APIの互換性を壊さないこと。テストがある場合テストを壊さないこと。diffを変に大きくしないこと。
2014-08-11 00:37:25最近のOSSはTravis-CIとかdrone.ioとかなんかかやでテストされているので、README.mdにビルド状況のバッヂが付いていることが大半です。そのバッヂをクリックするとどういう手順でテストが実行されているかわかるので、それを見てローカルでテストが通るのを確認しよう。
2014-08-11 00:38:26さらに、pull requestを投げた後に、自分のpull requestに×マークが出ないか、チェックしよう。ビルドサービスの都合上pull requestを出してからしばらくかかる。×になったのを確認したら修正コミットを作って追加で同じブランチにpushしよう。
2014-08-11 00:39:29コレを忘れてると、めんどくさがりのメンテナ(俺だ)の場合、レビューせずに放置することすらあります(テスト直してくれって英語で書くのめんどくさいんだよ!!!
2014-08-11 00:40:07APIの互換性を壊さないことは大事だ。イケてない名前やクラスを見つけても、気軽に修正してpull requestを投げても通らない確率のほうが高い。とはいえpull request投げないと始まらないのも事実なので、そういう修正を投げる時はかならず単独の変更として投げよう。
2014-08-11 00:41:31というのも、APIに非互換を持ち込む変更とまともなリファクタリングを一緒くたのpull requestにして出すと、まとめてrejectするしかないからだ。非互換な変更を含ませたい時は必ずその部分だけ単独のpull requestにしたほうが僕としては嬉しい。
2014-08-11 00:42:21あとはテストを追加すること。テストを追加しない場合、プロジェクトの性質やメンテナの性格にもよるが、内心「あー、直してって言ってすぐやってくれるかなー…」みたいな気持ちになることが多いので、最初っから含まれていたほうがまぁ無難だ。
2014-08-11 00:43:53でもまぁ「テストやり方わかんなかったんだけどどーすりゃいいの?教えてくれたら追加してpushするよ」みたいなことを書いてもいいと思う。そしたら参考になるソースとかを適当に提示したりしてくれるはずだ多分。
2014-08-11 00:44:20あとはdiffを大きくしないことだな。コミット単位ではなくてpull request単位で。例えばインデントを整えたり改行コード変えたりするのと、普通のコード修正が混じってたりするとかなりげんなりする。
2014-08-11 00:45:44なんでかっつーとGitHubはpull request全部まとめてのdiffが見やすいUIになってる。つまり、コミット単位でのレビューって僕はあんまりしないんだね。コミットログを綺麗にするぞという気合入ったプロジェクトだとまた別の運用かもしんないけど。
2014-08-11 00:46:20だもんで、普通の変更と改行コードやインデントの変更が入り乱れているとかなりレビューがつらい。ぶっちゃけ後回しにして、気が乗らなかったら次の日に回したりする。GitHubの場合、URL末尾に ?w= ってパラメータ生やすとある程度空白系diff殺してくれる機能がある。
2014-08-11 00:47:33だもんで、 ?w= つけて見やすければさほど気にはしないんだけど、まぁコミット作る時点で変なdiffが入らないようにしたほうがまぁpull request送る側も楽でしょ多分。
2014-08-11 00:48:14こんだけやっとけばとりあえず問題ないんじゃないかなぁ。一番重要でかつ各プロジェクト共通なのが twitter.com/vvakame/status… ね。これはきっちりやろう。これだけこなしておけば少なくとも無視されるレベルでめんどくさがられはしないと思う。
2014-08-11 00:49:53あと、英語でdescription書くのがめんどくさい場合。 environment: (デバッグに重要そうな情報書く) reproduction: (問題が具体化するコード例書く) expected: (こう動くと思ってた的なコード例書く) で十分だと思う。
2014-08-11 00:51:33とりあえず、何か要望がある場合はIssue書く、pull request出す。それで具体的な対応してくれなかったらとりあえず作者をdisるかそのプロジェクトをdisって見限ろう!!!
2014-08-11 00:52:24