lkml.org 
[lkml]   [2020]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology
Hi Chris,

On Mon, Jul 06, 2020 at 12:45:34PM +0000, Chris Mason via Ksummit-discuss wrote:
> 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.

I don't think anybody doubts your intentions. But they say, the road to
hell is paved with good intentions.

I had a "privilege" to live in the USSR and back there Newspeak was not a
fiction but a reality.

And despite the good intent, I have a really strong feeling that this
could be a step in a wrong direction...

> > *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
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

--
Sincerely yours,
Mike.

\
 
 \ /
  Last update: 2020-07-06 18:07    [W:0.079 / U:6.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site