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.
Comments
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.
[1]: http://ansuz.sooke.bc.ca/entry/23