Net triage docs: Fix links, mention crashes on other platforms.

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.
@@ skipping 43 matching lines @@
       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),
+* 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).

[mmenke, 2016/03/10 17:36:15]

Strangely, splitting the lines here didn't work on Googlesource's md enging, but
did work on Chrome...but the split on line 64 worked on both.

[Randy Smith (Not in Mondays), 2016/03/10 18:14:10]

Huh.  How did you check Googlesource's md engine before landing the CL?

[mmenke, 2016/03/10 19:18:35]

I didn't, I'm describing how it's behaving with the current code.

+* 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).
 
     * 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.
 
+    * Make sure to check for new crashes on all platforms, not just Windows.
+
 ### 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.
 
 * 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.