Update net triage instructions.

net/docs/bug-triage.md

 # Chrome Network Bug Triage
 
 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
 
-### 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
 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.
 
 ## Details
 
 ### 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 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.
 
-* 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 UMA notifications.
 
-* 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:
+    * 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.
 
+    * Mark it as Needs-Feedback.
+
     * 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.
+      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.
+    * 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
-      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.
+    * 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.
 
-* Monitor UMA histograms and Chirp/Gasper alerts.
+* 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).
 
-    * 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 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.
 
 See [bug-triage-labels.md](bug-triage-labels.md) for labeling tips for network
 and non-network bugs.
 
 See [crash-course-in-net-internals.md](crash-course-in-net-internals.md) for
 some help on getting started with about:net-internals debugging.