are automatically cc'd to the mailing list email@example.com. 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.
- Attempt to reproduce and set the correct Status for untriaged and unconfirmed bugs. (That search ignores Needs-Feedback and External bugs.)
Categorize uncategorized bugs by adding them to the "Blocked on" list of one of these category bugs.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.
- 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