Minor changes to triage docs.

net/docs/bug-triage.txt

 The Chrome network team uses a two day bug triage rotation.  The main goals are
 to identify and label new network bugs, and investigate network bugs when no
 label seems suitable.
 
 Responsibilities
 
 To be done on each rotation.  These responsibilities should be tracked, and
 anything left undone at the end of a rotation should be handed off to the next
 triager.  The downside to passing along bug investigations like this is each new
 triager has to get back up to speed on bugs the previous triager was
 investigating.  The upside is that triagers don't get stuck investigating issues
 after their time after their rotation, and it results in a uniform, predictable
 two day commitment for all triagers.
 
 Primary Responsibilities:
 * Identify new crashers that are potentially network related.  You should check
     the most recent canary, the previous canary (if the most recent less than a
     day old), and any of dev/beta/stable that were released in the last couple
     of days, for each platform.  File Cr-Internals-Network bugs on the tracker
     when new crashers are found.
 * Identify new network bugs, both on the bug tracker and on the crash server.
     All Unconfirmed issues filed during your triage rotation should be scanned,
     and, for suspected network bugs, a network label assigned.  A triager is
     responsible for looking at bugs reported from noon PST / 3:00 pm EST of the
     last day of the previous triager's rotation until the same time on the last
-    day of his rotation.  
+    day of their rotation.
 * Request data about recent unassigned Cr-Internals-Network bugs from reporters.
     "Recent" means issues updated in the past week or so.
 * Investigate each recent (New comment within the past week or so)
     Cr-Internals-Network issue until you can do one of the following:
   * Mark it as WontFix (working as intended, obsolete issue) or a duplicate.
   * Mark it as a feature request.
   * Remove the Cr-Internals-Network label, replacing it with at least one more
     specific network label or non-network label.  Promptly adding non-network
     labels when appropriate is important to get new bugs in front of someone
     familiar with the relevant code, and to remove them from the next triager's
@@ skipping 15 matching lines @@
 * Investigate old bugs, prioritizing the most recent.
 * Close obsolete bugs.
 
 If you've investigated an issue (in code you don't normally work on) to an
 extent that you know how to fix it, and the fix is simple, feel free to take
 ownership of the issue and create a patch while on triage duty, but other tasks
 should take priority.
 
 See bug-triage-suggested-workflow.txt for suggested workflows.
 See bug-triage-labels.txt for labeling tips for network and non-network bugs.