The Truth About Rod Vagg
medium.com
medium.com
When a project focuses on other things unrelated to the core reason why they exist things like this happen.
To the outside world these issues seem unrelated to why they use the language.
Inclusivity seems more like creating documentation in different languages rather than kick someone out over a retweet with an acceptable message to the average node user.
CoCs are bad in that they're often used as ideological purges - for joking about 'dongles' or, in this case, retweeting an article http://quillette.com/2017/07/18/neurodiversity-case-free-spe... that was on the front page of HN a few days ago. Women aren't children and won't be harmed by seeing something they may potentially disagree with, nor do they all hold the same opinions.
I would posit that this is nothing to do with Linus being a dickbag to people and everything to do with a) they focused on "getting shit working" over "purity", b) were (as best I can tell) much more open to contributions and partnerships than the BSDs, and c) expanded rapidly to cover just about every little niche there was.
Any of the BSDs (or other OSs, I guess) could have had the same viral trajectory if they'd focused on the same things instead of their ideological purity, code stability, et al.
> But does it help or does it harm?
I believe there are several studies that show increasing diversity can improve technical projects because this reduces "situations where points are never made".
> Does it really help to take people onboard who are less technically and more politically oriented?
That depends - does your project exist in a world that contains politics? Is it meant to solve problems for human beings? Both of those benefit from diversity because, and this will shock you, a very small percentage of the world is comprised of privileged white dudes.
Also, they focused on "getting shit working" over "making sure to not offend anyone".
> b) were (as best I can tell) much more open to contributions and partnerships than the BSDs
And they managed to be more "open to contributions" despite having a "dickbag" as benevolent dictator and an "hostile environment" (as you probably would put it) to beginner devs. And not having a CoC for 20 years. So maybe it's not terribly essential to be forcibly inclusive in order to be open to contributions?
> c) expanded rapidly to cover just about every little niche there was.
Again, they managed that being a non-diverse environment, by most meters of (modern) judgement. So maybe it's not so essential to be inclusive when you manage to cover all niches in no time? It was so exclusive that managed to cover everyone's needs? How's that even possible?
> I believe there are several studies that show increasing diversity can improve technical projects because this reduces "situations where points are never made".
Indeed, but you have to consider that being overly-inclusive opens the doors to bike-shedding and, for example, wanting to exclude perfectly capable programmers just because they communicate aggressively. I believe that more points are made (and I don't find difficult to believe studies prove that), but are highly capable people valued correctly in such an environment? Is it an overall gain, in all aspects?
> That depends - does your project exist in a world that contains politics?
A lot of stuff exist in a world that contains politics, but doesn't have to be political. Is medicine political? Obviously yes. Are you "including" surgeons based on their right to be there? No.
But I concede that there should be an overall body with actual powers controlling that a series of Code of Conducts, known and approved by anyone (by representation) are respected. And that this body should be periodically elected democratically. Oh, wait... we have one - it's called "Government" and the CoC are called "laws".
Having that, do we really need to tell people on Github to avoid telling others to "stop saying bullshit" because it's offensive? Do we need to make kindness mandatory? Do we need to favour inclusion over technical prowess? Sounds like the recipe for a disaster.
Yes - and Linus wasn't involved in most of them (since he delegated subtrees) which makes your "despite having a dickbag in charge" completely irrelevant.
> Maybe it's not terribly essential to be forcibly inclusive in order to be open to contributions
But you'll note I specifically said "more open [...] than the BSDs" - it wasn't an absolute. The Linux kernel is very much not open to contributions per se -but- compared with the *BSDs etc. it is a paragon of welcome.
> exclude perfectly capable programmers just because they communicate aggressively
Being able to communicate effectively - and that generally excludes "aggressively" - is an important part of being a capable (and better) programmer.
> Are you "including" surgeons based on their right to be there? No.
What?
> you have to consider that being overly-inclusive opens the doors to bike-shedding
Ironic that you call it "bike-shedding" when that was coined from a project that wasn't "overly-inclusive". Almost as if your link between the two is fanciful nonsense.
It's clear your only argument is "I don't like inclusivity" and that's fine - you're on the wrong side of history and doomed to fail.
So not having a CoC and having a dickbag in charge is OK? Cool! QED!
> Being able to communicate effectively - and that generally excludes "aggressively"
It doesn't. Aggressivity doesn't exclude efficiency. Aggressivity is a human interaction with a purpose. If used correctly it can express emphasis with amazing efficiency.
> Ironic that you call it "bike-shedding" when that was coined from a project that wasn't "overly-inclusive".
Bike-shedding is a reality in non-inclusive project like FreeBSD. Now imagine in "inclusive" projects where every word has to be carefully weighted in order to not offend anyone. People fighting not only over the color of the bike shed, but also on the political undertones of supporting bikes, on the percentage of male and/or white bike riders, all while constantly accusing each other of being threatening. Exponential bullshitting and no work done :)
> It's clear your only argument is "I don't like inclusivity"
Actually, I like it. But, in a technical project, it should always come after the actual "getting shit done" part.
> you're on the wrong side of history and doomed to fail.
Am I? I was there in the 90s, when riot grrrls were all the shit and PC peaked. I wasn't terribly impressed back then and I'm not impressed now :)
Linking to a Quilette article and screen capping abuse you receive doesn't mean you're a 'known hostile' and all the various hyperbole that's been around in the last couple of days.
The Github comment revision needs to stop. It makes it impossible for people who were not involved in the original conversation to understand what actually happened. Without a full archive of all revisions, you cannot even judge if the edits were made in good faith or if the current text represents the author's original intent. It casts doubt on everything.
The whole mess is even worse on long threads like the ones linked to. Editing a comment that other users responded to can make the responding comments look silly or stupid, or completely change the meaning of their response.
This is mostly a process thing but Github also needs to improve how edits are handled.