Re: [PATCH] CodingStyle: Inclusive Terminology

Re: [PATCH] CodingStyle: Inclusive Terminology

[Michael Shigorin]

	Hi guys,
do you think playing with words will really get you anywhere
or help anyone?

> +On the triviality of replacing words

You're not going to make white black, make a native African
white, or fix age-old crimes by this "triviality".

You're only going to sort of please those who actually
hate you -- and everyone creative -- because they envy.
Or rather subdue to their twisted will (what's next on
the list, cannibalism aproval extorted from you?).


Have you seen this post by a teacher?
https://www.reddit.com/r/TrueOffMyChest/comments/gulna2/i_used_to_teach_in_a_black_inner_city_school/

Do you believe that a typical late-USSRish quota system
for those who do not want to learn will help them learn?

I'd rather start with helping those who DO want to learn
by protecting them from their disruptive environment that
pulls them back into morass.


That whole "inclusivity" agenda is extremely toxic and
hypocritical -- this king is so naked that it takes a late
Soviet-style propaganda and party-bashing to make people
shut up and not even confess that a black criminal's life
might only be an excuse and not the reason to murder and
pillage zounds of other people of any skin color -- with
only some black people daring to point out that the said
criminal was once threating a pregnant black woman with
his gun aimed at her baby not yet even born, for example.

That orwellish "inclusivity" that excludes on intent,
ill-meaning "goodwill", silencing "free speech" is what
seems to be going to bury the country where many of you
work and live.

I wouldn't say I wish USA good health and good luck --
it is the country that ruined USSR on intent and that
ruined former Ukraine on intent (I used to live in Kiev
since early 1980s up till 2014 when USA-made nazi coup
destroyed the country).  But I should at least warn you
that you're playing with demon core, not even with fire;
you're rushing to support moral rapists when you could
at least stay where you are.


I write that as a person made in USSR back in 1979,
just in case.  It was still Russia, but I remember
those kitchen talks that are no more needed.  And I
remember a "why do you learn?" question back in 1993.

You can argue and call me an intolerant liar, welcome.
Time will tell and you have no power over it, comrades.


PS: those who find this kind of abuse unacceptable
are welcome to Russia if they fail to protect their
homeland -- we've learned it all too well already,
so we *do* value our freedom -- and stand by it.
Look for Innopolis.

PPS: James, kudos to you!  Prepare for your share
of "democratic shelling" though.  Hope you stand.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [PATCH] CodingStyle: Inclusive Terminology

[Pavel Machek]

Hi!

> +On the triviality of replacing words
> +====================================
> +
> +The African slave trade was a brutal system of human misery deployed at
> +global scale. Some word choice decisions in a modern software project
> +does next to nothing to compensate for that legacy. So why put any
> +effort into something so trivial in comparison? Because the goal is not
> +to repair, or erase the past. The goal is to maximize availability and
> +efficiency of the global developer community to participate in the Linux
> +kernel development process.

I'd preffer to keep politics out of kernel.

> +of 'blacklist' is devoid of a historical racial connection. However, one
> +thought exercise is to consider replacing 'blacklist/whitelist' with
> +'redlist/greenlist'. Realize that the replacement only makes sense if
> +you have been socialized with the concepts that 'red/green' implies
> +'stop/go'. Colors to represent a policy requires an indirection. The

So you are trying to blacklist colors. That's stupid.

> +socialization of 'black/white' to have the connotation of
> +'impermissible/permissible' does not support inclusion.
> +
> +Inclusion == global developer community efficiency.

It seems inclusion == reason to push politics and questionable patches
into kernel. That is opposite of efficiency.

:-(
										Pavel
 
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] CodingStyle: Inclusive Terminology

[Dan Williams]

On Sat, Jul 4, 2020 at 5:41 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote:
> > Recent events have prompted a Linux position statement on inclusive
> > terminology. Given that Linux maintains a coding-style and its own
> > idiomatic set of terminology here is a proposal to answer the call to
> > replace non-inclusive terminology.
> >
> > Cc: Jonathan Corbet <corbet@lwn.net>
> > Cc: Kees Cook <keescook@chromium.org>
> > Signed-off-by: Chris Mason <clm@fb.clm>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>
> (nit: isn't this a Co-developed-by chain, not a SoB chain?)
>
> Acked-by: Kees Cook <keescook@chromium.org>
>
> Comments below...
>
> > ---
> >  Documentation/process/coding-style.rst          |   12 ++++
> >  Documentation/process/inclusive-terminology.rst |   64 +++++++++++++++++++++++
> >  Documentation/process/index.rst                 |    1
> >  3 files changed, 77 insertions(+)
> >  create mode 100644 Documentation/process/inclusive-terminology.rst
> >
> > diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
> > index 2657a55c6f12..4b15ab671089 100644
> > --- a/Documentation/process/coding-style.rst
> > +++ b/Documentation/process/coding-style.rst
> > @@ -319,6 +319,18 @@ If you are afraid to mix up your local variable names, you have another
> >  problem, which is called the function-growth-hormone-imbalance syndrome.
> >  See chapter 6 (Functions).
> >
> > +For symbol names, avoid introducing new usage of the words 'slave' and
> > +'blacklist'. Recommended replacements for 'slave' are: 'secondary',
> > +'subordinate', 'replica', 'responder', 'follower', 'proxy', or
> > +'performer'.  Recommended replacements for blacklist are: 'blocklist' or
> > +'denylist'.
>
> Keeping "master" in a "master/slave" pairing (i.e. replacing only
> "slave") seems incomplete to me. If "master" is paired with "slave", it
> should be replaced too. Potential examples: 'primary', 'leader', 'principle',
> 'controller', 'sender', 'initial'.

Yes, this matches Andy's feedback, will add.

> Similarly, for "whitelist/blacklist", "whitelist" needs to replaced when
> "blacklist" has been. For example, seccomp documentation[1] uses
> "allow-list" and "deny-list".
>
> [1] https://man7.org/linux/man-pages/man2/seccomp.2.html

Oh, good to know will make that change.

> > +Exceptions for introducing new usage is to maintain a userspace ABI, or
>
> and API?

True, yes, the intent was "don't break userspace" for terminology replacement.

>
> > +when updating code for an existing (as of 2020) hardware or protocol
> > +specification that mandates those terms. For new specifications consider
> > +translating specification usage of the terminology to the kernel coding
> > +standard where possible. See :ref:`process/inclusive-terminology.rst
> > +<inclusiveterminology>` for details.
>
> Let's add:
>
>  Where possible, old instances of this language should be replaced when
>  it is not tied to external specifications nor userspace ABI/API.

Sounds good to me.

>
> >
> >  5) Typedefs
> >  -----------
> > diff --git a/Documentation/process/inclusive-terminology.rst b/Documentation/process/inclusive-terminology.rst
> > new file mode 100644
> > index 000000000000..a8eb26690eb4
> > --- /dev/null
> > +++ b/Documentation/process/inclusive-terminology.rst
> > @@ -0,0 +1,64 @@
> > +.. _inclusiveterminology:
> > +
> > +Linux kernel inclusive terminology
> > +==================================
> > +
> > +The Linux kernel is a global software project, and in 2020 there was a
> > +global reckoning on race relations that caused many organizations to
> > +re-evaluate their policies and practices relative to the inclusion of
> > +people of African descent. This document describes why the 'Naming'
> > +section in :ref:`process/coding-style.rst <codingstyle>` recommends
> > +avoiding usage of 'slave' and 'blacklist' in new additions to the Linux
> > +kernel.
>
> ... usage of 'master/slave', 'slave', 'whitelist/blacklist', and
> 'blacklist' in the Linux kernel.

Yes, but as I'm reading this thread backwards I've already agreed to
just push the coding-style change in isolation.

>
> > +
> > +On the triviality of replacing words
> > +====================================
> > +
> > +The African slave trade was a brutal system of human misery deployed at
> > +global scale. Some word choice decisions in a modern software project
> > +does next to nothing to compensate for that legacy. So why put any
> > +effort into something so trivial in comparison? Because the goal is not
> > +to repair, or erase the past. The goal is to maximize availability and
> > +efficiency of the global developer community to participate in the Linux
> > +kernel development process.
> > +
> > +Word choice and developer efficiency
> > +====================================
> > +
> > +Why does any software project go through the trouble of developing a
> > +document like :ref:`process/coding-style.rst <codingstyle>`? It does so
> > +because a common coding style maximizes the efficiency of both
> > +maintainers and developers. Developers learn common design patterns and
> > +idiomatic expressions while maintainers can spot deviations from those
> > +norms. Even non-compliant whitespace is considered a leading indicator
> > +to deeper problems in a patchset. Coding style violations are known to
> > +take a maintainer "out of the zone" of reviewing code. Maintainers are
> > +also sensitive to word choice across specifications and often choose to
> > +deploy Linux terminology to replace non-idiomatic word-choice in a
> > +specification.
> > +
> > +Non-inclusive terminology has that same distracting effect which is why
> > +it is a style issue for Linux, it injures developer efficiency.
> > +
> > +Of course it is around this point someone jumps in with an etymological
> > +argument about why people should not be offended. Etymological arguments
> > +do not scale. The scope and pace of Linux to reach new developers
> > +exceeds the ability of historical terminology defenders to describe "no,
> > +not that connotation". The revelation of 2020 was that black voices were
> > +heard on a global scale and the Linux kernel project has done its small
> > +part to answer that call as it wants black voices, among all voices, in
> > +its developer community.
> > +
> > +Really, 'blacklist' too?
> > +========================
> > +
> > +While 'slave' has a direct connection to human suffering the etymology
> > +of 'blacklist' is devoid of a historical racial connection. However, one
> > +thought exercise is to consider replacing 'blacklist/whitelist' with
> > +'redlist/greenlist'. Realize that the replacement only makes sense if
> > +you have been socialized with the concepts that 'red/green' implies
> > +'stop/go'. Colors to represent a policy requires an indirection. The
> > +socialization of 'black/white' to have the connotation of
> > +'impermissible/permissible' does not support inclusion.
> > +
> > +Inclusion == global developer community efficiency.
>
> Let's add:
>
>  Beyond just Linux
>  =================
>
>  For those of us in the kernel community involved in specification
>  development or similar larger ecosystem conversations, please help
>  steer those discussions to avoid these terms in new specifications
>  or APIs.

I agree with this statement and am interested in getting connected to
those conversations, but this may be a bit too much advocacy to expect
in kernel documentation.

Re: [PATCH] CodingStyle: Inclusive Terminology

[Pavel Begunkov]

On 04/07/2020 23:02, Dan Williams wrote:
> Recent events have prompted a Linux position statement on inclusive
> terminology. Given that Linux maintains a coding-style and its own
> idiomatic set of terminology here is a proposal to answer the call to
> replace non-inclusive terminology.
> 
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Kees Cook <keescook@chromium.org>
> Signed-off-by: Chris Mason <clm@fb.clm>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
>  Documentation/process/coding-style.rst          |   12 ++++
>  Documentation/process/inclusive-terminology.rst |   64 +++++++++++++++++++++++
>  Documentation/process/index.rst                 |    1 
>  3 files changed, 77 insertions(+)
>  create mode 100644 Documentation/process/inclusive-terminology.rst
> 
> diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
> index 2657a55c6f12..4b15ab671089 100644
> --- a/Documentation/process/coding-style.rst
> +++ b/Documentation/process/coding-style.rst
> @@ -319,6 +319,18 @@ If you are afraid to mix up your local variable names, you have another
>  problem, which is called the function-growth-hormone-imbalance syndrome.
>  See chapter 6 (Functions).
>  
> +For symbol names, avoid introducing new usage of the words 'slave' and
> +'blacklist'. Recommended replacements for 'slave' are: 'secondary',
> +'subordinate', 'replica', 'responder', 'follower', 'proxy', or
> +'performer'.  Recommended replacements for blacklist are: 'blocklist' or
> +'denylist'.

"Subordinate" means that they are unequal, and inequality is a big issue. This
should be forbidden as well. And what with "secondary"? Are you implying that
one better than another? That's shouting that people from the second world
countries don't have right to be included, this can't be good. Are you trying
to exclude me? That deeply hurts me, don't you care?
How about killing all words that mean "ownership" or "owning" then? And what
with that "kill"? It's everywhere, and it definitely means killing a person. That's
one meaning at least... but we don't care about other interpretations, do we?

...
> +Word choice and developer efficiency
> +====================================
> +
> +Why does any software project go through the trouble of developing a
> +document like :ref:`process/coding-style.rst <codingstyle>`? It does so
> +because a common coding style maximizes the efficiency of both
> +maintainers and developers. Developers learn common design patterns and
> +idiomatic expressions while maintainers can spot deviations from those
> +norms. Even non-compliant whitespace is considered a leading indicator
> +to deeper problems in a patchset. Coding style violations are known to
> +take a maintainer "out of the zone" of reviewing code. Maintainers are
> +also sensitive to word choice across specifications and often choose to
> +deploy Linux terminology to replace non-idiomatic word-choice in a
> +specification.
> +
> +Non-inclusive terminology has that same distracting effect which is why
> +it is a style issue for Linux, it injures developer efficiency.

Code styles also exist to not think about things that doesn't matter, as
well as terminologies do -- you see it, and the meaning is apparent. And
that betrays the whole idea when you replace well-known terms with some
random words.
Well, if you're trying to point people what to say and how to think,
could you please __at least__ be consistent? That would be really nice.

Let me outline -- discrimination is an issue. And creating a common
vocabulary can be pretty useful. But instead of it being helpful, the only
thing I see here is ill-conceived and pretty arrogant essay.

-- 
Pavel Begunkov

Re: [PATCH] CodingStyle: Inclusive Terminology

[Arvind Sankar]

On Sun, Jul 05, 2020 at 06:55:05AM +0200, 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. *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.

While I agree that using terms that can only be understood given a
cultural context that not everyone may share, I would think that better
examples would be references to movies/novels etc.

Though I'm not sure if blueprint translates literally into other
languages, it did actually have a logical reason, viz engineering
drawings used to be blue/white. But logical reasons don't have to exist.
In the case of colors, for example, using red-black tree doesn't exclude
blind people, precisely because there is no logical reason for using the
colors red and black, or even colors at all, so it's not as if you gain
any additional insight into the structure if you are able to see the
colors. It just needs _some_ arbitrary labels for distinguishing two
classes of nodes, it could just as well have been named A-B tree or 0-1
tree or whatever. I don't think there is any concise way to label them
that conveys anything useful about how they're used in the data
structure -- you just have to learn about the structure and how it's
used. This isn't the case with whitelist/blacklist, where those colors
actually have connotations about what the two lists mean.

Re: [PATCH] CodingStyle: Inclusive Terminology

[Tibor Raschko]

Sending the wrong message
===========================

I'm pretty sure everybody agrees that being inclusive is more than just
using the right words. Being truly inclusive means not caring about the
origin, birth, age, sex, skin color (amongst other things) at all. This
means not judging people based on these factors, and being friendly,
inviting and supportive with everybody in everyday life by default. On
the street, in hallways and rooms, and on the internet. This behavior
also includes using words and phrases that are non-offensive. So as a
result, the proposed patch advocates avoiding words such as "slave" and
"blacklist".

However, as it was already said in this discussion by other parties,
"context is everything". Quite ironically, this was said in a slightly
different context, but it doesn't change the importance and general
truth of these words. I'll go out on a limb and claim that nobody who
wrote "master-slave" during development of a device driver, or used the
word "blacklist" was actually thinking of African people or human
slavery.  In the context of the Linux kernel (and in computing in
general), these words have a long history and have zero bad connotation,
no racism, and absolutely null offense.  One could argue that
recommending to retroactively remove such references (which the original
proposal does) assumes that these were offensive, hence suggesting to a
certain degree that past developers who have used these words were
possibly racists. Retroactively removing those occurrences from code is
thus, I honestly think, disrespecting and insulting to the original
authors. Because why remove them if they didn't mean anything bad? And
before you say "because those instances could still be interpreted as
offensive", I'll get to that soon.

The proposal is just a surface treatment
===========================

... and a bad one at that. The "black" in "blacklist" has nothing to do
with African or Afro-American people. No matter how many occurrences of
"black" we eradicate from our dictionary, the word "black" will always
have bad connotations. This connotation stems from darkness, the absence
of beautiful colors, and historically from the coldness, darkness and
insecurity of the night. Dan W. dismisses this by saying this is an
etymological argument, but we cannot dismiss arguments just because they
are unbeneficial (is that even a word?) to our cause. The true problem
is not that the word "black" has bad connotations, but that people with
dark skin color have been labeled with a word that has a bad
connotation. If we don't want to be offensive, (as a small step) we must
stop thinking of African and Afro-American people as "black" and ban
this labeling of them. Note the big difference: Instead of banning the
use of a simple color in some contexts which have nothing to do with
oppression, hate or slavery, we should instead stop referring to groups
of people with a word that incites bad feelings. For this reason, I
argue that banning "blacklist" is just a surface treatment that doesn't
recognize the true problem behind it, and even if implemented will stay
ineffective. Accepting this proposal is like fixing an error message in
the kernel logs by simply removing the error message instead of fixing
the underlying bug. To fix the bug in our language, we must stop
referring to "black" people as black people. A measure where proponents
of the patch fail at most.

Being respectful
===========================

The case for "slave" is a bit different, obviously, because the
etymology here does link to actual human slavery. Again, it is important
to note the context however. In computing, this means something
completely different, end of sentence. Supporters of the patch will come
and say, "it doesn't need to be meant offensively to be taken
offensively". That's true, of course, but only if it is a
misunderstanding, which in the computing context has zero chance. If you
know and understand what the other party *really* meant, then something
that wasn't meant offensively cannot be taken offensively. The right
word here is not "offensive", but one or more of "uncomfortable",
"disturbing", or "upsetting". Now *that* is understandable. If you have
a history of you or your ancestors been oppressed, then talking about
slavery understandably generates unwelcome emotional reactions. But this
has nothing to do with inclusion, racism, or hate. However, because we
don't want to emotionally upset people, I actually support avoiding
references to "slave" in the future. Importantly though, this support is
out of respect, and not because it has anything to do with being
offensive. In this context, we should, and for correctness sake must,
stop referring to "offensiveness".

Though even this logic is borderline: just recently, half a million
people have fallen victim to COVID-19 in over just a couple of months.
The number of affected relatives are probably 2-3x of that, who are now
emotionally shaken and uncomfortable about talking about the virus.
Imagine where we would be now (or where we will be in half a year) if we
stopped referring to COVID to avoid emotionally upsetting these people.

About that argument with efficiency
===========================

The patch author goes into detail to "illustrate" how avoiding these
words will improve efficiency. I'm sorry to call this out, but this is
utterly bogus and distracting from the issue at hand. First of all, not
any maintainer has been slowed done or has worked less efficiently
because they saw the word "blacklist" or "slave" in the kernel sources.
These *technical* phrases are not like bad code formatting where
disconformity leads to worse readability or makes the coding intent
harder to follow or understand. Quite the contrary, if anybody read the
proposed "denylist" instead of "blacklist", they will stop for a second,
think "what an odd choice of words...", and if it wasn't for the current
black-lives-matter movement, would have a year ago probably even
refactored the code (or requested a v2-patch) with the usual terminology
of "blacklist". In other words, this argument has zero real-life basis
and will, if implemented, achieve the opposite effect of what it is
claiming.

If we do this, there is no end to politics
===========================

Let me start with an example. The patch author neglectfully forgets
about proposing to ban "whitelist", not just "blacklist". If we agree
that "blacklist" is wrong because it assumes that everything "black" is
always bad (and thus black people'd be bad), then obviously we *have to*
remove whitelist too. Because "whitelist" then assumes that everything
"white" is always good, and now since we're unable to ignore the
reference to skin-color, so this is just as racist (actually even
worse), suggesting white supremacy. It is obvious that whoever thought
out the exclusion of "blacklist" didn't think this through. But we all
know, these words to be replaced all stem from outside our community,
and the current patch is not the result of careful consideration, but
the result of giving-in to external pressure, and to political and media
waves. The Linux community should stand strong and be inclusive by
*being* welcoming, friendly and helpful to everybody irrespective of
skin color, not by *saying* what current political activists expect us
to say. It might even be better to stop talking about skin color in the
context of kernel development altogether, because skin color doesn't
matter here. Here people judge others by technical competency. Any
discussions otherwise are fueled by external factors and are a
distraction. Note this does *not* mean we turn our backs to racism or
offensive behavior. If we see any such poisonous activity among our
circles now or in the future, we must and will single them out and teach
them better, and for incorrigible cases we distance ourselves from them.
But these will be one-off cases that will be handled appropriately.
Unless it becomes a common problem among Linux developers, it is not our
responsibility to write down each and every desirable human behavior
(again, see top about "sending the wrong message"). We've successfully
avoided pests from infecting our circles in the past and we'll continue
to do so. Avoiding the word "blacklist" makes no difference here. How do
I know? Because let's be real: The use of the word "blacklist" has not
deterred a developer from joining our community yet... for about 25
years now. On the other hand this discussion is now wasting everybody's
time. With that last sentence in mind, sorry for this mail turning out
so long.

Raschko T.

Re: [PATCH] CodingStyle: Inclusive Terminology

[Chris Mason]

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

Re: [PATCH] CodingStyle: Inclusive Terminology

[Daniel Palmer]

Hi Willy,

On Sun, 5 Jul 2020 at 13:55, Willy Tarreau <w@1wt.eu> wrote:

> I'm personally thinking that for a non-native speaker it's already
> difficult to find the best term to describe something,

I'm a nobody in the kernel world but this point made me think.

I'm a native English speaker but I don't live in an English speaking
place and my experience is that a lot of technology terms have been
directly imported from English into the local language almost as-is.

In my case master/slave have been directly transliterated into
Japanese as masuta and sureebu and exists like that in technical
documentation for example:
https://www.analog.com/jp/analog-dialogue/articles/introduction-to-spi-interface.html#

I can imagine that by changing terminology that has been in use for so
long that it's been imported into other languages directly or is
common enough that non-native speakers know what it means might have
exactly the opposite result by excluding people that aren't native
English speakers and can't decode synonyms that are obvious to a
native speaker.

Cheers,

Daniel

Re: [PATCH] CodingStyle: Inclusive Terminology

[Willy Tarreau]

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

Willy

Re: [PATCH] CodingStyle: Inclusive Terminology

[Kees Cook]

On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote:
> Recent events have prompted a Linux position statement on inclusive
> terminology. Given that Linux maintains a coding-style and its own
> idiomatic set of terminology here is a proposal to answer the call to
> replace non-inclusive terminology.
> 
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Kees Cook <keescook@chromium.org>
> Signed-off-by: Chris Mason <clm@fb.clm>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>

(nit: isn't this a Co-developed-by chain, not a SoB chain?)

Acked-by: Kees Cook <keescook@chromium.org>

Comments below...

> ---
>  Documentation/process/coding-style.rst          |   12 ++++
>  Documentation/process/inclusive-terminology.rst |   64 +++++++++++++++++++++++
>  Documentation/process/index.rst                 |    1 
>  3 files changed, 77 insertions(+)
>  create mode 100644 Documentation/process/inclusive-terminology.rst
> 
> diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
> index 2657a55c6f12..4b15ab671089 100644
> --- a/Documentation/process/coding-style.rst
> +++ b/Documentation/process/coding-style.rst
> @@ -319,6 +319,18 @@ If you are afraid to mix up your local variable names, you have another
>  problem, which is called the function-growth-hormone-imbalance syndrome.
>  See chapter 6 (Functions).
>  
> +For symbol names, avoid introducing new usage of the words 'slave' and
> +'blacklist'. Recommended replacements for 'slave' are: 'secondary',
> +'subordinate', 'replica', 'responder', 'follower', 'proxy', or
> +'performer'.  Recommended replacements for blacklist are: 'blocklist' or
> +'denylist'.

Keeping "master" in a "master/slave" pairing (i.e. replacing only
"slave") seems incomplete to me. If "master" is paired with "slave", it
should be replaced too. Potential examples: 'primary', 'leader', 'principle',
'controller', 'sender', 'initial'.

Similarly, for "whitelist/blacklist", "whitelist" needs to replaced when
"blacklist" has been. For example, seccomp documentation[1] uses
"allow-list" and "deny-list".

[1] https://man7.org/linux/man-pages/man2/seccomp.2.html

> +Exceptions for introducing new usage is to maintain a userspace ABI, or

and API?

> +when updating code for an existing (as of 2020) hardware or protocol
> +specification that mandates those terms. For new specifications consider
> +translating specification usage of the terminology to the kernel coding
> +standard where possible. See :ref:`process/inclusive-terminology.rst
> +<inclusiveterminology>` for details.

Let's add:

 Where possible, old instances of this language should be replaced when
 it is not tied to external specifications nor userspace ABI/API.

>  
>  5) Typedefs
>  -----------
> diff --git a/Documentation/process/inclusive-terminology.rst b/Documentation/process/inclusive-terminology.rst
> new file mode 100644
> index 000000000000..a8eb26690eb4
> --- /dev/null
> +++ b/Documentation/process/inclusive-terminology.rst
> @@ -0,0 +1,64 @@
> +.. _inclusiveterminology:
> +
> +Linux kernel inclusive terminology
> +==================================
> +
> +The Linux kernel is a global software project, and in 2020 there was a
> +global reckoning on race relations that caused many organizations to
> +re-evaluate their policies and practices relative to the inclusion of
> +people of African descent. This document describes why the 'Naming'
> +section in :ref:`process/coding-style.rst <codingstyle>` recommends
> +avoiding usage of 'slave' and 'blacklist' in new additions to the Linux
> +kernel.

... usage of 'master/slave', 'slave', 'whitelist/blacklist', and
'blacklist' in the Linux kernel.

> +
> +On the triviality of replacing words
> +====================================
> +
> +The African slave trade was a brutal system of human misery deployed at
> +global scale. Some word choice decisions in a modern software project
> +does next to nothing to compensate for that legacy. So why put any
> +effort into something so trivial in comparison? Because the goal is not
> +to repair, or erase the past. The goal is to maximize availability and
> +efficiency of the global developer community to participate in the Linux
> +kernel development process.
> +
> +Word choice and developer efficiency
> +====================================
> +
> +Why does any software project go through the trouble of developing a
> +document like :ref:`process/coding-style.rst <codingstyle>`? It does so
> +because a common coding style maximizes the efficiency of both
> +maintainers and developers. Developers learn common design patterns and
> +idiomatic expressions while maintainers can spot deviations from those
> +norms. Even non-compliant whitespace is considered a leading indicator
> +to deeper problems in a patchset. Coding style violations are known to
> +take a maintainer "out of the zone" of reviewing code. Maintainers are
> +also sensitive to word choice across specifications and often choose to
> +deploy Linux terminology to replace non-idiomatic word-choice in a
> +specification.
> +
> +Non-inclusive terminology has that same distracting effect which is why
> +it is a style issue for Linux, it injures developer efficiency.
> +
> +Of course it is around this point someone jumps in with an etymological
> +argument about why people should not be offended. Etymological arguments
> +do not scale. The scope and pace of Linux to reach new developers
> +exceeds the ability of historical terminology defenders to describe "no,
> +not that connotation". The revelation of 2020 was that black voices were
> +heard on a global scale and the Linux kernel project has done its small
> +part to answer that call as it wants black voices, among all voices, in
> +its developer community.
> +
> +Really, 'blacklist' too?
> +========================
> +
> +While 'slave' has a direct connection to human suffering the etymology
> +of 'blacklist' is devoid of a historical racial connection. However, one
> +thought exercise is to consider replacing 'blacklist/whitelist' with
> +'redlist/greenlist'. Realize that the replacement only makes sense if
> +you have been socialized with the concepts that 'red/green' implies
> +'stop/go'. Colors to represent a policy requires an indirection. The
> +socialization of 'black/white' to have the connotation of
> +'impermissible/permissible' does not support inclusion.
> +
> +Inclusion == global developer community efficiency.

Let's add:

 Beyond just Linux
 =================

 For those of us in the kernel community involved in specification
 development or similar larger ecosystem conversations, please help
 steer those discussions to avoid these terms in new specifications
 or APIs.


> diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
> index f07c9250c3ac..ed861f6f8d25 100644
> --- a/Documentation/process/index.rst
> +++ b/Documentation/process/index.rst
> @@ -27,6 +27,7 @@ Below are the essential guides that every developer should read.
>     submitting-patches
>     programming-language
>     coding-style
> +   inclusive-terminology
>     maintainer-pgp-guide
>     email-clients
>     kernel-enforcement-statement
> 

-- 
Kees Cook

Re: [PATCH] CodingStyle: Inclusive Terminology

[Randy Dunlap]

On 7/4/20 1:02 PM, Dan Williams wrote:
> Recent events have prompted a Linux position statement on inclusive
> terminology. Given that Linux maintains a coding-style and its own
> idiomatic set of terminology here is a proposal to answer the call to
> replace non-inclusive terminology.
> 
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Kees Cook <keescook@chromium.org>
> Signed-off-by: Chris Mason <clm@fb.clm>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
>  Documentation/process/coding-style.rst          |   12 ++++
>  Documentation/process/inclusive-terminology.rst |   64 +++++++++++++++++++++++
>  Documentation/process/index.rst                 |    1 
>  3 files changed, 77 insertions(+)
>  create mode 100644 Documentation/process/inclusive-terminology.rst
> 
> diff --git a/Documentation/process/inclusive-terminology.rst b/Documentation/process/inclusive-terminology.rst
> new file mode 100644
> index 000000000000..a8eb26690eb4
> --- /dev/null
> +++ b/Documentation/process/inclusive-terminology.rst
> @@ -0,0 +1,64 @@
> +.. _inclusiveterminology:
> +
> +Linux kernel inclusive terminology
> +==================================
> +
> +The Linux kernel is a global software project, and in 2020 there was a
> +global reckoning on race relations that caused many organizations to
> +re-evaluate their policies and practices relative to the inclusion of
> +people of African descent. This document describes why the 'Naming'
> +section in :ref:`process/coding-style.rst <codingstyle>` recommends
> +avoiding usage of 'slave' and 'blacklist' in new additions to the Linux
> +kernel.
> +
> +On the triviality of replacing words
> +====================================
> +
> +The African slave trade was a brutal system of human misery deployed at
> +global scale. Some word choice decisions in a modern software project
> +does next to nothing to compensate for that legacy. So why put any

   do next to nothing

> +effort into something so trivial in comparison? Because the goal is not
> +to repair, or erase the past. The goal is to maximize availability and
> +efficiency of the global developer community to participate in the Linux
> +kernel development process.
> +
> +Word choice and developer efficiency
> +====================================
> +
> +Why does any software project go through the trouble of developing a
> +document like :ref:`process/coding-style.rst <codingstyle>`? It does so
> +because a common coding style maximizes the efficiency of both
> +maintainers and developers. Developers learn common design patterns and
> +idiomatic expressions while maintainers can spot deviations from those
> +norms. Even non-compliant whitespace is considered a leading indicator
> +to deeper problems in a patchset. Coding style violations are known to
> +take a maintainer "out of the zone" of reviewing code. Maintainers are
> +also sensitive to word choice across specifications and often choose to
> +deploy Linux terminology to replace non-idiomatic word-choice in a

                                                     word choice

> +specification.
> +
> +Non-inclusive terminology has that same distracting effect which is why
> +it is a style issue for Linux, it injures developer efficiency.

                       for Linux:

> +
> +Of course it is around this point someone jumps in with an etymological
> +argument about why people should not be offended. Etymological arguments
> +do not scale. The scope and pace of Linux to reach new developers
> +exceeds the ability of historical terminology defenders to describe "no,
> +not that connotation". The revelation of 2020 was that black voices were
> +heard on a global scale and the Linux kernel project has done its small
> +part to answer that call as it wants black voices, among all voices, in
> +its developer community.
> +
> +Really, 'blacklist' too?
> +========================
> +
> +While 'slave' has a direct connection to human suffering the etymology
> +of 'blacklist' is devoid of a historical racial connection. However, one
> +thought exercise is to consider replacing 'blacklist/whitelist' with
> +'redlist/greenlist'. Realize that the replacement only makes sense if
> +you have been socialized with the concepts that 'red/green' implies
> +'stop/go'. Colors to represent a policy requires an indirection. The

how about:
              Using colors to represent a policy requires an indirection.

> +socialization of 'black/white' to have the connotation of
> +'impermissible/permissible' does not support inclusion.
> +
> +Inclusion == global developer community efficiency.


Acked-by: Randy Dunlap <rdunlap@infradead.org>


thanks.
-- 
~Randy

[PATCH] CodingStyle: Inclusive Terminology

[Dan Williams]

Recent events have prompted a Linux position statement on inclusive
terminology. Given that Linux maintains a coding-style and its own
idiomatic set of terminology here is a proposal to answer the call to
replace non-inclusive terminology.

Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Chris Mason <clm@fb.clm>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
 Documentation/process/coding-style.rst          |   12 ++++
 Documentation/process/inclusive-terminology.rst |   64 +++++++++++++++++++++++
 Documentation/process/index.rst                 |    1 
 3 files changed, 77 insertions(+)
 create mode 100644 Documentation/process/inclusive-terminology.rst

diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
index 2657a55c6f12..4b15ab671089 100644
--- a/Documentation/process/coding-style.rst
+++ b/Documentation/process/coding-style.rst
@@ -319,6 +319,18 @@ If you are afraid to mix up your local variable names, you have another
 problem, which is called the function-growth-hormone-imbalance syndrome.
 See chapter 6 (Functions).
 
+For symbol names, avoid introducing new usage of the words 'slave' and
+'blacklist'. Recommended replacements for 'slave' are: 'secondary',
+'subordinate', 'replica', 'responder', 'follower', 'proxy', or
+'performer'.  Recommended replacements for blacklist are: 'blocklist' or
+'denylist'.
+
+Exceptions for introducing new usage is to maintain a userspace ABI, or
+when updating code for an existing (as of 2020) hardware or protocol
+specification that mandates those terms. For new specifications consider
+translating specification usage of the terminology to the kernel coding
+standard where possible. See :ref:`process/inclusive-terminology.rst
+<inclusiveterminology>` for details.
 
 5) Typedefs
 -----------
diff --git a/Documentation/process/inclusive-terminology.rst b/Documentation/process/inclusive-terminology.rst
new file mode 100644
index 000000000000..a8eb26690eb4
--- /dev/null
+++ b/Documentation/process/inclusive-terminology.rst
@@ -0,0 +1,64 @@
+.. _inclusiveterminology:
+
+Linux kernel inclusive terminology
+==================================
+
+The Linux kernel is a global software project, and in 2020 there was a
+global reckoning on race relations that caused many organizations to
+re-evaluate their policies and practices relative to the inclusion of
+people of African descent. This document describes why the 'Naming'
+section in :ref:`process/coding-style.rst <codingstyle>` recommends
+avoiding usage of 'slave' and 'blacklist' in new additions to the Linux
+kernel.
+
+On the triviality of replacing words
+====================================
+
+The African slave trade was a brutal system of human misery deployed at
+global scale. Some word choice decisions in a modern software project
+does next to nothing to compensate for that legacy. So why put any
+effort into something so trivial in comparison? Because the goal is not
+to repair, or erase the past. The goal is to maximize availability and
+efficiency of the global developer community to participate in the Linux
+kernel development process.
+
+Word choice and developer efficiency
+====================================
+
+Why does any software project go through the trouble of developing a
+document like :ref:`process/coding-style.rst <codingstyle>`? It does so
+because a common coding style maximizes the efficiency of both
+maintainers and developers. Developers learn common design patterns and
+idiomatic expressions while maintainers can spot deviations from those
+norms. Even non-compliant whitespace is considered a leading indicator
+to deeper problems in a patchset. Coding style violations are known to
+take a maintainer "out of the zone" of reviewing code. Maintainers are
+also sensitive to word choice across specifications and often choose to
+deploy Linux terminology to replace non-idiomatic word-choice in a
+specification.
+
+Non-inclusive terminology has that same distracting effect which is why
+it is a style issue for Linux, it injures developer efficiency.
+
+Of course it is around this point someone jumps in with an etymological
+argument about why people should not be offended. Etymological arguments
+do not scale. The scope and pace of Linux to reach new developers
+exceeds the ability of historical terminology defenders to describe "no,
+not that connotation". The revelation of 2020 was that black voices were
+heard on a global scale and the Linux kernel project has done its small
+part to answer that call as it wants black voices, among all voices, in
+its developer community.
+
+Really, 'blacklist' too?
+========================
+
+While 'slave' has a direct connection to human suffering the etymology
+of 'blacklist' is devoid of a historical racial connection. However, one
+thought exercise is to consider replacing 'blacklist/whitelist' with
+'redlist/greenlist'. Realize that the replacement only makes sense if
+you have been socialized with the concepts that 'red/green' implies
+'stop/go'. Colors to represent a policy requires an indirection. The
+socialization of 'black/white' to have the connotation of
+'impermissible/permissible' does not support inclusion.
+
+Inclusion == global developer community efficiency.
diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
index f07c9250c3ac..ed861f6f8d25 100644
--- a/Documentation/process/index.rst
+++ b/Documentation/process/index.rst
@@ -27,6 +27,7 @@ Below are the essential guides that every developer should read.
    submitting-patches
    programming-language
    coding-style
+   inclusive-terminology
    maintainer-pgp-guide
    email-clients
    kernel-enforcement-statement