Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Intent to Ship Pipeline

Pattern

A named solution to a recurring problem.

The staged public process by which a new Blink web-platform feature moves from idea to Stable Chrome, with required artifacts and named approvers at every gate.

A team that has finished implementing a feature isn’t the same thing as a team that’s about to ship it. In Chromium, those two states are separated by a sequence of public threads, an Explainer in a standards-track repository, an opt-in trial against real traffic, and three API-owner LGTM (looks-good-to-me) approvals drawn from a small cross-cutting reviewer population. The pipeline is what turns “the code is ready” into “the code reaches the open web.”

Context

Web-platform features in Chromium reach billions of installs across Chrome, the downstream forks, Electron applications, and WebView2 surfaces. A regression that lands in Stable affects every one of them, and the open-web ecosystem has no rollback channel beyond the next four-week stable cycle. The blink-dev mailing list, the Chrome Platform Status site (chromestatus.com), and the WICG repositories on GitHub are the public surfaces where features are proposed, debated, and tracked. A team building a new feature, whether inside Google or at Microsoft Edge or Igalia, operates inside this public record from the first Intent thread onward.

Problem

A feature owner has working code, a design document, and management support. The natural move is to merge it, flip a flag, and ship in the next stable channel. That move would expose readers, ad networks, accessibility tooling, password managers, and every embedded runtime to a feature that has not been seen by anyone outside the feature team. It would also produce a feature that no one at Microsoft Edge, Apple, Mozilla, or the W3C has had the chance to argue with, and that no site operator has had the chance to test against. The recurring problem is how a project that touches the entire web can ship novel surface without bypassing the scrutiny that prevents it from breaking the web.

Forces

  • Velocity vs. scrutiny. Feature teams want to ship. Reviewers, security engineers, and other browser vendors want time to read the proposal and react.
  • Specification quality vs. real-world fit. A feature can be specifiable but bad in practice, or pragmatic but unspecifiable. The pipeline has to surface both failure modes before Stable.
  • Public accountability vs. confidentiality. Most of the record has to be public so other vendors and standards bodies can engage; some details (security-sensitive ones) can’t be.
  • Reversibility vs. commitment. A feature that ships to Stable becomes part of the web’s permanent surface within months. Reversing it later costs more than catching the problem mid-pipeline.

Solution

The Chromium project requires every new Blink web-platform feature to traverse a six-stage public pipeline before it can reach Stable. Each stage produces a specific artifact, the artifact is reviewed by a specific population, and progression to the next stage is gated on that review. The stages, in order:

  1. Explainer. A design document in the Web Incubator Community Group (WICG) or W3C Technical Architecture Group (TAG) repository, written to the project’s standard Explainer template.
  2. Intent to Prototype. A thread on the blink-dev mailing list announcing that work is starting and inviting early feedback.
  3. Developer trial. A build that exposes the feature behind a flag for hands-on evaluation by other contributors.
  4. Origin Trial. A time-boxed registration through which real sites opt their origin into the feature, generating compatibility and usage data on production traffic.
  5. Intent to Ship. A thread on blink-dev requesting approval to enable the feature by default; clears only after three API-owner LGTM approvals land in the thread.
  6. Channel progression. Promotion through Canary, Dev, Beta, and finally Stable; the four channels add roughly twelve weeks of integration shake-out before broad release.

What makes the pipeline work is the asymmetry of authority at the gates. The Intent to Ship gate is held by API owners, a small cross-feature population whose authority is described in API Owner. The three required LGTM approvals come from this population, not from the feature team’s tech leads. The pipeline’s other gates rest on the same principle: each requires the assent of a population that is not the feature’s author. A team can’t self-approve.

How It Plays Out

A platform team at a downstream vendor is asked to evaluate a new Blink feature for their fork’s next release. They open the feature’s chromestatus.com entry, follow the link to the Intent to Ship thread on blink-dev, and find the three approving API-owner replies, the cited Origin Trial summary, and the WICG repository link to the Explainer. They can see the feature’s design rationale, the compatibility issues that surfaced during the trial, and which other vendor representatives engaged on the thread. The downstream team’s decision to enable the feature in their fork is informed by reading the same artifacts the Chromium project itself reviewed, in the same order.

A second team has merged what they consider a finished implementation and finds their Intent to Ship blocked. One API owner has asked for a specification revision; a second has asked for a longer Origin Trial because the existing run produced compatibility reports the team treated as edge cases. The team’s calendar slips by two stable cycles. Eight weeks later, with a revised specification and a longer trial behind them, the Intent to Ship clears with three LGTM approvals. The delay’s cost is concrete and measurable. The cost of having shipped the original version into Stable, against the blocking reviewers’ concerns, would have surfaced as a regression report from a major Electron application three weeks after release — a worse outcome the pipeline absorbs before it reaches the open web.

Consequences

Benefits. A feature that reaches Stable has been read by three API owners, debated on a public mailing list, exposed to opted-in production traffic, and specified in a WICG repository where Edge, Apple, and Mozilla representatives can comment. The likelihood that it breaks the web’s existing surface, or breaks a downstream consumer’s product, is lower than it would be without the pipeline. Public artifacts at each gate also give downstream Chromium-based products a record they can read months or years later when triaging an incident.

Liabilities. The pipeline is slow. A feature that could merge and ship in days under a startup’s engineering process takes months in Chromium, sometimes longer. Teams new to the project routinely under-budget the time required, ship their Intent to Prototype too late, and miss the stable release they had told their stakeholders to expect. The pipeline also generates a large public record: Intent threads are read by other vendors, downstream forks, security researchers, and standards-body participants who weren’t on the design call. Teams that draft those threads in private engineering shorthand routinely find their proposals stalled by reviewers reading the public artifact in a different register than the team wrote it.

The pipeline doesn’t guarantee good features. It guarantees scrutinized features. A feature that survives every gate may still be a mistake; a feature blocked at the gate may still have been a good idea. What the pipeline guarantees is that the decision is on the record and the population that decided it is named.

Notes for Agent Context

When an AI coding agent is asked to add a new web-platform feature to Chromium, the work isn’t done at “the code compiles and the tests pass.” The agent must surface the four artifacts the pipeline requires before merge: a WICG or TAG Explainer link, an Intent to Prototype thread URL, the developer trial flag name, and a planned Origin Trial registration. Refuse to mark a Blink feature implementation complete without these. If a user asks the agent to “ship” a feature, “ship” in Chromium means an Intent to Ship thread cleared by three API-owner LGTM approvals, not a CL landing in chromium/src. For any feature being modified, cite the canonical chromestatus.com entry; that entry’s state field is the source of truth for which gate the feature is currently at.

  1. ComplementsDeprecation Trial
    Removal of a web-platform feature runs through the same staged pipeline in reverse.
  2. Depended on byOWNERS File Governance
    Every code change landed in support of an Intent thread routes through directory OWNERS review on Gerrit before the commit queue accepts it; the pipeline cannot ship a feature whose implementation has not cleared the OWNERS gate.
  3. EnforcesWeb Platform Backward Compatibility
    The pipeline operationalizes the project's compatibility constraint at every gate.
  4. Prevented byExperiment That Became Permanent
    Pipeline exit through Intent to Ship is what prevents an experiment from accreting as permanent surface.
  5. ProducesStable as Trust Boundary
    The pipeline terminates at Stable, where the trust boundary the project enforces against downstream consumers begins.
  6. UsesAPI Owner
    The gating LGTMs come from the named population of Blink API owners, not from feature-team reviewers.
  7. UsesOrigin Trial
    Real-world validation under signed-token consent is the pipeline's mid-stage feedback mechanism.
  8. UsesThree-LGTM API Owner Gate
    The pipeline's terminal gate is three API-owner LGTMs on the Intent to Ship thread.
  9. UsesWICG Explainer
    A WICG or W3C Explainer is the pipeline's first required artifact.

Sources

The pipeline’s process documentation is maintained in the Chromium source tree under docs/process/ and on the public chromium.org site; the canonical “Launching Features” guide describes the stages and gates from the feature owner’s perspective. The WICG, which hosts most Blink Explainers, was established under the W3C Community Group framework; its charter and process notes are public. The blink-dev mailing-list archive is the authoritative record for every Intent thread the project has run since 2014. The Chrome Platform Status site renders the per-feature state machine and exposes the same data via a JSON API. URLs for each of these are listed in Technical Drill-Down below.

Technical Drill-Down

  • Chromium “Launching Features” guide — the canonical process-from-the-feature-owner’s-perspective document; the stage definitions in this article match this guide’s vocabulary.
  • chromestatus.com — the per-feature state-machine surface; each feature page links its Intent threads, Explainer, and Origin Trial registration.
  • blink-dev archive — the public mailing-list record; search for “Intent to Ship” to see active threads and their LGTM patterns.
  • Web Incubator Community Group (WICG) — the community-group home for most pre-standardization Explainers; charter and operating model are linked from the front page.
  • Origin Trials developer documentation — the site-operator’s view of registering an origin into a trial; the pipeline’s mid-stage feedback mechanism.