コミッタとレビューアの責任

https://www.chromium.org/developers/committers-responsibility

Chromiumレポジトリにコミットするときは、以下のガイドラインを確認すること。

1. 適切なレビューアを見つける。
2. トライボットを使い、すべてのプラットフォームで結果がグリーンであることを確認する。またはコミットキューを使う。
3. 変更を着地させる前にIM, Slack, ircを利用する。
4. ビルドボットコンソールを見てグリーン化チェックする。
5. 変更をもとに戻すときは、コードレビュページの「Revert Patchset」ボタンを使う。
6. TBR変更(To Be Reviewed)を着地させるときは、コード所有者に通知する。

要約すると、正しいことをすること、簡単にコミットしようとしないこと、最善の判断をすること。

恐れずに質問すること。Slackにはいつも助けてくれる人がいる。

多くのレビュアと共同での変更

多くのレビュアを伴った変更がよくある、変更が多くの領域にまたがり、責任や専門性がことなることがあるため。

ガイドラインがないとレビュアの責任が不明確になる。

あたなが唯一のレビュアなら、あなたはいい仕事ができるだろう。他に３人レビュアがいると、他のレビュアに任せるべき領域もあると思うだろう。みんながこのように考えるとレビューが適切に行われなくなる可能性がある。

他にも、もしあるレビュアが「LGTM」といって、他のレビュアが不十分だと感じてる場合もある。作成者はこの状況に困惑し、未熟なままコミットされてしまうこともある。

同時に、多くの人にはレビュアになってもらい、状況認識の保全に役立ててほしい。

そこでプロセスを透明化するためのガイドライン：

1. 作成者が複数のレビュアを要求しているときは、各レビュアの責任を明確にする。例えば以下のようなメールを書く。

  larry: bitmap changes
  sergey: process hacks
  everybody else: FYI

このケースであなたはマルチプロセスに関する変更のためのレビューをすることを頼まれ、作成者や他のレビュアはあなたを主要のレビュアであることを期待してないとみなすものである。

1. あなたが複数レビュアによるレビューを受けたが作成者が受けていない場合は、彼らに連絡し自分の責任の範囲を把握すること。
2. 作成者はチェックインする前にすべてのレビュアによる承認を待つこと。
3. 明確な責任のないレビュア（drive-byレビュー）は、レスポンシブになりレビューを停滞させないこと。作成者は彼らに急がせること。
4. あなたがFYIなレビュアで詳しくはレビュしなかったが、そのパッチで特に問題が生じていないなら以下のことに注意すること。"LGTM"の代わりにゴム印や"ACK"のような反応をすること。こうすることでレビュアはあなたのレビューを十分信頼できないと前提し、作成者はあなたのフィードバックを待つ必要がないことを知ることができる。できることなら、みんなが責任を持ちレビューに参加することが望ましいがこのやり方のほうがスピードアップするかもしれない。