Minimizing Review Lag Across Time Zones
If you're reviewing a change for someone in a different time zone, one review cycle can take up to 24 hours.
It's useful to remember that many contributors working outside of PST are constantly blocked on reviews. We can't rewrite the laws of physics but here are some tips on making the process go faster:
- Please consider "LGTM with nits.", If a review from a committer has only minor issues. This small phrase can unblock an excited non-PST engineer a full 24 hours sooner!
- Don't require a second round for trivial changes.
- For owner reviews: provide an owner LGTM if the overall approach and structure of the CL looks good, but ask the CL author to find a reviewer in their timezone to work with to get all the details right.
- If you have changes you want to see or if you don't like the CL ==suggest a solution and provide as much information as possible.== Terse responses mean a full 48 hours can go by before the non-PST person can ask "How would you suggest I accomplish this?" and then another 24 while they wait for the answer. Please don't simply ask questions on the review; ==suggest an acceptable solution==.
- Along the same lines, if you don't like the way something is named ==please suggest an alternate name== that you'd find acceptable.
- See this notice about acceptable latency for code reviews.