Update triage documents with Chirp.

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

 # Chrome Network Bug Triage : Suggested Workflow
 
 [TOC]
 
 ## Looking for new crashers
 
 1. Go to [go/chromecrash](https://goto.google.com/chromecrash).
 
 2. For each platform, look through the releases for which releases to
    investigate.  As per bug-triage.txt, this should be the most recent canary,
@@ skipping 141 matching lines @@
 * If you are having trouble with an issue, particularly for help understanding
   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.
 
-## Monitoring UMA histograms and gasper alerts
+## Monitoring UMA histograms and Chirp/Gasper alerts
 
-For each Gasper alert that fires, determine if it's a real alert and file a bug
-if so.
+Sign up to chrome-network-debugging@google.com mailing list to receive automated
+e-mails about UMA alerts.  Chirp is the new alert system, sending automated
+e-mails with sender address finch-chirp@google.com.  Gasper is the old alert
+system, sending automated e-mails with sender address gasper-alerts@google.com.
+While Chirp is of higher priority, Gasper is not deprecated yet, so both alerts
+should be monitored for the time being.
+
+For each alert that fires, determine if it's a real alert and file a bug if so.
 
 * Don't file if the alert is coincident with a major volume change.  The volume
   at a particular date can be determined by hovering the mouse over the
   appropriate location on the alert line.
 
 * Don't file if the alert is on a graph with very low volume (< ~200 data
   points); it's probably noise, and we probably don't care even if it isn't.
 
 * 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.
 
-For each Gasper alert, respond to chrome-network-debugging@google.com with a
-summary of the action you've taken and why, including issue link if an issue
-was filed.
+For each alert, respond to chrome-network-debugging@google.com with a summary of
+the action you've taken and why, including issue link if an issue was filed.
 
 ## 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.
@@ skipping 36 matching lines @@
       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.