[malandrew]

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.

[wpietri]

I understand you believe it was trivial. Maybe Ben Noordhuis still does too. Others disagree.

Using power to force one's own view because one can is a problematic behavior in open source projects. It needlessly costs contributors. And respect.

[malandrew]

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.).

[wpietri]

The view forced was that the change was trivial.

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.

[malandrew]

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.

[wpietri]

> Pronouns don't matter.

You keep turning your opinions into supposed statements of fact. Given how little you know about this topic, you're just embarrassing yourself.

Pronouns matter. The politics of it may not matter to you, but they matter to a lot of other people. They also matter in terms of reader perception. E.g.: http://www.jstor.org/discover/10.2307/27784423?uid=3739560&u...

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.

[malandrew]

    "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.

[millstone]

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.

[wpietri]

Well, technically, it was two places.

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.

[millstone]

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).

[malandrew]

    "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.

[0] https://github.com/joyent/libuv/issues [1] https://github.com/joyent/libuv/pulls

[sampo]

> "Please explain to me what view you think Ben was forcing upon the community

The view that the improvement to the documentation text was trivial.

[malandrew]

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.

[sampo]

"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.

[smf]

Exactly. Well said.