Update from https://crrev.com/311076

net/docs/bug-triage.txt

+The Chrome network team uses a two day bug triage rotation.  The main goals are
+to identify and label new network bugs, and investigate network bugs when no
+label seems suitable.
+
+Responsibilities
+
+To be done on each rotation.  These responsibilities should be tracked, and
+anything left undone at the end of a rotation should be handed off to the next
+triager.  The downside to passing along bug investigations like this is each new
+triager has to get back up to speed on bugs the previous triager was
+investigating.  The upside is that triagers don't get stuck investigating issues
+after their time after their rotation, and it results in a uniform, predictable
+two day commitment for all triagers.
+
+Primary Responsibilities:
+* Identify new crashers that are potentially network related.  You should check
+    the most recent canary, the previous canary (if the most recent less than a
+    day old), and any of dev/beta/stable that were released in the last couple
+    of days, for each platform.  File Cr-Internals-Network bugs on the tracker
+    when new crashers are found.
+* Identify new network bugs, both on the bug tracker and on the crash server.
+    All Unconfirmed issues filed during your triage rotation should be scanned,
+    and, for suspected network bugs, a network label assigned.  A triager is
+    responsible for looking at bugs reported from noon PST / 3:00 pm EST of the
+    last day of the previous triager's rotation until the same time on the last
+    day of his rotation.  
+* Request data about recent unassigned Cr-Internals-Network bugs from reporters.
+    "Recent" means issues updated in the past week or so.
+* Investigate each recent (New comment within the past week or so)
+    Cr-Internals-Network issue until you can do one of the following:
+  * Mark it as WontFix (working as intended, obsolete issue) or a duplicate.
+  * Mark it as a feature request.
+  * Remove the Cr-Internals-Network label, replacing it with at least one more
+    specific network label or non-network label.  Promptly adding non-network
+    labels when appropriate is important to get new bugs in front of someone
+    familiar with the relevant code, and to remove them from the next triager's
+    radar.  Because of the way the bug report wizard works, a lot of bugs
+    incorrectly end up with the network label.
+  * The issue is assigned to an appropriate owner.
+  * If there is no more specific label for a bug, it should be investigated
+    until we have a good understanding of the cause of the problem, and some
+    idea how it should be fixed, at which point its status should be set to
+    Available.  Future triagers should ignore bugs with this status, unless
+    investigating stale bugs.
+* Monitor UMA histograms and gasper alerts.
+    TODO (mmenke):  Add a suggested workflow.
+
+Best Effort (As you time):
+* Investigate unowned and owned but forgotten net/ crashers that are still
+    occurring (As indicated by go/chromecrash), prioritizing frequent and long
+    standing crashers.
+* Investigate old bugs, prioritizing the most recent.
+* Close obsolete bugs.
+
+If you've investigated an issue (in code you don't normally work on) to an
+extent that you know how to fix it, and the fix is simple, feel free to take
+ownership of the issue and create a patch while on triage duty, but other tasks
+should take priority.
+
+See bug-triage-suggested-workflow.txt for suggested workflows.
+See bug-triage-labels.txt for labeling tips for network and non-network bugs.