Chromium Code Reviews Chromium Code Reviews
Issue 1017743002:
[net] Convert bug triage documents to Markdown. (Closed)
Base URL: https://chromium.googlesource.com/chromium/src.git@master| OLD | NEW |
|---|---|
| (Empty) | |
| 1 # Chrome Network Bug Triage | |
| 2 | |
| 3 The Chrome network team uses a two day bug triage rotation. The main goals are | |
| 4 to identify and label new network bugs, and investigate network bugs when no | |
| 5 label seems suitable. | |
| 6 | |
| 7 ## Responsibilities | |
| 8 | |
| 9 ### Required: | |
| 10 * Identify new crashers | |
| 11 * Identify new network issues. | |
| 12 * Request data about recent `Cr-Internals-Network` issue. | |
|
Randy Smith (Not in Mondays)
2015/03/17 19:49:57
nit, suggestion: I'm not sure what to do about thi
asanka
2015/03/17 22:23:13
Yeah. I removed the backticks.
| |
| 13 * Investigate each recent `Cr-Internals-Network` issue. | |
| 14 * Monitor UMA histograms and gasper alerts. | |
| 15 | |
| 16 ### Best effort: | |
| 17 * Investigate unowned and owned-but-forgotten net/ crashers | |
| 18 * Investigate old bugs | |
| 19 * Close obsolete bugs. | |
| 20 | |
| 21 All of the above is to be done on each rotation. These responsibilities should | |
| 22 be tracked, and anything left undone at the end of a rotation should be handed | |
| 23 off to the next triager. The downside to passing along bug investigations like | |
| 24 this is each new triager has to get back up to speed on bugs the previous | |
| 25 triager was investigating. The upside is that triagers don't get stuck | |
| 26 investigating issues after their time after their rotation, and it results in a | |
| 27 uniform, predictable two day commitment for all triagers. | |
| 28 | |
| 29 ## Details | |
| 30 | |
| 31 ### Required: | |
| 32 | |
| 33 * Identify new crashers that are potentially network related. You should check | |
| 34 the most recent canary, the previous canary (if the most recent less than a | |
| 35 day old), and any of dev/beta/stable that were released in the last couple of | |
| 36 days, for each platform. File `Cr-Internals-Network` bugs on the tracker | |
| 37 when new crashers are found. | |
| 38 * Identify new network bugs, both on the bug tracker and on the crash server. | |
| 39 All Unconfirmed issues filed during your triage rotation should be scanned, | |
| 40 and, for suspected network bugs, a network label assigned. A triager is | |
| 41 responsible for looking at bugs reported from noon PST / 3:00 pm EST of the | |
| 42 last day of the previous triager's rotation until the same time on the last | |
| 43 day of their rotation. | |
| 44 * Investigate each recent (New comment within the past week or so) | |
| 45 `Cr-Internals-Network` issue, driving getting information from reporters as | |
| 46 needed, until you can do one of the following: | |
| 47 * Mark it as `WontFix` (working as intended, obsolete issue) or a duplicate. | |
|
Randy Smith (Not in Mondays)
2015/03/17 19:49:57
This doesn't result in an indented list in the HTM
asanka
2015/03/17 22:23:13
Added another level of indentation. That seems to
| |
| 48 * Mark it as a feature request. | |
| 49 * Remove the `Cr-Internals-Network` label, replacing it with at least one | |
| 50 more specific network label or non-network label. Promptly adding | |
| 51 non-network labels when appropriate is important to get new bugs in front | |
| 52 of someone familiar with the relevant code, and to remove them from the | |
| 53 next triager's radar. Because of the way the bug report wizard works, a | |
| 54 lot of bugs incorrectly end up with the network label. | |
| 55 * The issue is assigned to an appropriate owner. | |
| 56 * If there is no more specific label for a bug, it should be investigated | |
| 57 until we have a good understanding of the cause of the problem, and some | |
| 58 idea how it should be fixed, at which point its status should be set to | |
| 59 Available. Future triagers should ignore bugs with this status, unless | |
| 60 investigating stale bugs. | |
| 61 * Monitor UMA histograms and gasper alerts. | |
| 62 * For each Gasper alert that fires, the triager should determine if the alert | |
| 63 is real (not due to noise), and file a bug with the appropriate label if | |
| 64 so. Note that if no label more specific than `Cr-Internals-Network` is | |
| 65 appropriate, the responsibility remains with the triager to continue | |
| 66 investigating the bug, as above. | |
| 67 | |
| 68 ### Best Effort (As you have time): | |
| 69 * Investigate unowned and owned but forgotten net/ crashers that are still | |
| 70 occurring (As indicated by | |
| 71 [go/chromecrash](https://goto.google.com/chromecrash)), prioritizing frequent | |
| 72 and long standing crashers. | |
| 73 * Investigate old bugs, prioritizing the most recent. | |
| 74 * Close obsolete bugs. | |
| 75 | |
| 76 If you've investigated an issue (in code you don't normally work on) to an | |
| 77 extent that you know how to fix it, and the fix is simple, feel free to take | |
| 78 ownership of the issue and create a patch while on triage duty, but other tasks | |
| 79 should take priority. | |
| 80 | |
| 81 See [bug-triage-suggested-workflow.md](bug-triage-suggested-workflow.md) for | |
| 82 suggested workflows. | |
| 83 | |
| 84 See [bug-triage-labels.md](bug-triage-labels.md) for labeling tips for network | |
| 85 and non-network bugs. | |
| OLD | NEW |
