Three-LGTM API Owner Gate

The hard rule that an Intent to Ship clears only after three Blink API owners each post LGTM in the public thread: three approvals from a named cross-cutting population, not from the feature team or its management.

“Approval will require three LGTMs from API owners.” — Chromium project, Blink API owners procedures

The token “LGTM” (looks good to me) turns up everywhere in Chromium’s review surfaces. A code-review LGTM on a Gerrit change clears it for the commit queue. An OWNERS LGTM is what the OWNERS file mechanism counts when a directory’s gate fires. The Intent to Ship gate uses the same four-letter token for an entirely different authority regime, and a contributor who treats the two regimes as one regime stalls at the gate without understanding why. The phrase “three-LGTM gate” is the project’s own shorthand for the rule that separates them.

What It Is

The gate is the terminal rule of the Intent to Ship pipeline: a Blink web-platform feature reaches Stable only after the Intent to Ship thread on blink-dev carries three replies, each from a current Blink API owner, each consisting of LGTM (sometimes with conditions or follow-up requirements attached). The number is fixed. The population is fixed. The instrument (a public reply on a public thread) is fixed. A feature that has the assent of two API owners and twenty engineers does not clear; a feature that has the assent of three API owners and no one else does. The gate counts the union of three API owners’ authority and nothing else.

The rule is enforced by social and procedural mechanisms rather than by automation. The Chrome Platform Status entry for the feature surfaces the Intent thread’s URL; a feature whose blink-dev thread lacks three API-owner LGTMs is not enabled by default at Stable, and a feature owner who attempts to ship one anyway is reverted and reviewed. The thread itself is the source of truth, with each LGTM reply timestamped, signed by the API owner’s chromium.org address, and archived publicly. The project’s docs/process/blink/intent_to_ship.md states the rule in its opening paragraph; the canonical Blink launch process documentation on chromium.org states it again. The rule has held with minor variations (occasional emergency variations during pandemic-era process compressions, occasional special-case relaxations for trivial bug-fix Intents) since the pipeline’s introduction in the mid-2010s.

What an API-owner LGTM warrants is not “the feature is well-implemented” or “the code passes tests.” Both of those are decided earlier, by OWNERS-file review and by the continuous-integration system. The API-owner LGTM warrants something different: that a senior cross-cutting reviewer has read the feature’s Explainer, considered its cross-cutting concerns (security, privacy, interoperability with other browsers, web-platform compatibility, developer ergonomics, alignment with the platform’s architectural direction), and decided that the proposal is suitable for general release on the Stable channel. Three independent API owners reaching that conclusion is what the gate measures.

The “three” is itself a deliberate calibration. One LGTM concentrates authority in a single individual and creates an obvious capture risk; two LGTMs is too easy to coordinate within a single sub-team; five would slow the pipeline beyond tolerance. Three independent senior reviewers each willing to put their name on the public record is the project’s empirical answer to the question of how much cross-cutting scrutiny a new web-platform surface needs before it reaches billions of installs. The number has held stable across pipeline revisions; the population eligible to issue the LGTMs has been adjusted over time.

Why It Matters

Naming the gate is what lets a new contributor read the Intent thread’s outcome and act on it rather than mistake one of its parts for the whole.

The most common misreading is conflating the gate with the LGTM token writ large. An engineer who has seen a feature merged after their tech lead’s LGTM on Gerrit and a teammate’s LGTM on the design doc reasonably assumes that an LGTM from a senior contributor on the Intent thread is equivalent. It isn’t. The Intent thread accepts LGTM replies from anyone, and those non-API-owner LGTMs are visible context but not gating votes. The gate counts replies whose author is on the current Blink API owner roster, and counts no others. A feature whose Intent thread shows six enthusiastic LGTMs from engineers across three Chromium-based products and zero from API owners has not cleared.

A second misreading conflates the gate with management approval. A feature team’s director can sign off on a feature in every internal meeting that exists; that approval doesn’t appear in the Intent thread, and even if it did it wouldn’t count. The gate is structurally insulated from the feature team’s organizational hierarchy by design: API owners are named individuals selected for cross-cutting authority across the project, and they do not report into the feature team’s management chain. A feature team that has cleared every internal stage can still find its Intent to Ship blocked because the API owners read the Explainer and saw something the team didn’t. That outcome is the gate doing what it was built to do.

A third misreading collapses the API-owner LGTM and the OWNERS LGTM into one regime. They aren’t. OWNERS governs the code-review interaction for a specific directory; API ownership governs the cross-cutting web-platform interaction for the whole Blink surface. A feature can have OWNERS LGTMs from every directory it touches and still lack API-owner LGTMs on its Intent thread. The two regimes coexist and don’t substitute for each other. OWNERS File Governance names the code-review regime in detail; the gate concept names the cross-cutting one.

For governance, the gate is the project’s primary mechanism for slowing the addition of permanent web-platform surface. Web-platform features that reach Stable accrete as commitments to compatibility under Web Platform Backward Compatibility; once a feature ships, removing it requires a deprecation process that’s substantially heavier than the addition was. The gate’s three-reviewer rule is the project’s empirical answer to that asymmetry: the addition machinery has to be heavier than the implementation team finds comfortable, because the removal machinery is heavier still.

For security review, the gate is the place the Untrusted Renderer Axiom gets enforced on new browser-side interfaces. An API owner reading a new Mojo interface in an Explainer asks, for each method, what an attacker-controlled renderer can do by varying the inputs. The answer often surfaces a missing browser-side check that the feature team didn’t read as a security gap. The gate’s effect is to push that question into the open thread, where the team’s response is on the public record and the API owners’ subsequent LGTMs (or refusals) are too.

For downstream Chromium-based products (Microsoft Edge, Brave, Opera, Vivaldi, Electron applications, WebView2 embedders), the gate is the warrant that a feature reaching Stable has been scrutinized by named reviewers at the upstream project. A downstream vendor’s release-engineering team can read the Intent thread, see which API owners approved, and use that record as evidence in their own ship/no-ship decision for the next downstream build. The gate is one of the few project-wide artifacts that a downstream consumer can audit directly.

For AI coding agents working on Chromium contributions, the gate names the bar that a generated patch has to clear before it ships, which is substantially higher than “the code compiles and the tests pass.” An agent that has the gate in context refuses to mark a Blink feature implementation complete on the basis of code-level signals alone and surfaces the missing Intent artifacts (Explainer, prototype trial, Origin Trial registration, Intent thread URL, named API owners likely to review) for the human contributor to handle.

How to Recognize It

The gate shows up at several recognizable points in the project’s public record.

In the blink-dev mailing-list archive, every Intent to Ship thread that reached Stable carries three replies of the form “LGTM (with conditions)” or “LGTM (looks good)” each signed by an @chromium.org address whose author is on the current Blink API owners roster. A reader who clicks the Intent thread linked from any feature’s chromestatus.com entry sees the same three-reply shape, scrolling past whatever discussion preceded it. Threads that didn’t clear are also visible in the archive, often with API-owner replies asking for changes (“could you extend the Origin Trial?” “please revise the Explainer to address X” “the security review on this isn’t complete; please cycle through it before re-requesting”).

In chromestatus.com, each feature page exposes the Intent to Ship thread URL and the feature’s current pipeline stage. A feature stuck before Stable on a thread that has only one or two API-owner LGTMs is in the most common pre-Stable state; a Stable feature that has cleared has three.

In docs/process/blink/intent_to_ship.md and the canonical “Launching Features” guide on chromium.org, the rule is stated directly. The wording has stayed close to “approval requires three LGTMs from API owners” across pipeline revisions.

In the API owners’ own internal coordination, the rule produces a recognizable artifact: the weekly API-owners meeting agenda is built around Intent threads awaiting review. The agenda and meeting notes are public; a reader who follows them for a quarter sees the gate operating in the open.

In the practical experience of feature teams, the gate produces a recognizable rhythm: an Intent to Ship lands; one or two API owners reply within a week; a third LGTM (or a follow-up question that prevents the third LGTM from landing) follows over the next one or two weeks; the feature ships at Stable in the next-but-one channel cycle. Teams that don’t see this rhythm in their thread are typically the teams whose feature is not yet ready for the gate.

How It Plays Out

A platform team has implemented a new Blink web-platform feature, run an Origin Trial that returned clean compatibility data, and posted an Intent to Ship. Two API owners reply with LGTM within five days. A third API owner (coincidentally an Igalia contributor whose authority comes from years of Blink web-platform work, not from a Google management chain) reads the Explainer in detail, notes that the feature’s interaction with an existing CSS API is underspecified, and asks for an Explainer revision before issuing an LGTM. The team revises the Explainer, posts the diff to the thread, and waits two weeks for the third LGTM to land. The feature ships at Stable one channel cycle later than the team had told their PM to expect. The Igalia reviewer’s authority over the team’s schedule isn’t management authority; it’s the gate’s authority, which the team’s management isn’t a party to.

A second team has merged a feature that the team’s director endorsed in every internal meeting. The team posts an Intent to Ship, and the thread accumulates a single API-owner LGTM in the first week. Over the next month the second and third LGTMs don’t land; one API owner has flagged a privacy concern that the team’s privacy review (run internally) had cleared. The director escalates inside Google, but the API owner in question doesn’t report into that director’s chain and the privacy concern doesn’t resolve through the escalation. The team revises the design to address the concern, posts an updated Explainer, and the LGTMs come in over the next two weeks. The director’s organizational authority did not move the gate; the design revision did.

A downstream vendor’s release engineering team is preparing the next build of their Chromium-based product. They read the Intent threads for the three highest-impact new features in the upstream Stable release. Each thread carries three API-owner LGTMs, each Explainer is linked, each Origin Trial summary is available. The release-engineering team copies the Intent-thread URLs and the API-owner names into their own ship readiness document so their internal reviewers can audit the upstream record before the downstream build. The gate’s public-record property is what makes the downstream audit possible.

Consequences

Holding the gate produces several operational properties for the project.

The pipeline’s pace is set by the gate’s throughput. API owners are a small fixed population; their attention is a constrained resource. When the rate of incoming Intent to Ship threads exceeds the API owners’ weekly review capacity, the pipeline backlogs. The project responds with rotation, with explicit prioritization, and occasionally with batched reviews; it does not respond by lowering the three-LGTM count.

The Intent thread becomes the authoritative public record for a feature’s pre-ship review. A feature whose Intent thread shows three carefully-considered LGTMs and an answered follow-up question is treated by downstream consumers as having a cleaner provenance than a feature whose thread shows three perfunctory LGTMs with no discussion. The gate counts the LGTMs; the thread’s quality is read by everyone downstream.

The composition of the API-owner population is what determines whose cross-cutting concerns get represented. Conway’s Law in Multi-Org Chromium applies here directly: the API owner roster has historically been dominated by Google engineers, with named representation from Microsoft Edge and Igalia. The cross-organizational composition is what gives the gate’s LGTMs their legitimacy for non-Google downstream consumers. A gate whose population had no non-Google members would warrant less; the project’s roster decisions are partly governance decisions about how much.

There are real costs. Feature teams routinely under-budget the time required to clear the gate, particularly when an API owner asks for a substantive revision and the team’s calendar slips by one or two channel cycles. New contributors find the gate’s three-LGTM rule harsher than the OWNERS-LGTM rule they’re used to from intra-directory code review, and the difference takes time to internalize. The gate also concentrates authority in a small population, which produces capture and consistency risks the project mitigates through rotation and through the public Intent-thread record but doesn’t fully eliminate.

The gate doesn’t guarantee good features; it guarantees scrutinized ones. A feature that clears with three LGTMs may still turn out to be a mistake; the gate puts the project’s reasoning on the public record so the mistake can be analyzed later, and the gate makes blocking concerns visible in public when the third LGTM doesn’t land.

Notes for Agent Context

An AI coding agent working on a Chromium contribution that adds a new Blink web-platform feature must never mark the feature complete on the basis of compile-clean code and passing tests. The agent must produce, alongside the code, the four Intent-pipeline artifacts the human contributor will need to clear the three-LGTM gate: a WICG or W3C Explainer URL (or a clear note that the Explainer needs to be drafted), the Intent to Prototype thread URL on blink-dev, the planned Origin Trial registration details, and the Intent to Ship thread URL once the team is ready to request approval. When asked to “ship” or “release” a Blink feature, the agent must surface that “ship” in Chromium means three API-owner LGTMs in a public Intent thread, not a CL landing in chromium/src. The agent must not propose to substitute internal Google approvals, team-lead LGTMs, OWNERS-file LGTMs from feature-team owners, or director sign-off for the API-owner LGTMs the gate requires; those approvals are necessary in their own regimes but they do not count toward the gate. When generating an Intent to Ship draft for human review, the agent must consult the Blink API owners procedures page (chromium.org/blink/guidelines/api-owners/procedures) and the ChromeStatus feature-creation form for the required Intent sections (Contact, Explainer, Specification, Summary, Risks, Compat Risk, Interop Risk, Gecko, WebKit, Web developers, Other signals, Compat, Privacy, Security, Performance, Ecosystem, Activation, Tracking bug, Estimated milestones, Anticipated spec changes, Link to entry on the Chrome Platform Status, Links to previous Intent discussions) and refuse to omit a section even when the team thinks it’s unnecessary; the API owners read every section, and a missing one is the most common reason a thread sits without a third LGTM.

Related Patterns

Sources

The gate’s canonical statement lives in the Blink API owners procedures page on chromium.org/blink/guidelines/api-owners/procedures, which sets the three-LGTM rule and names the population eligible to issue the LGTMs; the same rule is restated in the “Launching Features” guide on chromium.org/blink/launching-features/. The Blink API owners roster is the third_party/blink/API_OWNERS file in the Chromium source tree, and the criteria for joining the roster are documented at chromium.org/blink/blink-api-owners-requirements/. The principles API owners apply when evaluating an Intent live at chromium.org/blink/guidelines/web-platform-changes-guidelines/. The blink-dev mailing-list archive is the authoritative public record for every Intent to Ship thread the project has run since the pipeline’s introduction in the mid-2010s; the same data is mirrored into chromestatus.com’s per-feature pages, which expose the Intent threads, the API-owner LGTMs, and the feature’s current pipeline stage in a structured form. The historical context of the pipeline (why three LGTMs rather than one or five, when the rule was introduced, what variations the project has tried during pandemic-era process compressions) is captured in design documents and in retrospective posts on the Chrome engineering blog.

Technical Drill-Down

• Blink API owners procedures — the canonical statement of the three-LGTM rule and the procedural conventions API owners follow when issuing the LGTMs.
• third_party/blink/API_OWNERS (pinned 1f78222a) — the source-of-truth roster the gate counts; every LGTM-eligible email address is one line of this file.
• Blink API owner requirements — the criteria for joining the roster and the project’s standards for the API-owner role.
• Web-platform changes guidelines — the principles API owners apply when reading an Intent thread’s Explainer and deciding whether to grant an LGTM.
• Chromium project, “Launching Features” guide — the feature-team-facing walkthrough of the pipeline, with the gate as its terminal step.
• blink-dev mailing-list archive — search for “Intent to Ship” to see every cleared thread’s three-LGTM pattern and every blocked thread’s open questions.
• chromestatus.com — the per-feature surface that exposes the Intent thread URL and the feature’s pipeline stage; clear-cleared-or-blocked is visible at a glance.