Update bug labels to components in network triage documentation.

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 61 matching lines @@
   net-related, look at the crash stack at
   [go/crash](https://goto.google.com/crash), and see if it looks to be network
   related.  Be sure to check if other bug reports have that stack trace, and
   mark as a dupe if so.  Even if the bug isn't network related, paste the stack
   trace in the bug, so no one else has to look up the crash stack from the ID.
     * If there's no other information than the crash ID, ask for more details
       and add the Needs-Feedback label.
 
 * If network causes are possible, ask for a net-internals log (If it's not a
   browser crash) and attach the most specific internals-network label that's
-  applicable.  If there isn't an applicable narrower label, a clear owner for
-  the issue, or there are multiple possibilities, attach the internals-network
-  label and proceed with further investigation.
+  applicable.  If there isn't an applicable narrower component, a clear owner for
+  the issue, or there are multiple possibilities, attach the Internals>Network
+  component and proceed with further investigation.
 
-* If non-network causes also seem possible, attach those labels as well.
+* If non-network causes also seem possible, attach those components as well.
 
-## Investigating Cr-Internals-Network bugs
+## Investigating component=Internals>Network bugs
 
 * 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 uncomfirmed and untriaged Cr-Internals-Network bugs,
+* Look through uncomfirmed and untriaged component=Internals>Network bugs,
   prioritizing those updated within the last week. [Use this issue tracker
-  query](https://code.google.com/p/chromium/issues/list?can=2&q=Cr%3DInternals-Network+-status%3AAssigned+-status%3AStarted+-status%3AAvailable+&sort=-modified).
+  query](https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component%3DInternals%3ENetwork+-status%3AAssigned+-status%3AStarted+-status%3AAvailable&sort=-modified&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids).
 
 * If more information is needed from the reporter, ask for it and add the
   Needs-Feedback label.  If the reporter has answered an earlier request for
   information, remove that label.
 
 * While investigating a new issue, change the status to Untriaged.
 
 * If a bug is a potential security issue (Allows for code execution from remote
   site, allows crossing security boundaries, unchecked array bounds, etc) mark
   it Type-Bug-Security.  If it has privacy implication (History, cookies
   discoverable by an entity that shouldn't be able to do so, incognito state
   being saved in memory or on disk beyond the lifetime of incognito tabs, etc),
-  mark it Cr-Privacy.
+  mark it with component Privacy.

[eroman, 2016/02/22 19:22:31]

Kind of weird, but seems how we have done it.

[mmenke, 2016/02/22 19:28:01]

Seems very broken.  But ok, I guess?

 
-* For bugs that already have a more specific network label, go ahead and remove
-  the Cr-Internals-Network label and move on.
+* For bugs that already have a more specific network component, go ahead and remove
+  the Internals>Network component and move on.
 
 * Try to figure out if it's really a network bug.  See common non-network
-  labels section for description of common labels needed for issues incorrectly
-  tagged as Cr-Internals-Network.
+  components section for description of common components for issues incorrectly
+  tagged as Internals>Network.
 
-* If it's not, attach appropriate labels and go no further.
+* If it's not, attach appropriate labels/components and go no further.
 
-* If it may be a network bug, attach additional possibly relevant labels if
+* If it may be a network bug, attach additional possibly relevant component if
   any, and continue investigating.  Once you either determine it's a
-  non-network bug, or figure out accurate more specific network labels, your
+  non-network bug, or figure out accurate more specific network components, your
   job is done, though you should still ask for a net-internals dump if it seems
   likely to be useful.
 
 * Note that ChromeOS-specific network-related code (Captive portal detection,
   connectivity detection, login, etc) may not all have appropriate more
-  specific labels, but are not in areas handled by the network stack team.
+  specific subcomponents, but are not in areas handled by the network stack team.
   Just make sure those have the OS-Chrome label, and any more specific labels
   if applicable, and then move on.
 
 * Gather data and investigate.
     * Remember to add the Needs-Feedback label whenever waiting for the user to
       respond with more information, and remove it when not waiting on the
       user.
     * Try to reproduce locally.  If you can, and it's a regression, use
       src/tools/bisect-builds.py to figure out when it regressed.
     * Ask more data from the user as needed (net-internals dumps, repro case,
       crash ID from about:crashes, run tests, etc).
     * If asking for an about:net-internals dump, provide this link:
       https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details.
       Can just grab the link from about:net-internals, as needed.
 
-* Try to figure out what's going on, and which more specific network label is
+* Try to figure out what's going on, and which more specific network component is
   most appropriate.
 
 * If it's a regression, browse through the git history of relevant files to try
   and figure out when it regressed.  CC authors / primary reviewers of any
   strongly suspect CLs.
 
 * 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.
+  subcomponent applies, or only the Internals>Network>HTTP subcomponent
+  applies, and there's no clear owner), try to figure out the exact cause.
 
 ## Monitoring UMA histograms and Chirp/Gasper alerts
 
 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.
 
@@ skipping 44 matching lines @@
 
 * 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
 
 ## Dealing with old bugs
 
-* For all network issues (Even those with owners, or a more specific labels):
+* For all network issues (Even those with owners, or a more specific component):
 
     * If the issue has had the Needs-Feedback label for over a month, verify it
       is waiting on feedback from the user.  If not, remove the label.
       Otherwise, go ahead and mark the issue WontFix due to lack of response
       and suggest the user file a new bug if the issue is still present. [Use
       this issue tracker query for old Needs-Feedback
       issues](https://code.google.com/p/chromium/issues/list?can=2&q=Cr%3AInternals-Network%20Needs=Feedback+modified-before%3Atoday-30&sort=-modified).
 
     * 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
+* Old unconfirmed or untriaged 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.