Ben closed the sincere and well-meant patch, saying, "Sorry, not interested in trivial changes like that." He didn't just participate in the drama; he started it.
Non-drama options would be things like: asking the contributor more, asking a colleague to look it over, asking a native speaker why it mattered, and just moving past the pull request and leaving it for somebody who cared.
It was a trivial change. It didn't help me nor anyone else understand the code being commented on any better, nor did it change any executable code. That's about as close to the definition of a trivial[0] change that I can think of. Pronoun choice is of little value of importance since this is a open source project, not a college gender studies class. If you think that's not trivial, then take it somewhere where it's not considered trivial and spare everyone else the bikeshedding.
[0] definition of trivial: of little value or importance.
Please explain to me what view you think Ben was forcing upon the community, because I do not think the view you and others nerd-raging here is aligned with reality.
Ben was forcing the view that the commit policy had not been followed, which is a view that the rest of the community agrees with. This all got blown out of control when someone misinterpreted Ben's actions and started a bikeshedding tempest in a teacup instead of figuring out why Ben considered it a trivial change.
I don't know about you, but everyone who went off the deep end in that thread basically joined a lynch mob based on misunderstanding and failure to seek clarification for the commit reversion. The burden was on those who were upset to seek clarification instead of brandishing pitchforks and torches.
I don't think anyone who has contributed to the NodeJS repo joined because they wanted to bikeshed over gender issues. I'd be surprised if anyone (other than the author of the commit that started all this) joined to commit with that as a primary intent (or secondary, tertiary, etc.).
That's the same view you're trying to force here. But at least Noordhuis has the virtue of possibly believing that. You clearly don't; you've got 9 dismissive, rage-y comments on this article. That's not how people react to trivia, which you were helpful enough to define as of little importance.
I think you correctly recognize the topic, which is the politics of gender inclusion, as important. It's just that you disagree with the people who proposed and support this change. I'd rather you were honest enough to say that, rather than trying to get us to swallow the notion that this this totally unimportant thing is totally important.
I agree gender issues are important. Pull requests are the wrong place to begin that debate. NodeJS was not started as a asynchronous framework for server side javascript with gender inclusive comments.
The project was never gender exclusive. The comments could have easily used the pronouns she instead of he. Whoever wrote the comment chose he for whatever reason. Had someone else who has a different gender pronoun preference written the code being commented on, then it would have been different. It doesn't really matter because it's irrelevant to the purpose of the project.
Yes, I disagree with people wasting the committer's time with something that simply does not matter. Pronouns don't matter. He, she, it, user, dog, cat, lamp. If it's not code or comments that further clarify the code in question who cares because it simply does not matter. Knowing or not knowing the gender of the example user in the comment doesn't change anything about the code. Were we really supposed to believe that it was only going to send the nsent flag is the user is male and that we are not sending the flag if the user is female.
People should either code or not code, but they should not pretend to contribute with trivial pull requests that have been one huge net negative addition to the project due to the shitstorm kicked up. That's all the original pull request has accomplished ... one big massive net negative addition to the community. What an excellent way to make your point and endear people with your cause. I hope they are happy with the turd they left in the pool.
You know what statistic I would love to see. Lines of code contributed by those who think the change is trivial versus those that think it is not trivial. That's the only worthwhile objective measure of "important" that really matters. I bet you that the conversation on that PR is actually really really short once you eliminate everyone who has never contributed a pull request.
We are coming out of centuries of systemic gender discrimination. The tech industry still has substantial problems in this regard, and is under intense scrutiny, internal and external. Arguing to ignore improvements in favor of the status quo is arguing to support gender discrimination. Arguments like that are especially suspicious from somebody on the good side of gender privilege. Especially double-talk arguments about how vitally important it is to resist this one specific trivial patch.
Also, you can't blame the shitstorm on the person submitting the pull request. After all, you keep asserting that it's trivial, the very smallest of things. The shitstorm started with the rude, dismissive rejection of the pull request. If you'd like to blame something, blame that.
"Also, you can't blame the shitstorm on the person
submitting the pull request."
Why not? You can't unilaterally decide that that person cannot be to blame here.
They could have made a contribution of utility (bugfix or feature for example) and included that minor comment change within that pull request, instead of using a pull request as their own personal soapbox. Github issues and pull requests are not forums for debating the politics of gender issues. As someone who had never once submitted a prior pull request with utility to libuv, Alex Gaynor should have made his change silently as part of a bugfix or feature and moved along. His behavior was antisocial.
Or as an alternative, he could have privately emailed an existing contributor, discussed the change, and got support. If it had come from Isaac or Bert to start with, it would have sailed through without objection.
I really feel like a pull request was the wrong vehicle for what the original submitter was trying to accomplish.
If open-source projects adopt an "email first before pull request" approach, I think that's a big mistake. That will mean a lot of dialog with people who aren't actually going to do the work, and a lot of missed patch opportunities from people who have done or will do the work but are put off by the uncertainty of a policy like that.
Regardless, if a pull request is the wrong vehicle, then the correct response isn't, "Request rejected! Go away." It's "Let's talk about this more." It was a two-line change that made the project better. (At least, nobody has so far claimed that the gender-exclusive language was better.) I think that's enough of a positive signal to be worth following up on, and certainly not the dire insult that some believe it to be.
Ok. If it's not a policy, then I don't think there's any way you can expect a potential contributor to know that a particular pull request must be preceded by discussion. In which case, I think the burden falls on the person reviewing the requests. In this case, Noordhuis. The submitter did their bit by making a positive change and offering the patch.
The change was not "let's make libuv comments gender neutral," but "here's this one thing I noticed in this one place." A one-off change like that has a trivial impact on the overall gender-inclusiveness of the project, and that's the case no matter what importance you attach to it.
If gender-inclusive language in comments is deemed important, then it ought to be treated as important from the contributor side. For example, "comments must all be gender neutral" should have been incorporated into the coding standard for the project, along with a rationale, and the existing code should have been vetted for all uses of gendered pronouns. That would have made for a more serious contribution, and I bet Noordhuis would have treated it differently.
Your theory about Noordhuis is interesting, but there's no evidence for it, and some against. If he had thought it was a good change that just needed more in that direction, he could have easily said that rather than closing the pull request with a discouraging comment.
I think that's true for any change, really. If somebody had fixed a spelling mistake, would any reasonable project leader just have closed the pull request dismissively? I doubt it. Would have they refused to accept the patch until spelling was put in the coding standard and all spelling mistakes were fixed in one go? That'd be crazy.
I guess I'm extrapolating from my own experiences. I review and merge pull requests on a semi-notable project, and I am often tasked with evaluating changes in unfamiliar areas, which means I am liable to misunderstand the significance of a change (as Noordhuis acknowledged he did, not being a native speaker). I appreciate PRs that clearly explain the issues and lay out their case, and I defer many one-offs that I deem not worth the trouble.
So I sympathize with the guy. All I see is someone donating his precious free time acting in what he believes to be the interests of the project, doing his best to handle issues that he poorly understands, because someone has to do it.
I have actually encountered your spelling mistake example. I dealt with it by asking the contributor to vet the code for other instances of the same mistake. The results were fantastic: the contributor was inspired to find all sorts of spelling mistakes, and include them in the PR, resulting in one big commit fixing dozens of errors.
So you are correct to criticize his dismissive comment, and choice to close the PR. That attitude drives away potential contributors, and also invites misunderstanding (in this case, accusations of misogyny).
"he could have easily said that rather than closing the
pull request with a discouraging comment"
There are 129 open issues[0] and 25 open pull requests[1] for libuv right now on Github. That one didn't deserve his extremely valuable time that is better spent on considering contributions that matter, like the the 25 open pull requests.
You don't have a right to Ben's time and attention. He gives to the project out of his own volition out of a sense of duty to the community. The community here are people who have help build node.js and libuv to what it is today. Someone showing up in Nov/Dec 2013 issuing their first pull request and making it a trivial one isn't deserving of Ben's time. Ben doesn't owe anyone an explanation here. Had the PR request submitter made several prior code commits that had been accepted, maybe it would be fair to expect an explanation, but not for a trivial first PR.
That I don't have a right to Ben's time and attention is true, but irrelevant. I'm not demanding anything of him.
I do have the right to criticize him for his public actions, which is what I'm doing. I think he behaved poorly in relation to two topics I care about: leading open source projects, and ending sexism. He doesn't owe me an explanation, but I would read it with interest.
I also think people on the project have a right to criticize him. They have. He does owe them an explanation; any action taken in the project's name is subject to review by the project community.
I think the rest of your argument is more smokescreen for your true agenda, which is tiresome. I'm glad to discuss the actual issue, but I'm not interested in knocking down straw men until you get tired of making them. It seems like you've run out of new things to say, and I don't think either of us is learning anything here. If you want to discuss this further, feel free to email me.
"I think he behaved poorly in relation to two topics I care
about: leading open source projects, and ending sexism."
I would think that the best way to do that is to lead by example by leading and open source project and combatting sexism in the project(s) you lead instead of knocking down my strawmen.
If you lead an open source project and fight to end sexism, then great. If not, you are in no position to criticize Ben.
"I also think people [who have contributed to] the project have
a right to criticize him. [Everyone else can GTFO]. He does owe
them an explanation; any action taken in the project's name is
subject to review by the project community."
FTFY. This entire ordeal would have been a non-issue if you could mute non-contributors.
My true agenda? Establishing a culture where non-contributors don't waste the time of contributors with their bikeshedding.
What excludes someone from the category of non-contributor? They submit test cases. They clarify documentation to make it clearer how to use the code or understand the algorithms in the code. They implement features. They participate in design discussions. They contribute use cases and elaborate on why those use cases are important. They fix bugs in the open source code instead of simply hacking around it in their own code. They write blog posts on how to use the open source code. They publish examples of the open source code in use. They give talks on how to use the open-source code.
Nope. At best that's a partial explanation of the view.
In Ben's own words:
"... Us maintainers tend to reject tiny doc changes
because they're often more trouble than they're worth. You
have to collect and check the CLA, it makes git blame less
effective, etc."
Put yourself in Ben's shoes. You come across a commit that clearly doesn't fix a bug, add a feature or clarify some confusing comments (it's may not have been PC, but it certainly wasn't confusing). Next you check who is submitting the PR. It's from some user you don't recognize because they've never submitted a pull request before. Well before you can accept the commit, you need to check if they have signed a CLA. Well that's a pain in the ass to do. So you ask yourself, "Is it really worth my time to go look all this stuff up or should I just close it and move on to a pull request that actually contributes something valuable to the project?".
I would expect the overwhelming majority of people who have been committers of a large active open-source project to have done what Ben did. It's called triaging and it is in the overall best interest of the community.
"Tiny changes" are his words. It was tiny in the amount of characters, but apparently some people consider it not so tiny in meaning, otherwise this whole storm would not have ensued.
Some people consider it tiny, other don't. There is no consensus.
Also, I don't think anyone can claim copyright over the change of 2 words (so in the intellectual property sense it was tiny), so if there was CLA- and other process-related complications, he could have done the same edits himself. Takes one minute, problem solved, shitstorm avoided. Would also have saved a lot of his and everyone's time.
Ben closed the sincere and well-meant patch, saying, "Sorry, not interested in trivial changes like that." He didn't just participate in the drama; he started it.
Non-drama options would be things like: asking the contributor more, asking a colleague to look it over, asking a native speaker why it mattered, and just moving past the pull request and leaving it for somebody who cared.