Update from https://crrev.com/316786

net/docs/bug-triage-suggested-workflow.txt

 Identifying unlabeled network bugs on the tracker:
 * Look at new uncomfirmed bugs since noon PST on the last triager's rotation:
     https://code.google.com/p/chromium/issues/list?can=2&q=status%3Aunconfirmed&sort=-id&num=1000
 * Press "h" to bring up a preview of the bug text.
 * Use "j" and "k" to advance through bugs.
 * If a bug looks like it might be network/download/safe-browsing related, middle
     click [or command-click on OSX] to open in new tab.
 * If a user provides a crash ID for a crasher for a bug that could be
     net-related, look at the crash stack at go/crash, and see if it looks to be
     network related.  Be sure to check if other bug reports have that stack
@@ skipping 59 matching lines @@
     net-internals logs, email the public net-dev@chromium.org list for help
     debugging.  If it's a crasher, or for some other reason discussion needs to
     be done in private, use chrome-network-debugging@google.com.
     TODO(mmenke): Write up a net-internals tips and tricks docs.
 * If it appears to be a bug in the unowned core of the network stack (i.e. no
     sublabel applies, or only the Cr-Internals-Network-HTTP sublabel applies,
     and there's no clear owner), try to figure out the exact cause.
 
 Look for new crashers:
 * Go to go/chromecrash.
-* For each platform, go to the latest canary.  Click on browser -> limit 1000.
-    Search the page for "net::".  Ignore crashes that only occur once, as
+* For each platform, go to the latest canary.
+* In the "Process Type" frame, click on "browser".
+* At the bottom of the "Magic Signature" frame,  click "limit 1000".
+  Reported crashers are sorted in decreasing order of the number of reports for
+  that crash signature.
+* Search the page for "net::".  Ignore crashes that only occur once, as
     memory corruption can easily cause one-off failures when the sample size is
     large enough.
-  * Look at the stack trace to confirm it's a network bug.
+* Click on the number of reports field to see details of crash. Look at the
+    stack trace to confirm it's a network bug.
   * If it is, and there's no associated bug filed, file a new bug directly from
       chromecrash, looking at earlier canaries to determine if it's a recent
       regression.  Use the most specific label possible.
 * The most recent Canary may not yet have a full day of crashes, so it may be
     worth looking at more than one version.
 * If there's been a dev, beta, or stable release in the last couple days, should
     also look at those.
 
 Investigating crashers:
 * Only investigate crashers that are still occurring, as identified by above
@@ skipping 24 matching lines @@
   * If a bug is over 2 months old, and the underlying problem was never
     reproduced or really understood:
     * If it's over a year old, go ahead and mark the issue as Archived.
     * Otherwise, ask reporters if the issue is still present, and attach the
         Needs-Feedback label.
 * Old unconfirmed or untriaged Cr-Internals-Network issues can be investigated
     just like newer ones.  Crashers should generally be given higher priority,
     since we can verify if they still occur, and then newer issues, as they're
     more likely to still be present, and more likely to have a still responsive
     bug reporter.