Gender-neutralize a few more comments / strings.

docs/shift_based_development.md

 # Introduction
 
 Kai Wang (kaiwang@) and I (Jói Sigurðsson, joi@) experimented with something we called “shift-based development” in the first half of Q1 2013 as a way to work closely together on a componentization that was hard to do in parallel.
 
 I work from Iceland, which is 7 or 8 hours ahead of Kai’s location (Mountain View, California), depending on the time of year (daylight savings time is not observed in Iceland). Kai and I were working on componentizing the Prefs subsystem of Chromium, and it was obvious early on that if we tried to develop in parallel, we would step on each others’ toes very regularly and be forced to do often difficult merges (due to e.g. moving files, renaming things, and so on). The idea came up, since my normal work day ends right around the time Kai’s starts, why not do the development in serial instead. Although I often work an extra hour or two later in the evening, that’s normally for responding to code review requests and email and not so much for coding, so this way we’d be completely free of getting in each others’ way.
 
 The way we implemented this was we set up a bare git repository, and at the end of the day, we would push whatever we were working on to this repository, and let the other know the status of things. This could be a single working branch, or (more often) a pipeline of branches, plus a branch representing the SVN revision we were based off of. To make this work, we were both using the unmanaged git workflow.
 
 The idea was, the next “shift” would pull down the pipeline of branches and continue where the last left off, doing development on the last change in the pipeline if it was incomplete, landing whatever changes could be landed, or starting a new change in the pipeline if all of them were ready for review or ready to land.
 
@@ skipping 88 matching lines @@
 for each branch.
 
 d) At the start of our shift, we did `git fetch shiftrepo` and then
 for each branch we were collaborating on we did `git checkout branchname && git merge shiftrepo/branchname`. Note that the first command checks
 out the local branch, and the second merges the shiftrepo/ branch into
 it. This does not make the shiftrepo/ branch a parent of the local
 branch.
 
 e) Also at the start of each shift, we updated the local upstream
 branches for each branch to match the upstream relationships that the
-person ending their shift had on his end.  One case is if the oldest
+person ending their shift had on their end.  One case is if the oldest
 branch in the pipeline has been merged to a new LKGR, then we did this:
 
 ```
 git branch --set-upstream oldestBranchName `git log -1 --grep=src@ oldestBranchName | head -1 | cut -d " " -f2`
 ```
 
 and the other case is if new branches were created during the last shift, e.g. p4-foo was added, then for each we need to do like this:
 
 ```
 git branch --set-upstream p4-foo p3-bar
@@ skipping 21 matching lines @@
 next branches to work on.
 
 ## Random Commands
 
 To push a local branch to shiftrepo: `git push shiftrepo localbranchname`
 
 To push all "matching" branches (i.e. push the latest copy of
 any local branch that has previously been pushed to shiftrepo): `git push shiftrepo`
 
 To delete a branch from shiftrepo, it's weird: `git push shiftrepo :branchname`