十分な説明になるタイトルをつける

それだけで完結した説明文を書くようにする

Pull Reqには、動機や目的があるはずある。それを書く

「問題 → 解決」か「背景 → 提案」という構成を使うとよい

詳しくはPullRequestには、問題か課題を書く

実装方法について説明する

コードをみれば自明な場合は、「コードを見てほしい」と書く

関連するサイトやissueのリンクを貼る

スクリーンショットは必須

画像はURLではなく画像が展開されるようにしたほうが良い

Gyazoからmarkdownでコピー、もしくは ![](画像URL)

やらないことがある場合はリストで明示する

リファクタリングPRでテストが減っていないことを確認する方法も参照

作業途中でも積極的にPRをつくる。ほかの人が作業内容や進捗を追いやすくなる

作業途中の場合は、issue labelに WIP や In Progress をつけて作業途中であることを明示する

リポジトリによってlabelが違うので統一しておいたほうが良さそう

2020-10-26 現在は draft 状態で pull request 作成して、 review 後の修正も Review/QA 外せばよいと思ってるので要らないと思う

レビュー依頼であることを明示する

ZenHub 使う場合は Review/QA に移動するのがよさそう

レビュワーはレビュー完了であることを明示する

ZenHub ... -> Done

誰かひとりから「LGTM」「よさそう」などのメッセージをもらうとレビュー完了

PRがマージはとてもめでたいことなので画像などを使って最大限盛り上げる

便利な画像集

レビュー完了したら基本的にPR主が自分でマージする

mergeしたらなるべく早くrelease → リリースルール

たくさんコメントがある場合、 [MUST] , [SHOULD] , [MAY] , [質問] などと書くと修正必須なのか、すべきなのか、どちらでもよいのか、伝わって便利です。

なぜコードレビューを行うのかの解説が必要かも

現在の問題と新しい解決が簡潔明瞭

スクリーンショットがあり分かりやすい

動作確認方法が書いてあるので、レビューしやすい。影響範囲をどう捉えているかわかる

sentryへの送信というわりと検証が難しいものをlocalhostから送信して試している

試し方が書いてある（のでレビューアーも再現可能）

スクショが貼ってある