I'm surprised by the disproportionate level of angst from the people who are upset about the use of 'they' in place of 'he'. I can see the point of eliminating both and using 'it' instead, but some of the comments on that Github issue sounded like the kind of 'political correctness gone mad!' drivel that one[1] reads in the Daily Mail[2], for goodness' sake.
It's not really about the They VS. He issue. No one got worked up about the original commits/documentation. What people are strongly objecting to, correctly in my opinion, is the divisive and condescending way in which the commits were reverted and the reason why they were reverted. Simply put he said that making the project feel more welcoming for women was a trivial and unimportant. It's basically the same as actively promoting the myth that open source is a white male only thing, not cool IMO.
I dunno. He said that the pull request was trivial, which could have been meant in the sense that the change is trivial - a one-word change to a code comment that does not affect the program's operation. Commit history space is a somewhat scarce resource, and I can see the point in rejecting the commit on the grounds that it doesn't really change enough to be worth a commit. For example, did the commit fix all instances of masculine pronouns or just one? Was it intended to fix the whole problem, or just to "make a point"? I can see why the committer might not have seen much value in the PR. I don't think that he deserves to be totally excoriated for his rejection of the PR just yet, as it would be good to hear his side of the story first.
Comment threads are rarely conducive to positive discussion, especially once people start tweeting about them, and I think a lot of assumptions were made on the basis of fairly scant evidence. I'm enough of an optimist to believe that the committer didn't meant to suggest that open source is a white male only thing, and if we're concerned about that view becoming widespread then we might want to be cautious about suggesting that as his motive.
That's definitely the real reason behind this situation: The people behind large projects tend to have to manage tons of releases, branches, and commits along with the code itself. The solution that many projects use is to appoint a few people with The Power to Approve Commits, so that all this meta-information can be managed more effectively. Every commit that you create is a set of extra objects that need to be downloaded, examined, and discussed separately. If you have people to manage this, then the amount of meta-noise goes down. Otherwise, you have some people trying to merge branches with tons of tiny commits with names like "Argh why doesn't this work" instead of squashing them together, increasing the amount of noise that you must look through.
So it is understandable that anyone in such a position would reject a change which amounts to editing a word to a synonym, in terms of the meaning of the documentation. What really matters with documentation is the question "Does this commit improve the ability of the documentation to teach users how the product works?" Rarely do I see a pull request and think "Is this commit offensive or discriminatory?" because people submitting code that is offensive is a pretty rare occurrence, rare enough that it almost seems impossible. But here's the issue: In this case, there were at least two Commit Approvers involved. When the commit was rejected, the committer obtained permission from another Commit Approver. When the commit was pushed through, then to the first Commit Approver, the committer appeared to be breaking the golden rule: Only the appointed Commit Approver may approve commits. Which is why there was a chiding comment left by that first Commit Approver. Now of course, looking at one side of the evidence, it is very easy for some people to jump to the conclusion that misogyny is involved.
It just so happened that the commit in question contained so-called Colored Bits [1] - it carried gender equality connotations that some people found to be objectionable. What people don't seem to realize is that maybe not that much attention was paid to what kind of meta-meta-information was associated with this commit (itself being a piece of meta-information about the documentation, a piece of information.) Maybe the person in charge of approving commits had a lot of work on his plate that day and only wanted to focus on what a lot of developers say is the Part That Matters - the code. So he acted bureaucratically on this pull request. It is possible to act in an entirely robotic manner and still get accused of things like gender bias. Looking at the backstory of this commit, it doesn't seem like there was any malicious intent by any party at all.
What could have been done to mitigate this situation? Maybe if there was a single person in charge of managing updates to the documentation, who curated the incoming commits in large batches before creating pull requests to the Commit Approver, then there would be less friction in getting documentation updated. Maybe if the executive people at Joyent were more understanding of the situation, then they would not have fired one of their employees over trivial circumstances.
Forget political correctness. Using needlessly gender-bound pronouns is simply bad writing, as is ostentatiously randomizing pronouns. You are not a better writer than Conrad, or Jane Austen. Both would tell you: English has a singular gender-neutral pronoun; it's "they".
I think a better solution would be to select random gendered pronouns but keep them consistent (for example don't switch mid sentence which is the worst of both worlds).
If you are describing a transaction between two people, make one male and one female. If you have an odd number then distribute gender at random.
I think a better solution would be to select random gendered pronouns
This can work, and it's certainly good practice when one is talking about social situations, and is one of the reason that "Alice and Bob" are such enduring characters. It's probably less good when one is talking about computations, where gender (and, indeed, personhood) is just a distraction, unless we really do believe in feminine functions and masculine monads.
It also wouldn't have helped much in the original Github issue, where a single instance of 'he' was being corrected. Git's patch-oriented workflow is great for correcting local bugs but not so great for global things like "do we have the correct balance of pronoun genders across our codebase?". I think if you ever end up having to ask that question, something has gone badly wrong.
If the interacting entities are not persons, we have "it" as a neuter pronoun. If they are persons, we can use "he" and "she" alternately, "he/she" (somewhat cumbersome and stilted), or "they".
[1] A gender-neutral pronoun!
[2] If you're fortunate enough to not know what the Daily Mail is: http://www.youtube.com/watch?v=5eBT6OSr1TI