Concepts
Every new feature on the web platform should have a ChromeStatus feature entry. Each entry is a central point of collaboration for feature owners, API owners, and the cross-functional teams that help make each feature successful. There are multiple types of feature entries to match the type of feature work being done. Each feature entry consists of metadata and process stages, each of which contain fields to be filled in with information about the feature. Feature owners work through the stages of their feature entry to eventually be ready to fully release their feature.
A few of the stages have review gates that must be approved before the stage is complete. Each review gate is owned by a team of reviewers that specialize in a certain topic area listed in the next section. The review process helps identify potential problems with the feature entry, and it also creates awareness of the feature needed for coordinated action on it later. Each review has its approval state, a survey question prompt, and a log of comments. When requesting a review, feature owners use comments to respond to the survey question prompt. Then, reviewers may post comments to ask for clarifications, or set their review response value.
| State | Description |
|---|---|
Preparing 
|
The feature owners are still preparing the feature entry fields for that stage and they have not requested a review yet. |
No review activity yet 
|
The reviewers have been notified that a review has been requested, but they have not responded yet. |
Review started 
|
The reviewers have looked at the review request but are not ready to give a detailed response yet. They may use comments to ask clarifying questions. |
Internal review 
|
The reviewers have indicated that this review should go through a Google-internal review process as consultation with other teams outside the Web Platform team may be needed. They should reach out to the feature owners with instructions. Once that internal process is done, the review could be set to "Approved". |
Needs work 
|
The reviewers have found some aspect of the feature entry that needs to be improved before approval can be granted. They should use comments to provide details to the feature owners, and the feature owners should respond via comments to answer questions or indicate that improvements have been made to the feature entry. |
N/A or Ack 
|
The review team believes that the feature work can proceed without their full review at this stage. This counts as approval. |
Approved 
|
The review team approves the feature entry at this stage. |
Denied 
|
This is rarely used because "Needs work" is usually used to ask the feature owner to make changes that could ultimately lead to approval. The "Denied" value indicates that the feature entry as currently written cannot be easily fixed, meaning that the feature owners should rethink their approach in consultation with the reviewers, possibly leading to a new feature entry. |
After cross-functional review gates have been approved, the feature owners should then request review by API Owners. Unlike cross-functional reviews that are conducted completely on ChromeStatus, the API Owners review also requires an "intent" thread on the blink-dev mailing list. ChromeStatus generates the subject line and body of the initial email message. Feature owners then copy and paste that into an actual email message and send it to the blink-dev mailing list.
To help prevent reviews from going unnoticed, ChromeStatus provides a SLO timer for the initial response to each review. The configured SLO limit is shown before the review is requested so that feature owners know the rough number of weekdays to allocate in their plans. On the reviewers' "My features" dashboard page, red clock icons are shown to draw attention to the overdue reviews. Any response from a reviewer satisfies the SLO, even a "Review started" or "Needs work" response. The time needed to earn approval depends on the feature and the discussion after the initial response, so it is not covered by the SLO timer.