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