linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: torvalds@linux-foundation.org
Cc: Jonathan Corbet <corbet@lwn.net>,
	Kees Cook <keescook@chromium.org>, Chris Mason <clm@fb.clm>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	ksummit-discuss@lists.linuxfoundation.org,
	tech-board-discuss@lists.linuxfoundation.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH] CodingStyle: Inclusive Terminology
Date: Sat, 04 Jul 2020 13:02:51 -0700	[thread overview]
Message-ID: <159389297140.2210796.13590142254668787525.stgit@dwillia2-desk3.amr.corp.intel.com> (raw)

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


             reply	other threads:[~2020-07-04 20:19 UTC|newest]

Thread overview: 93+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-04 20:02 Dan Williams [this message]
2020-07-04 20:31 ` Randy Dunlap
2020-07-04 23:41   ` [Ksummit-discuss] " Dave Airlie
     [not found]     ` <CAFhKne9MA_G-UsvBFfX-gZRcu9Gb7Xt7UxQ14MTppdU3X1VYdQ@mail.gmail.com>
2020-07-05  1:10       ` [Tech-board-discuss] " Kees Cook
2020-07-05  2:44         ` Randy Dunlap
2020-07-06 11:15         ` [Ksummit-discuss] [Tech-board-discuss] " Michael Kerrisk (man-pages)
2020-07-06 15:53           ` Kees Cook
2020-07-05  2:54       ` [Ksummit-discuss] " Dave Airlie
2020-07-04 20:44 ` Stephen Rothwell
2020-07-04 23:34   ` Dave Airlie
2020-07-05  2:12     ` Stephen Rothwell
2020-07-05  2:56       ` Dave Airlie
2020-07-05  3:23         ` James Bottomley
2020-07-05  3:26         ` Stephen Rothwell
2020-07-04 21:14 ` Olof Johansson
2020-07-04 21:25 ` [Tech-board-discuss] " James Bottomley
2020-07-04 21:51   ` Joe Perches
2020-07-04 23:39   ` [Ksummit-discuss] " Dave Airlie
2020-07-05  0:08     ` Joe Perches
2020-07-05  1:32     ` Kees Cook
2020-07-05 17:50     ` opal hart
2020-07-04 23:42 ` [Ksummit-discuss] " Dave Airlie
2020-07-05  0:41 ` Kees Cook
2020-07-07  4:30   ` Dan Williams
2020-07-10 16:52     ` [Ksummit-discuss] " Andy Lutomirski
2020-07-05  4:55 ` Willy Tarreau
2020-07-06  3:13   ` Daniel Palmer
2020-07-06 12:45   ` Chris Mason
2020-07-06 14:06     ` [Ksummit-discuss] " Laurent Pinchart
2020-07-06 15:55       ` Chris Mason
2020-07-06 16:06     ` Mike Rapoport
2020-07-07  4:17       ` Dan Williams
2020-07-06 15:22   ` Arvind Sankar
2020-07-06 15:40     ` [Tech-board-discuss] " Steven Rostedt
     [not found] ` <CAFhKne_ZVWVhZX5hNEbeGBfU6BMRN9JKQeTsVYOcMmEH1cd3xg@mail.gmail.com>
2020-07-06  7:06   ` [Ksummit-discuss] " NeilBrown
2020-07-06  7:10   ` NeilBrown
2020-07-06  7:22     ` Greg Kroah-Hartman
2020-07-06  7:53       ` Geert Uytterhoeven
2020-07-06 10:22         ` Greg Kroah-Hartman
2020-07-06 12:51         ` Matthew Wilcox
2020-07-06 12:59           ` Joe Perches
2020-07-06 13:04             ` Matthew Wilcox
2020-07-06 13:30               ` Joe Perches
2020-07-09 11:11                 ` Mauro Carvalho Chehab
2020-07-13  4:25                   ` Vinod Koul
2020-07-13 15:55                     ` Dan Williams
2020-07-06 13:23 ` Tibor Raschko
2020-07-06 16:29 ` [Ksummit-discuss] " Andy Lutomirski
2020-07-07  4:00   ` Dan Williams
2020-07-07  5:56   ` Kees Cook
2020-07-07  6:49     ` Mike Rapoport
2020-07-07 13:37       ` [Tech-board-discuss] " Steven Rostedt
2020-07-07 15:24         ` [Ksummit-discuss] [Tech-board-discuss] " Bird, Tim
2020-07-07 15:33           ` Randy Dunlap
2020-07-07 15:41             ` Steven Rostedt
2020-07-07 15:55               ` Bird, Tim
2020-07-07  6:56     ` [Ksummit-discuss] " Harrosh, Boaz
2020-07-07  8:54       ` Kees Cook
2020-07-07 13:41         ` [Tech-board-discuss] " Steven Rostedt
2020-07-07 14:45           ` [Ksummit-discuss] [Tech-board-discuss] " Mike Rapoport
2020-07-07 20:56             ` Kees Cook
2020-07-07 21:48         ` [Ksummit-discuss] " Arvind Sankar
2020-07-07 12:13       ` Mark Brown
2020-07-06 18:30 ` [Tech-board-discuss] " Shuah Khan
2020-07-06 23:58   ` Tibor Raschko
2020-07-09 10:43     ` [Ksummit-discuss] " Mauro Carvalho Chehab
2020-07-09 16:01       ` Shuah Khan
2020-07-09 16:13         ` [Tech-board-discuss] [Ksummit-discuss] " Mark Brown
2020-07-09 16:32           ` [Ksummit-discuss] [Tech-board-discuss] " James Bottomley
2020-07-09 16:35           ` [Tech-board-discuss] [Ksummit-discuss] " Steven Rostedt
2020-07-10  9:38         ` [Ksummit-discuss] [Tech-board-discuss] " Tibor Raschko
2020-07-07  4:04   ` Dan Williams
2020-07-06 19:15 ` Mark Brown
2020-07-07  0:48   ` Tibor Raschko
2020-07-07 21:26     ` Arvind Sankar
2020-07-07 23:54       ` Tibor Raschko
2020-07-07  4:08   ` Dan Williams
2020-07-07  9:36     ` Mark Brown
2020-07-06 21:31 ` Pavel Begunkov
2020-07-06 22:10   ` [Tech-board-discuss] " Steven Rostedt
2020-07-06 22:17     ` Pavel Begunkov
2020-07-06 22:28       ` Steven Rostedt
2020-07-06 23:03         ` Pavel Begunkov
2020-07-08  3:42           ` [Ksummit-discuss] " Stephen Hemminger
2020-07-08 10:51             ` Pavel Begunkov
2020-07-07  6:56 ` [Ksummit-discuss] " SeongJae Park
2020-07-08  7:12   ` Dan Williams
2020-07-08  9:28     ` SeongJae Park
2020-07-07  7:51 ` Christian Brauner
2020-07-08 18:40 ` Daniel Vetter
2020-07-17  8:35 ` Pavel Machek
2020-07-26 15:30 ` [Ksummit-discuss] " Laurent Pinchart
2020-07-06  8:48 Michael Shigorin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=159389297140.2210796.13590142254668787525.stgit@dwillia2-desk3.amr.corp.intel.com \
    --to=dan.j.williams@intel.com \
    --cc=clm@fb.clm \
    --cc=corbet@lwn.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=keescook@chromium.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tech-board-discuss@lists.linuxfoundation.org \
    --cc=torvalds@linux-foundation.org \
    --subject='Re: [PATCH] CodingStyle: Inclusive Terminology' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).