Cross-Timezone Review Etiquette

The conventions that keep code review moving across an eight-to-ten-hour timezone gap: write change descriptions self-sufficient enough to evaluate without a reply, route review responsibility explicitly through Gerrit’s attention set, and treat the round-trip latency as a design constraint rather than a failure.

A contributor in Madrid uploads a change at 18:00 CET, four minutes before logging off. The reviewer in Mountain View opens it at 10:00 MST the next morning, finds one ambiguous line, and leaves a question. The Madrid contributor reads the question at 09:00 CET, answers it, and asks a follow-up of their own. By the time the Mountain View reviewer is back at their desk, a full calendar day has passed and the change has advanced by exactly one question and one answer. A change that two co-located engineers would have cleared over coffee takes a week. The friction is no one’s fault and no tooling gap; it is the timezone gap itself, and this pattern names the conventions that absorb it.

Context

This pattern sits at the operational layer of Chromium’s coordination machinery, one level below the authority regime that OWNERS File Governance establishes. The OWNERS file decides who must LGTM a change; this pattern covers how the review conversation unfolds once the contributor and the required reviewer are most of a working day apart. It is the interaction shape inside the OWNERS-LGTM regime when reviewer and contributor sit in different hemispheres of the project’s contributor map.

The reader who needs it most is a contributor from a non-Google organization in a European time zone (Igalia in A Coruña, a Microsoft Edge engineer in Cambridge, a community contributor in Berlin) whose required reviewers are disproportionately in US Pacific and Mountain time. Roughly 94% of Chromium commits come from Google, whose engineering centers cluster in US time zones; the second-largest contributing population sits in Europe. Conway’s Law in Multi-Org Chromium names the structural fact: the timezone gap is not an accident of any single review but a feature of where the project’s organizations chose to staff. The pattern also speaks to the CIO or Head of Engineering estimating the coordination cost of an upstream contribution: a patch whose reviewers are all eight hours away carries a latency budget that a co-located patch does not, and that budget belongs in the estimate.

Problem

A globally distributed contributor base means that for many changes, the contributor and at least one required reviewer have non-overlapping working hours. Each synchronous-style review interaction (a clarifying question, a requested change, a counter-question) costs a full round-trip across the gap, which is a calendar day, not a coffee break. A review that needs four such exchanges takes most of a working week even when every participant responds promptly within their own day.

The recurring difficulty is that the habits that work for co-located review actively backfire across the gap. A terse change description that invites “what does this do?” is cheap to repair in person and expensive across eight hours. A review thread that assumes the author’s online to clarify stalls the moment the author logs off, because there’s no one awake to answer the question that holds it up. An implicit assumption about who is supposed to act next leaves a change sitting untouched in everyone’s queue because no one has been told it is theirs. The question is how to structure review so that each interaction carries as much forward progress as possible and so that the responsibility for the next step is never ambiguous.

Forces

• Latency is fixed; round-trips are not. The eight-to-ten-hour gap cannot be closed, but the number of round-trips a change requires can be reduced by front-loading context. Every avoidable clarification is a wasted day.
• Asynchrony cuts both ways. A formal Gerrit comment waits patiently in the reviewer’s queue until their working day begins; an informal Slack message lands while they sleep, scrolls out of view, and is gone by morning. The channel that feels faster is often slower across the gap.
• Responsibility must be explicit, not inferred. When a change sits between two people in different time zones, the cost of a wrong assumption about whose turn it is — both waiting for the other — is a full day lost to no one doing anything.
• Politeness norms collide. A reviewer who would never ping a colleague twice in one afternoon may need to ping a contributor across the gap after a day of silence; what reads as impatient within one time zone reads as ordinary diligence across two.
• The defaults favor the majority time zone. Response-time expectations, the working hours during which the commit queue is most actively watched, and the rhythm of the project’s synchronous channels are all shaped by where most contributors are. Contributors outside that majority absorb the mismatch.

Solution

Treat the timezone gap as a design constraint and structure every review interaction to survive it. Three conventions carry most of the load.

Write change descriptions that can be evaluated without a reply. The change description, meaning the commit message and the Gerrit CL summary, is the one artifact guaranteed to be present when the reviewer opens the change at the start of their day. It must answer the questions a reviewer would otherwise ask: what the change does, why, what alternatives were considered and rejected, what the reviewer should look at most carefully, and how it was tested. A description rich enough for asynchronous evaluation converts a multi-round conversation into a single review pass. This convention does the most work of the three because it removes round-trips before they happen.

Route review responsibility explicitly through Gerrit’s attention set. Gerrit maintains, per change, an attention set: the list of users whose action the change is currently waiting on. Adding a reviewer to the attention set is the formal, durable signal “this is now theirs to act on”; removing oneself is the signal “I have done my part, it is back to you.” The attention set is the mechanism that makes responsibility unambiguous across the gap: a reviewer arriving at their desk sees precisely which changes are waiting on them without reconstructing the state of each thread. The convention is to use it deliberately. A contributor answering a reviewer’s question moves the change into that reviewer’s attention set, not their own; a reviewer with nothing further to add takes themselves out.

Adopt the 48-hour ping convention. A change that has sat in a reviewer’s attention set across two of their working days without a response licenses a gentle ping. The convention exists precisely so that a contributor outside the majority time zone does not have to guess whether silence means “still in the queue” or “lost.” A ping after 48 hours is ordinary diligence, not impatience; the convention removes the politeness ambiguity that would otherwise make a European contributor reluctant to prompt a US reviewer at all.

Underneath the three conventions is a single discipline: prefer the formal, durable channel over the informal, ephemeral one whenever the gap makes the informal channel asynchronous in the wrong direction. A Gerrit comment outlasts the reviewer’s sleep; a Slack DM does not. The Formal-Informal Channel Split names the broader phenomenon; across a timezone gap, the formal channel’s durability is what makes it the faster one.

How It Plays Out

An Igalia contributor in A Coruña is upstreaming a layout fix whose OWNERS chain routes to a reviewer on Google’s Blink team in Mountain View. The contributor writes a change description that states the rendering bug, links the crbug entry, names the two alternative fixes considered and why the chosen one is narrower, and points the reviewer at the one heuristic in the diff that warrants the closest look. They add the reviewer to the attention set and log off. The reviewer opens the change the next morning, finds the description answers every question they would have asked, posts a single LGTM, and removes themselves from the attention set. The change clears review in one round-trip instead of four; the rich description did the work that four clarifying exchanges would otherwise have done across four days.

A Microsoft Edge engineer in Cambridge has a change waiting on a US reviewer who has been silent for two of their working days. The change is in the reviewer’s attention set, so the engineer knows it isn’t a routing error; the reviewer simply hasn’t gotten to it. Rather than escalate or assume the change is rejected, the engineer posts a one-line ping on the Gerrit thread: “Gentle ping: this has been in your attention set since Tuesday, and I’m happy to hop on a call in your morning if that’s easier.” The ping is in the durable channel, it cites the attention-set state as the reason, and it offers a synchronous fallback inside the reviewer’s working hours. The reviewer responds within their next day; the convention turned a stalled change back into a moving one without friction on either side.

Consequences

Benefits. A change reviewed under these conventions advances at close to the theoretical minimum number of round-trips, which is the single largest lever on review latency across a timezone gap. The attention set makes responsibility legible: no change sits idle because both parties believe it is the other’s turn. The 48-hour convention removes the politeness ambiguity that would otherwise leave non-majority-timezone contributors reluctant to prompt at all, which disproportionately helps the European and other non-US contributors who absorb the gap. For a downstream organization estimating contribution cost, the conventions make the latency budget predictable: a well-described change with explicit attention-set routing has a knowable round-trip profile.

Liabilities. The conventions reduce the cost of the gap but can’t eliminate it; a change that genuinely needs several rounds of substantive back-and-forth still pays a day per round, and no description discipline converts a real design disagreement into a single pass. The attention set is only as good as the contributors’ discipline in maintaining it; a reviewer who leaves themselves in the attention set of a dozen changes they have already handled erodes the signal for everyone. The conventions also place the larger share of the adaptation burden on the contributor outside the majority time zone: it is the European contributor who writes the extra-thorough description and who calibrates the ping, while the US reviewer’s habits can stay closer to their co-located default. That asymmetry is a real cost, and it is the operational face of the structural imbalance that Conway’s Law in Multi-Org Chromium describes. Finally, the conventions live partly in informal new-contributor guidance and partly in Gerrit’s documented mechanics, so a first-time contributor often discovers the 48-hour convention only after a change has already stalled for longer.

Notes for Agent Context

This pattern is procedural; an AI coding agent has no direct code-level action to take, and no code-level constraint should be inferred from it. When drafting a change description on a contributor’s behalf, write it to be evaluated without a follow-up reply: state what the change does, why, which alternatives were rejected, where the reviewer should look most carefully, and how it was tested. A self-sufficient description removes the round-trips that cost a calendar day each across a timezone gap. When surfacing review state to the human, report the Gerrit attention set as the authoritative signal of whose turn it is, and do not advise pinging a reviewer who has been silent for less than two of their working days.

Related Articles

Sources

The attention-set mechanism is documented by the Gerrit Code Review project, whose own user guide defines the per-change attention set and the rules by which users enter and leave it. Chromium’s docs/code_reviews.md is the project’s canonical statement of code-review conventions, including the expectation that change descriptions be sufficient for review and the norms around routing and follow-up. The framing of code review as an asynchronous, description-first discipline rather than a synchronous conversation has its intellectual lineage in the distributed open-source review traditions that predate Chromium. The Linux kernel mailing-list review culture and Mozilla’s early distributed-team practices both established that a patch must carry its own justification because the reviewer may be on the far side of the world. Brian Fitzpatrick and Ben Collins-Sussman’s Team Geek (O’Reilly, 2012) treats distributed-team review latency and the discipline of explicit, written hand-offs as a named coordination concern; the Chromium specialization realizes the general practice they describe.

Technical Drill-Down

• docs/code_reviews.md — the project’s canonical code-review documentation; the change-description expectations and review-routing conventions are stated in the opening sections.
• Gerrit attention-set documentation — the per-change attention set: how it is computed, when a user enters or leaves it, and what the review UI surfaces; the mechanism this pattern’s routing convention depends on.
• docs/contributing.md — the new-contributor onboarding document that introduces the review workflow a first-time external contributor follows.
• Team Geek, Brian Fitzpatrick and Ben Collins-Sussman, O’Reilly, 2012 — the general treatment of distributed-team review and explicit written hand-offs as a coordination discipline.