[TOC]
Go to go/chromecrash.
For each platform, look through the releases for which releases to investigate. As per bug-triage.txt, this should be the most recent canary, the previous canary (if the most recent is less than a day old), and any of dev/beta/stable that were released in the last couple of days.
For each release, 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::".
For each found signature:
Look at new uncomfirmed bugs since noon PST on the last triager's rotation. Use this issue tracker query.
Read the title of the bug.
If a bug looks like it might be network/download/safe-browsing related, middle click (or command-click on OSX) to open it in a 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 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 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 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 components as well.
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:
Look through uncomfirmed and untriaged component=Internals>Network bugs, prioritizing those updated within the last week. Use this issue tracker query.
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 with component Privacy.
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 components section for description of common components for issues incorrectly tagged as Internals>Network.
If it's not, attach appropriate labels/components and go no further.
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 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 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.
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 subcomponent applies, or only the Internals>Network>HTTP subcomponent applies, and there's no clear owner), try to figure out the exact cause.
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:
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.
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.
See if the same users are repeatedly running into the same issue. This can be accomplished by search for (Or clicking on) the client ID associated with 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
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.
If a bug is over 2 months old, and the underlying problem was never reproduced or really understood:
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.