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

[wpietri]

Wow, great example. That's exactly what I wish had happened here.

[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

[wpietri]

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.

[malandrew]

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

[wpietri]

Yes, I believe that's more smokescreen. As I said, I'm done engaging with you in this forum about this.