本記事は「はてなブログチーム柴崎優季氏が明かすGitHub活用ノウハウ（前編）」の続きです。

GitHubとレビュー

　以前は同僚に、「Pull Requestをしたのでレビューをお願いします」と詳しい人に個別にお願いするパターン。


　あるいは開発者が自分でPull Requestのなかからそれっぽい奴をさがしてレビューするか、という2パターンでやっていました。


　これもあんまりうまくいかなかったんですね。Pull Requestの状態が分からないので、いまレビューしてもらいたいのか、WIP（Work In Progress：仕掛かり中）で修正中なのか、レビューがもう終わっているのか。分からないので面倒になってレビューをためらうと。


　その結果レビューが消化されず、Pull Requestがすごい量になっているのだけど、誰がレビューするんだということで固まってしまうとか、ベテラン開発者がひたすらレビューをし続けるはめになるとか。


　GitHubのレビューツールはいいのですが、レビューの促進にはならないので、最近ではレビューの状態をはっきりさせようとか、レビュー依頼の一覧を分かりやすくしようとか、みんなでレビューしようという雰囲気作りをしています。

　そのためにやっているのが、レビュー状態ラベルとレビュータイムです。

　レビュー状態ラベルは、レビュー状態をはっきりさせるのと、レビュー依頼一覧を分かりやすくする取り組みで、Pull Requestに分かりやすいラベルを付けるというもの。

　今まさにレビューして欲しいときに「レビュー依頼」ラベルを付けて、レビューする人は「レビュー中」ラベルを付け、レビューしてコメントを付けたらレビューした人が「レビュー完了ラベル」を。それを見て、レビュー依頼をした人がなにもなければマージ、修正をしたら再レビュー依頼として「レビュー依頼」ラベルを付けると。


　issuesはラベル一覧を見ることができるので、いまレビューしてほしいものが分かるようになるのと、自分にアサインされているものの一覧も見ることができます。


　みんなでレビューする雰囲気作りのための取り組みとして、レビュータイムをもうけています。レビュータイムは、毎日ランチ後の14時にレビュー依頼タスクを片っ端からみんなで見るものです。


　その時間になるとボットに言われてやりはじめると。


　レビューのきっかけができて、毎日みんなでレビューするようになりました。

【次ページ】 GitHubとリリース