If you're attempting to bring people around to your point of view, you're going to repeatedly have the same argument, because you're constantly going to be encountering new people who need to be convinced. If you don't want to do that, perhaps political activism isn't for you.
> the vast majority of arguments in that area have been had already. That's some of the primary value provided by their wiki: a repository of past arguments and refutations, to avoid having to revisit them every time.
To be more accurate, it's a repository of refutations that GeekFeminism asserts answer the argument. The Discovery Institute also has a repository of what it asserts are refutations of evolution, but (assuming you're not a creationist) I doubt you'd rush out and read them all just on my say-so. Same deal here.
Granted. I've certainly spent a pile of time commenting in this thread, and none of it was new. But just as it's reasonable to link to a FAQ rather than answer the same question for the Nth time, it's also not unreasonable to link to a detailed response to an argument rather than reiterating it for the Nth time, especially when it's far better supported and researched than something off-the-cuff.
> To be more accurate, it's a repository of refutations that GeekFeminism asserts answer the argument.
Sure. And if someone really wanted to try to argue against those points, by all means do so (in an appropriate forum and context, not on a project mailing list for instance). But ignoring those arguments because of the site they're on or the people who made them is a perfectly sensible reason to end the discussion, just as if someone said "I'm ignoring everything you just said, my arguments still hold, so there".
I'm disinclined to read a pile of arguments in favor of creationism for exactly the same reasons I'm disinclined to directly get into an argument with a creationist: there's no possible way it's worth my time to do so. If I've found myself making some set of poor life choices that led me to become involved in such a debate, then of course I'd read and respond to arguments made in it, as with any other discussion. I'd also be inclined to consider whether I'm primarily trying to convince that person, or primarily convince the set of as-yet uncommitted bystanders while writing off that person as likely a hopeless cause.
As for base assumptions, I see we also differ wildly. Mine are:
* Code quality matters above all else.
* People that don't contribute code don't get a seat at the table.
* There's no inherent value in letting as many people as possible contribute to the project. Quality over quantity.
I'm leaving out anything having to do with feminism because we're not going to agree on anything about it.
There's another assumption you're implying but leaving out: "The set of people who show up and contribute under those conditions will inherently be the best and produce the best results". And that assumption is subject to a lot of confirmation bias; if you don't set out to question that assumption, you'll tend to get results that give you no reason to doubt it, precisely because it's harder to notice the absence of something.
Coding well is damn hard, by its very nature it's not a very inclusive thing. Very few have the capacity to do it well. I prefer to focus on them than on the masses that will never be great coders. I don't think pretending like everyone can and should be involved is useful.
I'm a minority from a poor background. No one encouraged me to code, I couldn't even afford the tools I needed. I would read computer magazines in the supermarket and write psudeo-code on paper at home. I'm now a very successful software engineer. Regardless of how unimportant you think my own experience is, it IS quite possible to succeed if you're talented and from an under represented group, no "safe spaces" needed. Just tenacity, an interest in the subject matter and self-drive.
For the people who do know how to code, there's an additional barrier of dealing with people who (for a few examples) like to shout about how anyone who could possibly write such terrible code should die to save important people the trouble of dealing with them, or who talk about "how to explain to your wife or girlfriend", or who give conference presentations featuring lingerie models and pornstars. Nobody should have to put up with that, or should be told to grow a thicker skin. Not wanting to put up with that does not mean someone doesn't know how to code. And allowing that kind of thing in your project disproportionately tends to exclude some groups more than others.
People are centralizing the philosophy behind a project more than is necessary.
As for communities, no, "fork it" is not a universal solution to problems within communities, conferences, professional events, and other environments. But even in cases where the approach finally ends up being to go start new, more welcoming environments, that's still a case for codes of conduct and similar; even if you're successful in moving a community elsewhere, if the same set (or a new set) of awful people show up with their same behavior, you need something to show what standards a community expects. And much like the Zen of Python, "explicit is better than implicit".
I'm also noticing a conspicuous lack of any response to the actual behaviors I was referring to; you're dismissing that as behavior that someone ought to have to tolerate or go start their own project. This problem ought to be as universally recognized in projects as buffer overflows are. And rather than playing whack-a-mole, it makes sense to try to get better solutions in place. For instance, getting support from major hosting sites, or otherwise creating larger meta-communities of people who agree that this is a bad idea, to avoid having a different set of standards (or lack of standards) in every project. And just as it's a bad idea to write your own software license rather than using a standard one, it's a bad idea to write your own code of conduct rather than using a standard one.
Absolutely. Why should I judge anyone? I'm not forced to use their project. Last I checked lingerie and porn weren't illegal. If someone wants to represent themselves like that, then more power to them.
Not every project is a corporate project and not all are going to come from that politically correct environment.
I would no sooner tell someone that they couldn't fill a project with sexually explicit terms than I would tell a songwriter to not use sexually explicit lyrics.
Nothing stops people from acting that way. It's not illegal, nor should it be. But I'm looking forward to a world where when someone tries everyone else just looks at them funny and dismisses them immediately, so that people stop trying.
Which brings us full circle back to the original point: given a choice (and it is a choice) between which set of people to exclude from a community, I know which set I'd prefer. You seem to have a different preference, and you're welcome to it. I look forward to that point of view losing all credibility and respect in the industry as a whole, and an increasing number of people are working towards that goal. Have a nice day.
There's a difference between silencing a point of view and refusing to repeatedly have the same argument. New arguments need new information, and the vast majority of arguments in that area have been had already. That's some of the primary value provided by their wiki: a repository of past arguments and refutations, to avoid having to revisit them every time.
Project mailing lists and other communication channels, for instance, are the wrong place for repeated introductory conversations demanding justifications for a code of conduct. And that's a very common problem.
Considering I didn't start with the set of base assumptions I have now, and had to learn them over time, I'm always willing to question them. That I don't personally find any of your arguments even remotely compelling towards that end doesn't make those assumptions immutable.
To explicitly state some of the assumptions that I suspect we disagree on: 1) If you refuse to exclude anyone from a project, then you're by default excluding people who are not willing to put up with a hostile environment. 2) Since you can't avoid excluding people, better to exclude people who make the project less welcoming. 3) Don't let the people you want to exclude write the policy. 4) Don't let the people who would fare just fine in a project without a code of conduct drive the requirements; get the requirements from people who wouldn't.
Apart from that, the other reason I don't particularly care about having this argument here is that it's unlikely to have as much effect as having it elsewhere.