the Chromium logo

The Chromium Projects

Triaging Bugs

You don’t have to be a programmer to contribute to the Chromium project. There are always new bugs coming in, and those bugs need to be clarified, confirmed, and routed to the right people before process of getting them fixed can even begin. If you are interested in helping with this important part of the project, here are a few ways you can get started. Everything listed here except the parts in italics and the "Categorizing bugs" section is something anyone can jump in and start doing. Once you have been triaging for a while, you may want to consider getting permissions to edit bugs so that you can do even more.

Finding duplicates

Many of the bugs that are filed are duplicates of existing bugs. Look through the unconfirmed bugs for any that are already filed.

The more you triage bugs, the more duplicates you will recognize immediately. If you suspect something might be a duplicate but aren’t sure (such as with a feature request that seems likely to have been made before), search for as many of the variants of the key words in the bug as you can think of. Be sure to search “All issues”, not the default of “Open issues” so that you can find WontFixed bugs and other duplicates.

Clarifying and/or reproducing bugs

Knowing how to reproduce a bug is the first step toward fixing it. The bug template encourages people to provide steps to reproduce a bug, but sometimes the steps are missing, unclear, or just don’t work for everyone. Note that if something is clearly a feature request, rather than a bug report, you should skip this step.

Look through the unconfirmed bugs for reports that nobody has tried to reproduce.

Cleaning up old bugs

While it’s most important to get new bugs triaged, as they are most likely to be relevant, there are also a number of old bugs that nobody has had time to follow up on. It can be helpful to go through old unconfirmed bugs to weed out the ones that aren’t relevant any more. All the advice above applies, but there are a few extra things to consider with old bugs:

Creating reduced test cases

For bugs that are about compatibility with specific sites, creating a reduced test case is extremely helpful. If you are familiar with HTML, CSS, and/or Javascript, this is a great way to use your skills to help improve Chromium.

Look through the Compat bugs for issues that haven’t already been tracked down to a specific problem—the Needs-Reduction label is helpful in finding these, but it doesn’t always get added. Once you can reproduce a problem, try to isolate exactly what in the HTML/CSS/JavaScript/etc. is responsible for the failure.

Categorizing bugs

Once you can edit bugs, giving bugs the correct labels helps them move through the triage process faster. There are a lot of labels, here are the most important for incoming bugs:

Most of the remaining labels are very specialized, and it’s best not to use them unless you know otherwise. Never add or change ReleaseBlock-* or Milestone-* labels.