Messages in this thread | | | From | Chris Mason <> | Subject | Re: [PATCH] CodingStyle: Inclusive Terminology | Date | Mon, 6 Jul 2020 12:45:34 +0000 |
| |
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
| |