Update net triage instructions.

net/docs/bug-triage.md

Index: net/docs/bug-triage.md
diff --git a/net/docs/bug-triage.md b/net/docs/bug-triage.md
index 8a03d85f0347b9b0cfb4026806cd0a8bd93c8d12..ac3240338f4498cdd58964ed08bca333d7a87f16 100644
--- a/net/docs/bug-triage.md
+++ b/net/docs/bug-triage.md
@@ -6,16 +6,16 @@ label seems suitable.
 
 ## Responsibilities
 
-### Required:
-* Identify new crashers
-* Identify new network issues.
-* Request data about recent Internals>Network issue.
-* Investigate each recent Internals>Network issue.
-* Monitor UMA histograms and Chirp/Gasper alerts.
+### Required, in rough order of priority:
+* Identify new network bugs on the tracker.
+* Investigate UMA notifications.
+* Investigate recent Internals>Network issues with no subcomponent.
+* Follow up on Needs-Feedback issues for all network components.
+* Identify and file bugs for significant new crashers.
 
 ### Best effort:
-* Investigate unowned and owned-but-forgotten net/ crashers
-* Investigate old bugs
+* Investigate unowned and owned-but-forgotten net/ crashers.
+* Investigate old bugs.
 * Close obsolete bugs.
 
 All of the above is to be done on each rotation.  These responsibilities should
@@ -30,67 +30,104 @@ uniform, predictable two day commitment for all triagers.
 
 ### Required:
 
-* 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 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 component 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 their rotation.
-
-* Investigate each recent (new comment within the past week or so)
-  Internals>Network issue, driving getting information from reporters as
-  needed, until you can do one of the following:
+* Identify new network bugs on the bug tracker.  All Unconfirmed issues filed
+  during your triage rotation should be scanned, and, for suspected network
+  bugs, a network component assigned and an about:net-internals log requested.
+  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 their rotation.  Once you've changed labels on a bug, mark it
+  Untriaged, so other triagers sorting through Unconfirmed bugs won't see it.
+  
+    * For desktop bugs, ask for a net-internals log and give the user a link to
+      https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details
+      (A link there appears on about:net-internals, for easy reference) for
+      instructions.  On mobile, point them to about:net-export.  In either case,
+      attach the Needs-Feedback label.
+
+* Investigate UMA notifications.
+
+    * UMA notifications ("chirps") are alerts based on UMA histograms that are
+      sent to   chrome-network-debugging@google.com.  Triagers should subscribe
+      to this list.  When an alert fires, the triager should determine if the
+      alert looks to be real and file a bug with the appropriate label if so.
+      Note that if no label more specific than Internals>Network is appropriate,
+      the responsibility remains with the triager to continue investigating the
+      bug, as above.
+      
+    * The triager is responsible for looking at any notification previous
+      triagers did not, so when an issue is investigated, the person who did
+      so should respond to chrome-network-debugging@google.com with a short
+      email, describing their conclusions.  Future triagers can then use the
+      fact an alert was responded to as an inidicator of which of them need
+      to be followed up on.
+
+* Investigate [Uncomfirmed / Untriaged Internals>Network issues that don't
+  belong to a more specific network component](https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component%3DInternals%3ENetwork+status%3AUnconfirmed,Untriaged+-label:Needs-Feedback&sort=-modified),
+  prioritizing the most recent issues, ones with the most responsive reporters,
+  and major crashers.  This will generally take up the majority of your time as
+  triager. Continue digging 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 Internals>Network component, replacing it with at least one
-      more specific network component or non-network component.  Promptly adding
-      non-network components 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 component.
-
-    * The issue is assigned to an appropriate owner.
-
-    * If there is no more specific component 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.
+    * Mark it as Needs-Feedback.
 
-* Monitor UMA histograms and Chirp/Gasper alerts.
-
-    * For each Chirp and Gasper alert that fires, the triager should determine
-      if the alert is real (not due to noise), and file a bug with the
-      appropriate component if so.  Note that if no component more specific than
-      Internals>Network is appropriate, the responsibility remains with the
-      triager to continue investigating the bug, as above.
+    * Remove the Internals>Network component, replacing it with at least one
+      more specific network component or non-network component. Replacing the
+      Internals>Network component gets it off the next triager's radar, and
+      in front of someone more familiar with the relevant code.  Note that
+      due to the way the bug report wizard works, a lot of bugs incorrectly end
+      up with the network component.
+
+    * The issue is assigned to an appropriate owner, and make sure to mark it
+      as "assigned" so the next triager doesn't run into it.
+
+    * If there is no more specific component for a bug, it should be
+      investigated by the triager 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.
+
+* Follow up on [Needs-Feedback issues for all components owned by the network
+  stack team](https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component%3AInternals%3ENetwork%2CUI>Browser>Downloads+-component%3AInternals%3ENetwork%3EDataProxy+-component%3AInternals%3ENetwork%3EDataUse+-component%3AInternals%3ENetwork%3EVPN+Needs%3DFeedback).
+
+    * Remove label once feedback is provided.  Continue to investigate, if
+      the previous section applies.
+
+    * If the Needs-Feedback label has been present for one week, ping the
+      reporter.
+
+    * Archive after two weeks with no feedback, telling users to file a new
+      bug if they still have the issue, with the requested information, unless
+      the reporter indicates they'll provide data when they can.  In that case,
+      use your own judgment for further pings or archiving.
+
+* Identify significant new browser process
+  [crashers](https://goto.google.com/chromecrash) that are potentially network
+  related.  You should look at crashes for the most recent canary that has at
+  least a day of data, and if there's been a dev or beta release from the start
+  of the last triager's shift to the start of yours, you should also look at
+  that once it has at least a day of data.  Recent releases available
+  [here](https://omahaproxy.appspot.com/).  If both dev and beta have been
+  released in that period, just look at beta.  File Internals>Network bugs on
+  the tracker when new crashers are found.  Bugs  should only be filed for
+  crashes that are both in the top 100 for each release and occurred for more
+  than two users.
 
 ### Best Effort (As you have time):
 
+* Investigate old bugs, and bugs associated with Internals>Network
+  subcomponents.
+
 * Investigate unowned and owned but forgotten net/ crashers that are still
   occurring (As indicated by
   [go/chromecrash](https://goto.google.com/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.md](bug-triage-suggested-workflow.md) for
 suggested workflows.