[david-cako]

- User doesn't like the fact that buildbot (which they think is maintained by mozilla) uses "master/slave" terminology https://github.com/rust-lang/rust-buildbot/issues/2 . Mozilla gives buildbot $15k for changing it https://blog.mozilla.org/blog/2015/12/10/mozilla-open-source...

- User doesn't like that dining philosophers is cited with some male and/or gender-neutral pronouns and placeholders (even though the original exposition was already changed to female pronouns) -- proceeds to change the rest of the pronouns to female (I guess gender-neutral didn't make sense) https://github.com/rust-lang/rust/pull/25640

- User thinks "bad code style" is offensive https://github.com/rust-lang/rust/issues/41646

- User doesn't like brotli encoding type being called "bro" https://bugzilla.mozilla.org/show_bug.cgi?id=366559#c147

- User thinks that the code of conduct is too general in its suggestions that all people be respected and treated fairly -- it needs to explicitly cite certain groups https://github.com/rust-lang/rust-www/issues/268

This stuff is absolutely ridiculous. Write a code of conduct, make sure everyone is respected, and make that the end of it. Changing documentation to gender-neutral pronouns is something I can actually get behind -- nevertheless, that's still not fair apparently.

[gcp]

User doesn't like brotli encoding type being called "bro" https://bugzilla.mozilla.org/show_bug.cgi?id=366559#c147

1) "User" is the principal engineer of most of Gecko's network stack and pointing out that using that name will lead to complaints during the standardization.

2) The code in question isn't Rust at all.

I mean why even bring this up given (2)?

[david-cako]

> (perhaps it's a mozilla cultural affect?)

I didn't know that. The fact that a lead engineer is entertaining people who are upset with "brotli" being abbreviated to "bro" is honestly case in point.

[gcp]

1) As the person who has to drive the result through standards committees, he has to consider how it will be perceived.

2) Again, what has it got to do with Rust?!

[david-cako]

If my giving examples of how mozilla as a company engages in social politics (the buildbot one is the best example) doesn't relate to rust, I don't know what to tell you.

[steveklabnik]

Mozilla does not and cannot dictate what happens with Rust, given that we operate by consensus and Mozilla does not hold a majority position in governance. This is on purpose!

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

[pornel]

Gödel incompleteness theorem strikes.

Rust goes to great lengths to keep everyone happy, but ends up putting off people like you, who don't like projects going to great lengths to keep everyone happy :)