[veemjeem]

If you read the github thread, you'd see that Ben actually never participated in the drama/discussion until it blew up. Ben essentially rejected the pull request, then a giant PR nightmare blew up overnight with blog posts from Joyent & Strongloop. He decided to leave because of the whole ordeal from the companies.

[wpietri]

I read the github thread.

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.

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

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

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

[smf]

Exactly. Well said.

[regularfry]

The way I saw it, there was one blowup when bnoordhuis rejected the initial PR, but it magnified hugely when he then reverted isaacs's commit applying the patch from the PR, "chiding" him in the process. According to the IRC log, isaacs made the commit "acting fast to prevent it from blowing up further into a whole big thing."

Looking at the IRC log, here's a weirdery: The initial patch (47d98b6) and the merge commit isaacs made (5812e19) both appear in the IRC log. bnoordhuis' revert (804d40e) doesn't. In fact, the revert isn't discussed at all.