last update: 2018/06/11
The current triage process owner is mpearson@.
Instructions for Chrome omnibox engineers serving an assigned bug triage rotation.
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 or Needs=TestConfirmation).
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.
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.
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.
Set the Status field to the following value depending on the triage action taken:
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.
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.
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:
| Label | Description |
|---|---|
| Hotlist-OmniboxFocus | Bugs about focus, including not having focus when it should, focussing on the wrong end of the URL, etc. (Note: label does not appear in the Hotlist completion dropdown.) |
| Hotlist-OmniboxKeyboardShortcuts | Bugs related to handling of keyboard shortcuts, including both incorrectly handling real omnibox shortcuts and preventing other Chrome shortcuts from working when focus is in the omnibox. (Note: label does not appear in the Hotlist completion dropdown.) |
| Hotlist-OmniboxRanking | Bugs related to which suggestions are considered matches against the input and how relevance scores are assigned. (Note: label does not appear in the Hotlist completion dropdown.) |
| Hotlist-CodeHealth | Bugs about the making the code base easy to work with such as quality of comments. Refactoring efforts can also be included when for that purpose. |
| Hotlist-Polish | Bugs about how a feature looks and feels: not whether the feature works or not; instead, more of whether it appears the feature was created with attention to detail. Often user-visible edge cases fit in this category. |
| Hotlist-Refactoring | Bugs related to restructuring existing code without changing its behavior. |
| Performance-Browser | Bugs that affect performance. |
The components that additionally apply to bugs include:
| Component | Description |
|---|---|
| Enterprise | Bugs that mainly affect enterprise environments: enterprise policies, intranet handling, etc. |
| Tests>{Disabled,Failed,Missing,Flaky} | Bugs related to failing tests or lack of test coverage. |
| UI>Browser>Search | Bugs related to web search in general whose effects aren’t limited to the omnibox. |
The subcomponents of omnibox bugs include:
| Subcomponent | Description |
|---|---|
| UI>Browser>Omnibox>AiS | Answers in Suggest. |
| UI>Browser>Omnibox>DocumentSuggest | Documents provided by Google Drive |
| UI>Browser>Omnibox>SecurityIndicators | Secure/insecure icons; triaged by another team. |
| UI>Browser>Omnibox>TabToSearch | Custom search engines, omnibox extensions, etc. (including adding, triggering, ranking, etc. for them). |
| UI>Browser>Omnibox>ZeroSuggest | Suggestions displayed on omnibox focus (both contextual and non-contextual). |
If the bug is extremely low priority, set the NextAction field to 01/07/2020 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.)
Every message sent to chrome-omnibox-team-alerts@ should be evaluated by a triage engineer. The triage engineer should either
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:
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:
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.
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 submit chrome://omnibox output for “___”. Check both the “show all details” and “show results per provider” boxes. This will help us figure out what's going on.
Feel free to paste the results in here unformatted; we’ll be able to decipher them.
“I want the option to turn off inline autocomplete.” Dup against crbug/91378.
“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
“I want to disable suggestions from appearing entirely”. Try to find out why. Quote freely from pkasting’s comment on this bug.
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: