[Etzos]

> Write a code of conduct, make sure everyone is respected, and make that the end of it.

But that's exactly what all of your examples are. In each situation the decision and action was to make things as neutral and inclusive as possible. That there are people in any given community which want things to be taken in a different direction (any direction, social or otherwise) seems like a pretty natural thing.

[david-cako]

Good luck finding these types of patches in the Linux kernel dev community. There is a very specific type of culture that spawns this kind of timewasting.

[kbenson]

You either waste a small amount of time up-front defining what's acceptable and how people should deal with each other, or you waste what's likely much more time the first time people have a major problem that could have been avoided with some sane defaults. And then you're faced with the choice to spend more time setting some sane default expectations, or you put it off until the next problem.

The real difference in why the kernel can work with that and other projects can't is the D in BDFL. What Linus says goes, so there's an ultimate arbiter (for better or worse) that can settle these problems, and set the tone. The LKML doesn't need a code of conduct because Linus is the example of conduct, which in this case is "words don't matter put up or shut up". That'f fine, as long as you're aware and okay with marginalizing the people that don't deal well with that, which can, and has happened on the LKML. But that's a choice for Linus. Rust doesn't have a BDFL, so there's no ultimate authority to define what's right or wrong for Rust and the community around it (as much as a BDFL can for something at large as a language). In that situation, a code of conduct that exists to set some sane defaults can be useful.

[Etzos]

I don't exactly see the Linux kernel dev community as being inclusive, so that's not really an apt comparison. Nor is it a language-based community. It's a very specific set of people who are expected to follow the rules and do things in a particular manner; and for them that's okay.

For a programming language community though I don't think that's the kind of approach to take. Sure, it could work and you may get some very talented people to help, but it's also arbitrarily limiting the kinds of people who can contribute and feel welcome based on the thickness of their skin, not on their technical ability. You may consider this timewasting, but I think it's more like a clever and nuanced form or marketing. Not only do you get the benefits of including more potentially skilled people into your community, you encourage them to actually get involved with the language. It seems like a worthwhile investment to me.

[RaleyField]

> kernel dev community .. timewasting

Dude what you listed are trivialities and if you consider the throughput of Rust project the time taken must surely be negligible. I wonder what Theo or Brad think about timewasting on that other paragon of a project you mentioned.

[gcp]

I wouldn't hold the Linux kernel dev community as an example of...well pretty much anything really, least of all a meritocracy.