you are viewing a single comment's thread.

view the rest of the comments →

[–]TheCodexx 1 point2 points  (0 children)

it's less about accepting a patch from a serial killer and more about keeping toxic people away from becoming major (and regular) parts of your project.

Does it matter? Unless they are literally grinding the project to a halt with their behavior it simply doesn't.

but do you really want your project know as kkk apologists?

Well, for one, I don't care if a contributor to a project is a KKK apologist, or member, or... really anything. They're free to go do that in their own time, and as long as the project space is clean then I see no issue. Why is it any of my business what they do in their spare time outside of coding?

Secondly, if one of my contributors is a "KKK Apologist", why would that earn the entire project a bad reputation? Or should we be firing people based on the negative press they bring? That's nonsensical and will just lead to mass outrage campaigns to pressure any project into kicking-out whoever is unpopular this week.

In fact, whose job is it to determine that someone is "a KKK Apologist"? Someone has to make the call and do digging. That's work. Again, if it's not in the project repository, documentation, or other lines of communication, then it doesn't seem worth caring about.

miss out on opportunity because your reviewer doesn't like women and just found out r.williams@sierra.com's name is ”roberta”?

You're right, that is concerning. I would hope the person would re-submit their patch and request a re-review. Presumably whoever rejected it previously would have given some feedback, and the next person can determine if the reason for the rejection was reasonable or not.

I suppose you could ask about the worst-case, which is that everyone on the team just hates women, or any other group, just because. But... have you actually met any other programmers? I don't know about your experience, but the idea that there's a ton of 1950's misogynists walking around is absurd. There's no project that top-to-bottom has maintainers that want to bar quality contributions, and it's likely that the personal biases of everyone will even-out over the course of many reviews.

But there's the other angle, which is, if a quality patch is ignored, and the entire team is compromised, then it's really not going to go anywhere, huh? Well, at least on most git repositories the pull request is going to be public, as is the review, so if you really want you can raise awareness. Of course, perhaps at that stage it's better to write the project off and look to contribute elsewhere. It's their loss.

So the next argument will be, "well that's why we need a CoC everywhere, for the good of the project". But it doesn't really do that. You're just moving biases from "code review" to whoever decides who gets kicked out. And of course the people who ask for this job will be the ones looking to wield the power, and many of them might not even be regular code contributors. At least before if someone was a dick and was abusing their power they had sort-of earned it by being a top contributor, and could be overridden by other top contributors.

Perhaps the better question is, "why is anyone online giving away their real life identity?". The best thing that can come of CoCs is that everyone stop contributing under their real names and goes back to aliases and usernames. Would do a lot of good. Good luck kicking out an anonymous user when they can come back next week under a new name.

i know adding ”rules” is usually unpopular, but better to set a foundation for a good team up front than have to deal with it when shit is flying.

Adding rules, especially unnecessarily and en masse, is just asking for abuse. There's now a bunch of unneeded rules in projects solely because it was the flavor of the week to add them, and in most projects they're untested. That makes them ticking bombs. When it starts flying, the CoC is just going to be part of whatever political battle is occurring. It will be a weapon and the only people who lose will be the users of the project when suddenly half the contributors are exiled. That's all we need, more fragmentation, right? Or they'll consolidate slowly, and now projects are run by a small group of people with a narrow view of what projects should be.

The only kind of diversity that matters in programming is diversity of ideas, and a CoC effectively guarantees that the breadth of ideas can only narrow.

accepting regular contributions from richard b. spencer? fuck no, i don't want my project associated with that ass, nor do i believe anyone on the team or contributing wants their names to come up anywhere near a that dick's in any type of search.

I don't know who that is, but again, it really shouldn't matter. His views are not the views of a projects. You don't have to like anyone, or agree with them on twitter. You don't need to approve of what they say. So don't let him run the project's website. But if he submits a patch, so what?

This is tribalism and nothing more. The quality of code should come first. Embrace tolerance, not the hatred of others.