Omnibox Bug Triage Process

last update: 2020/04/16

The current triage process owner is jdonnelly@.

Instructions for Chrome omnibox engineers serving an assigned bug triage rotation.

Goal of the process

Every omnibox bug is triaged, preferably within a week of being filed. This means making the issue clear, marking it as a dup if necessary, revising the status, setting a priority, labeling/categorizing as appropriate (or handing off to another component), and (possibly) assigning an owner. The only reason bugs should remain untriaged (i.e., status=Unconfirmed or status=Untriaged) is because of they need additional information from someone. These bugs should be labeled as such (Needs=Feedback, Needs=Investigation, or Needs=TestConfirmation).

Non-goals

• Ensure high priority bugs or regressions are making progress / ping bug owners for progress updates on other important bugs. (Trust your teammates to work on assigned bugs.)

Process

• Every Monday, Wednesday and Friday, the triage engineer looks over all Unconfirmed and Untriaged omnibox bugs (without Needs=Feedback) and triages them.
• Every week on Tuesday, the triage engineer looks over all Unconfirmed and Untriaged bugs filed that aren’t categorized as omnibox yet have relevant terms to see if any should be moved to the omnibox component and triaged. (This scan can be limited to those filed in the last week, i.e., since the last check.)
• Every week on Tuesday, the triage engineer should also look over all bugs with Needs=Feedback and should take action on those that have been sitting for too long.
  • If there‘s been no feedback over a week since the label was added, ping the reporter (or whoever’s being asked for feedback) and politely ask them to provide feedback.
  • If there's been no feedback for over a week since the last ping, and no one can reproduce the issue, close it as WontFix.
• Every week on Thursday, the triage engineer looks over all alerts sent to chrome-omnibox-team-alerts@ and, for each, either files a bug or replies to the message indicating why filing a bug is not appropriate. These bugs should be set to “Untriaged”, so that the current triage engineer sees them, until a root cause has been identified and an owner assigned (or closed.) More details available below.

Other team members are welcome to triage a bug if they see it before the the triage engineer. The triager owner will cycle among team members by arrangement.

How to triage chromium bugs

Purpose

The purpose of labels, components, and priority are to make it easy for omnibox team members to identify bugs at a glance that affect a particular area. In other words, this bug management process is intended to make the team more efficient and provide better visibility for team members to identify what’s important to work on in particular areas.

Identifying the issue

If the bug isn’t clear, or the desired outcome is unclear, please apply the label Needs-Feedback and courteously ask for clarification. This is appropriate both for external bug filers, Chromium developers on other teams, or Googlers. The label is merely an indication that this bug needs information from someone outside the team in order to make progress. It’s also an indication that someone on the team needs to follow-up if feedback is not forthcoming.

Often the appropriate request includes a request for chrome://omnibox data; an example such request is below.

Also, if the bug is clear, try to reproduce. If it cannot be reproduced or you lack the necessary setup, either ask the reporter for clarification or add the label Needs-TestConfirmation as appropriate.

Some bugs are feature requests. Marks these as Feature, not Bug. It’s likely a feature may have been requested before. Search the bugs database and dup appropriately.

Some commonly requested features and commonly reported bugs are listed below.

Status

Set the Status field to the following value depending on the triage action taken:

• Available: The typical state for bugs exiting the triage process, assuming none of the other states below apply.
• Assigned: Available bugs with Owners; see section on assigning owners.
• ExternalDependency: Bugs that turn out to be in another project‘s code and you’ve contacted that other project. Typically this is problems with Google-sourced suggestions, an IME, or a Chrome extension. In all cases, file a bug or contact the appropriate team and post information about this outreach (e.g., a bug number) in a comment on the Chromium bug.
• Duplicate: This issue has been reported in another bug or shares the same root cause as another bug and will certainly be fixed simultaneously.
• WontFix: Anything working by design. Also applies to old non-reproducible bugs or bugs lacking feedback per standard Chromium policies.
• Unconfirmed or Untriaged: These labels are generally only appropriate if you labeled the bug with Needs-Feedback or Needs-TestConfirmation, otherwise in effect you're kicking the can down the road to the next triage engineer.

Priority

Follow standard Chromium policies. Priority-2 represents wanted for this release but can be punted for a release. Priority-3 are bugs not time sensitive. There is an even-lower-priority state; see the NextAction=01/07/2020 below.

If you aren't sure of the scope, severity, or implications of an issue, prefer to assign it a higher priority (1 or 2) and try to assign it to someone appropriate to look into further or at least identify the scope / true priority. If you cannot identify a person to assign it to, it would be better to leave it Untriaged for the next triage engineer than mark it Available just to try to clear the queue.

Owners

Generally only assign someone else to own a bug if the bug is Priority-2 or better. Priority-3 bugs are not likely to be completed soon; for these bugs, don’t assign an owner to merely sit on the bug. To draw someone’s attention to a bug, explicitly CC them.

Categorization

Omnibox bugs use a combination of labels (including hotlists) and subcomponents to indicate their topic.

Most omnibox bugs should be in the main omnibox component. A few will fall directly into a subcomponent instead; the available subcomponents are listed below.

Add all the labels, components, and next actions dates that seem appropriate to the issue. The main ones encountered by omnibox issues are listed below; feel free to use additional suitable ones as well.

The main labels that apply to bugs include:

The components that additionally apply to bugs include:

The subcomponents of omnibox bugs include:

If the bug is extremely low priority, set the NextAction field to 01/07/2021 and mention that we will “reassess” the bug next year. This NextAction field is for Priority-3 bugs that are somehow less important than other priority-3 bugs. These are bugs we’re sure no one on the team intends to fix this year (e.g., really unimportant, or mostly unimportant and hard to fix). This label should be applied only when confident the whole team will agree with you. When searching the bugs database for things to do, I suggest excluding bugs on this hotlist.)

How to triage alerts

Every message sent to chrome-omnibox-team-alerts@ should be evaluated by a triage engineer. The triage engineer should either

• file a Chromium bug to investigate the issue further and reply to the alert with a link to the Chromium bug, or
• reply to the alert explaining that the alert is already being tracked, and link to the appropriate Chromium bug, or
• reply to the alert explaining why ignoring the alert is appropriate. This is only appropriate if the engineer believes the alert is incorrect or spurious.

Tip: Alerts on Beta and Stable that happen at the time of a new version release will often have triggered an alert on Dev. Look for those Dev alerts. Most likely they already have associated bugs. If the Beta/Stable change is the same scale at the Dev change, it's likely the same issue--you should simply point the Beta/Stable alert thread to the existing bug thread.

With this process, when the next triage engineer begins their triage rotation, they'll be able to see which alerts have been handled and which have not. All alerts that have been handled will have a reply from a triage engineer. All alerts that have not been looked at will not.

Sometimes multiple alerts will be fired at around the same time, on the same channel, on related histograms. All of these alerts can be filed as part of the same bug if the triage engineer thinks they're likely all related (as they likely are). All these alerts should be mentioned in the bug and all the separate alert threads should be replied to pointing to that bug.

When filing the bug about an alert:

• Leave it Untriaged. You should investigate it during your triage shift; if you don't identify a root cause, the next triager will see the bug and try. Only assign an owner if the likely root cause has been determined!
• Add the Restrict-View-Google label so metrics can be discussed without fear of leaking sensitive information.
• Link to the alert message.
• Set a priority. Generally these bugs should be Priority-1 or Priority-2.
• Tag it with a milestone (if appropriate).
• Likely, label it with either Performance-Browser or Hotlist-OmniboxRanking. (Probably one of those is appropriate.)

Investigating an Alert

The timeline dashboard is your friend, especially the split by channel, split by platform, split by milestone, and split by version features. Some tips on how to investigate using the timeline dashboard:

• If the regression is on Dev, see if you can spot it on Canary. That can usually indicate a narrow regression range. This can usually be done unless the histogram is too noisy.
• What platforms did the regression happen on? That might narrow down the area of relevant code.
• Did the regression happen on multiple channels at the same time? If so, then it's either caused by a change that was submitted and quickly merged to multiple channels or it may be caused by something external to Chrome (such as a major holiday or significant weather events, which can change omnibox behavior).

Action: The best way to verify that a particular changelist caused a regression is to revert the changelist and see if the metrics improve. This is a better strategy than landing a fix directly. If the “fix” doesn‘t make the metric recover to the exact same degree as the regression, it’s unclear whether the fix was related to the regression, only a partial solution, and whether there's still another issue.

FYI: the alerting system does not alert on ChromeOS changes because the vast majority of alerts that trigger on ChromeOS are due to school schedules (e.g., summer and winter vacation). For the year prior to disabling ChromeOS alerts, we did not see a real ChromeOS alert that wasn‘t also fired on Windows. (I.e., all real regressions on ChromeOS were also regressions on Windows; Views platforms tend to regress simultaneously.) Thus, we seemingly don’t get any additional value from ChromeOS alerts.

Appendix

Example request for chrome://omnibox data

NOTE: If you ask someone for chrome://omnibox data on a public bug, label the bug with Restrict-View-Google so that any personal data from the reporter's chrome://omnibox output is not made public. Do this before they respond. As the original reporter, they should still have access to the bug even with the restrict applied.

Example request:

Please visit chrome://omnibox in the version of Chrome in which you're experiencing the issue and type the input that triggers the issue into the “Enter omnibox input” text box. Then click the Download link and attach the downloaded file to this issue.

Please be aware that this data may reveal details of your browsing history so only attach the file if you're comfortable sharing that data with the omnibox team. I have added the Restrict-View-Google label to this issue so that it is not visible to the public.

Commonly referenced bugs

• “I want the option to turn off inline autocomplete.” Dup against crbug/91378.

  • Try to understand the motivation of the user making the request. Please ask the user for examples, with chrome://omnibox detail (see above), of times where the omnibox doesn’t do what they want. Ideally we should be able make to make the omnibox smart enough that such a feature isn’t necessary.

• “I want to disable suggestions from appearing entirely”. Dup against crbug/1470391

  • Try to understand the motivation of the user making the request. Consider quoting from pkasting’s comment on this bug.

• “I typed in something like go/foo and got redirected to a search results page instead.” See this internal page. Follow the guidelines there; generally ask about a message about profile corruption. If so, the bug can be dupped against crbug/665253

  • … and no “Did you mean?” infobar appears. This is likely prerendering; see crbug/247848

References

General Chromium bug triage guidelines

Omnibox bugs that we intend/hope to tackle this year, broken down:

• User-facing (everything not tagged as one of the non-user-facing categories below). Some of these can be further categorized: Performance, Polish, Enterprise, Answers in Suggest, Tab To Search, Zero Suggest.

• Non user-facing, divided into these categories:

  • Code health

  • Refactoring

  • Testing