the Chromium logo

The Chromium Projects

Triaging Downloads Bugs

Downloads bugs are automatically cc'd to the mailing list download-bugs@chromium.org. People on the bugs rotation should subscribe to that list. The suggested frequency for handling incoming bugs is 2-3 days, but that's just a suggestion.

Triagers should

  1. Attempt to reproduce and set the correct Status for untriaged and unconfirmed bugs. (That search ignores Needs-Feedback and External bugs.)
    • Engage with users as they report bugs to get all the information we need for eventual resolution.
    • Set Type-Feature Available for feature requests or mark WontFix and explain why this feature is unlikely to be implemented.
    • Crash reports frequently do not contain crash ids. Send reporters to Reporting a Crash Bug and set Needs-Feedback.
    • Providing Network Details for bug reports
    • Ensure high priority bugs receive appropriate attention. Consult benjhayden or asanka if necessary in order to ensure timely resolution. High priority bugs include
      • Regressions: Mark as Type-Bug-Regression Pri-1
      • Possible security problems: Request security review and lock down (Restrict-View-Commit). If security review shows severity medium or higher, mark Pri-1
      • Crashers: Mark as Pri-1 if it's on the top crash list or looks likely to happen in the wild. If it looks like a use-after-free that might be reproducible in the wild, it's a security issue.
        • chromecrash query: fiddle with the literal 0 to find crashes before/after/at a specific branch.
      • Badly broken features
      • Failing or disabled tests
    • Mark duplicates as such. Frequently duplicated bugs
      • Some issues on windows are due to bad shell extensions. Point reporters to ShellMenuView
  2. Categorize uncategorized bugs by adding them to the "Blocked on" list of one of these category bugs.
  3. Sweep needs=feedback: if feedback has been provided, remove needs-feedback and continue debugging; if feedback has not been provided after 2 weeks, Archive the bug.
  4. When major changes such as file moves happen, either update the below documentation or delete it if nobody has found it useful.

FAQ, Bug-hunting tips

Where to begin fixing different kinds of bugs. Please feel free extend this liberally.