Web Platform Changes: Process

Launch Process: removing a feature (or making other breaking changes)

API Owners

Here's the current list of API OWNERS.

All members of the project are responsible for enforcing that new features follow the project’s policies. Project members who feel that a feature is violating the policy should raise the issue first with the contributor and, if that doesn’t resolve the issue, with the project’s public mailing list.

To complement this project-wide responsibility, we have a set of API owners who are listed in the OWNERS file for the expected output of tests that monitor much of the web-exposed surface area of blink (eg. these). When reviewing changes to these files, the API owners should ensure that the changes meet the project’s guidelines for new and removed features.

API Review

API Review meetings will be scheduled when API discussion over email is insufficient (per the Launch Process). API owners and contributors of features under discussion are welcome to attend. The purpose of the API Review meeting is to provide a high-bandwidth forum for discussion between API owners and feature implementers. The group makes decisions by consensus; at least three project OWNERS must be present for quorum. After the meeting the organizer will send notes, including any decisions, to blink-dev@.

Feature Dashboard

To improve transparency, we track development of new features on our Feature Dashboard. For each feature, the dashboard tracks our implementation status, the feature's progress through the standards process, our understanding of the opinion of other browser vendors and other key metrics.

We associate each value with a shade of red or green, corresponding to how the value reflects our web citizenship. For example, “opposition from another browser vendor” is red and “a similar implementation in another browser” is green. Viewed in aggregate, these colors provide a quick snapshot of the project’s overall web citizenship.

The dashboard data itself is also a useful high-level record of when features were implemented and a peek at what’s coming next. If you’d like to monitor lower-level changes as they happen, check out our Gitiles and SVN logs.

Guiding Principles for Process

  • Minimize interoperability and compatibility risk for released features.
  • Minimize process burden once a change has been LGTM-ed by API owners.
  • Minimize ambiguity.
  • Block bad engineering investments upfront.
  • Block incomplete features from being runtime-enabled.
  • Create an audit trail, not necessarily a single approval funnel for all changes.
  • Prefer email over meetings.
Comments