Tweak network doc wording, fix link, and make order in workflow match

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, 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:
+### Best effort, also in rough priority order:
 * 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 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.
+  the last day of their rotation.  Once you've assigned a bug to a component,
+  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.
+      to be followed up on.  Alerts fired before the beginning of the
+      previous triager's rotation may be ignored. 

[mmenke, 2016/03/29 20:19:43]

+"and passive-aggressively whine at the previous triagers."  (Just to be clear,
that's snark)

 
 * 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. 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&sort=-modified).
+* 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%3EBrowser%3EDownloads+-component%3AInternals%3ENetwork%3EDataProxy+-component%3AInternals%3ENetwork%3EDataUse+-component%3AInternals%3ENetwork%3EVPN+Needs%3DFeedback&sort=-modified).

[mmenke, 2016/03/29 20:19:43]

Ahh...Was wondering why I missed one of the downloads bugs you pinged for
feedback on my last rotation!

 
     * 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,
@@ skipping 26 matching lines @@
 * Close obsolete bugs.
 
 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.