A couple of minor updates to triage instructions.

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

 # Chrome Network Bug Triage : Suggested Workflow
 
 [TOC]
 
 ## Identifying unlabeled network bugs on the tracker
 
 * Look at new unconfirmed bugs since noon PST on the last triager's rotation.
   [Use this issue tracker
   query](https://bugs.chromium.org/p/chromium/issues/list?q=status%3Aunconfirmed&sort=-id&num=1000).
 
@@ skipping 31 matching lines @@
 
 * Don't file if the graph is really noisy (but eyeball it to decide if there is
   an underlying important shift under the noise).
 
 * Don't file if the alert is in the "Known Ignorable" list:
     * SimpleCache on Windows
     * DiskCache on Android.
 
 ## Investigating component=Internals>Network bugs
 
+* Note that you may want to investigate Needs-Feedback bugs first, as
+  that may result in some bugs being added to this list.  
+
 * It's recommended that while on triage duty, you subscribe to the
   Internals>Network component (but not its subcomponents). To do this, go
   to the issue tracker and then click "Saved Queries".
   Add a query with these settings:
     * Saved query name: Network Bug Triage
     * Project: chromium
     * Query: component=Internals>Network
     * Subscription options: Notify Immediately
 
 * Look through unconfirmed and untriaged component=Internals>Network bugs,
@@ skipping 108 matching lines @@
             3. Removing the "product.version='X.Y.Z.W' AND" string and clicking
                "Update".
             4. Clicking "Limit 1000" in the Product Version list in the
                resulting page (without this, the listing will be restricted to
                the releases in which the signature is most common, which will
                often not include the canary/dev release being investigated).
             5. Choose some subset of that list, or all of it, to include in the
                bug.  Make sure to indicate if there is a defined point in the
                past before which the signature is not present.
 
+As an alternative to the above, you can use [Eric Roman's new crash
+tool](https://ericroman.users.x20web.corp.google.com/www/net-crash-triage/index.html)
+(internal link).  Note that it isn't a perfect fit with the triage
+responsibilities, specifically:
+  
+* It's only showing Windows releases; Android, iOS, and WebView are
+  usually different, and Mac is sometimes different.
+* The instructions are to look at the latest canary which has a days
+  worth of data.  If canaries are being pushed fast, that may be more
+  than one canary into the past, and hence not visible on the tool.
+* Eric's tool filters based on files in "src/net" rather than looking
+  for magic signature's including the string "net::" ("src/net" is
+  probably the better filter).    
+
 ## Investigating crashers
 
 * Only investigate crashers that are still occurring, as identified by above
   section.  If a search on go/crash indicates a crasher is no longer occurring,
   mark it as WontFix.
 
 * On Windows, you may want to look for weird dlls associated with the crashes.
   This generally needs crashes from a fair number of different users to reach
   any conclusions.
     * To get a list of loaded modules in related crash dumps, select
@@ skipping 12 matching lines @@
   a crash report, and seeing if there are multiple reports for the same crash.
   If this is the case, it may be also be malware, or an issue with an unusual
   system/chrome/network config.
 
 * Dig through crash reports to figure out when the crash first appeared, and
   dig through revision history in related files to try and locate a suspect CL.
   TODO(mmenke):  Add more detail here.
 
 * Load crash dumps, try to figure out a cause.  See
   http://www.chromium.org/developers/crash-reports for more information