Re: [PATCH] CodingStyle: Inclusive Terminology

[Chris Mason <clm@fb.com>]

On 5 Jul 2020, at 0:55, Willy Tarreau wrote:

> On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote:
>> +Non-inclusive terminology has that same distracting effect which is 
>> why
>> +it is a style issue for Linux, it injures developer efficiency.
>
> I'm personally thinking that for a non-native speaker it's already
> difficult to find the best term to describe something, but having to
> apply an extra level of filtering on the found words to figure whether
> they are allowed by the language police is even more difficult.

Since our discussions are public, we’ve always had to deal with 
comments from people outside the community on a range of topics.  But 
inside the kernel, it’s just a group of developers trying to help each 
other produce the best quality of code.  We’ve got a long history 
together and in general I think we’re pretty good at assuming good 
intent.

> *This*
> injures developers efficiency. What could improve developers 
> efficiency
> is to take care of removing *all* idiomatic or cultural words then. 
> For
> example I've been participating to projects using the term 
> "blueprint",
> I didn't understand what that meant. It was once explained to me and
> given that it had no logical reason for being called this way, I now
> forgot. If we follow your reasoning, Such words should be banned for
> exactly the same reasons. Same for colors that probably don't mean
> anything to those born blind.
>
> For example if in my local culture we eat tomatoes at starters and
> apples for dessert, it could be convenient for me to use "tomato" and
> "apple" as list elements to name the pointers leading to the beginning
> and the end of the list, and it might sound obvious to many people, 
> but
> not at all for many others.
>
> Maybe instead of providing an explicit list of a few words it should
> simply say that terms that take their roots in the non-technical world
> and whose meaning can only be understood based on history or local
> culture ought to be avoided, because *that* actually is the real
> root cause of the problem you're trying to address.

I’d definitely agree that it’s a good goal to keep out non-technical 
terms.  Even though we already try, every subsystem has its own set of 
patterns that reflect the most frequent contributors.

-chris