| asanka | ddd5dc2 | 2015-03-20 15:52:40 | [diff] [blame] | 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. |
| 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 when |
| 37 | new crashers are found. |
| 38 | |
| 39 | * Identify new network bugs, both on the bug tracker and on the crash server. |
| 40 | All Unconfirmed issues filed during your triage rotation should be scanned, |
| 41 | and, for suspected network bugs, a network label assigned. A triager is |
| 42 | responsible for looking at bugs reported from noon PST / 3:00 pm EST of the |
| 43 | last day of the previous triager's rotation until the same time on the last |
| 44 | day of their rotation. |
| 45 | |
| 46 | * Investigate each recent (new comment within the past week or so) |
| 47 | Cr-Internals-Network issue, driving getting information from reporters as |
| 48 | needed, until you can do one of the following: |
| 49 | |
| 50 | * Mark it as *WontFix* (working as intended, obsolete issue) or a |
| 51 | duplicate. |
| 52 | |
| 53 | * Mark it as a feature request. |
| 54 | |
| 55 | * Remove the Cr-Internals-Network label, replacing it with at least one |
| 56 | more specific network label or non-network label. Promptly adding |
| 57 | non-network labels when appropriate is important to get new bugs in front |
| 58 | of someone familiar with the relevant code, and to remove them from the |
| 59 | next triager's radar. Because of the way the bug report wizard works, a |
| 60 | lot of bugs incorrectly end up with the network label. |
| 61 | |
| 62 | * The issue is assigned to an appropriate owner. |
| 63 | |
| 64 | * If there is no more specific label for a bug, it should be investigated |
| 65 | until we have a good understanding of the cause of the problem, and some |
| 66 | idea how it should be fixed, at which point its status should be set to |
| 67 | Available. Future triagers should ignore bugs with this status, unless |
| 68 | investigating stale bugs. |
| 69 | |
| 70 | * Monitor UMA histograms and gasper alerts. |
| 71 | |
| 72 | * For each Gasper alert that fires, the triager should determine if the |
| 73 | alert is real (not due to noise), and file a bug with the appropriate |
| 74 | label if so. Note that if no label more specific than |
| 75 | Cr-Internals-Network is appropriate, the responsibility remains with the |
| 76 | triager to continue investigating the bug, as above. |
| 77 | |
| 78 | ### Best Effort (As you have time): |
| 79 | |
| 80 | * Investigate unowned and owned but forgotten net/ crashers that are still |
| 81 | occurring (As indicated by |
| 82 | [go/chromecrash](https://goto.google.com/chromecrash)), prioritizing frequent |
| 83 | and long standing crashers. |
| 84 | |
| 85 | * Investigate old bugs, prioritizing the most recent. |
| 86 | |
| 87 | * Close obsolete bugs. |
| 88 | |
| 89 | If you've investigated an issue (in code you don't normally work on) to an |
| 90 | extent that you know how to fix it, and the fix is simple, feel free to take |
| 91 | ownership of the issue and create a patch while on triage duty, but other tasks |
| 92 | should take priority. |
| 93 | |
| 94 | See [bug-triage-suggested-workflow.md](bug-triage-suggested-workflow.md) for |
| 95 | suggested workflows. |
| 96 | |
| 97 | See [bug-triage-labels.md](bug-triage-labels.md) for labeling tips for network |
| 98 | and non-network bugs. |
