From: Dan Williams <dan.j.williams@intel.com>
To: torvalds@linux-foundation.org
Cc: ksummit-discuss@lists.linuxfoundation.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org,
tech-board-discuss@lists.linuxfoundation.org,
Chris Mason <clm@fb.clm>
Subject: [Ksummit-discuss] [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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
next reply other threads:[~2020-07-04 20:19 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-04 20:02 Dan Williams [this message]
2020-07-04 20:31 ` [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology Randy Dunlap
2020-07-04 23:41 ` Dave Airlie
2020-07-05 0:10 ` Matthew Wilcox
2020-07-05 1:10 ` [Ksummit-discuss] [Tech-board-discuss] " Kees Cook
2020-07-05 2:44 ` Randy Dunlap
2020-07-06 11:15 ` 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 ` [Ksummit-discuss] [Tech-board-discuss] " James Bottomley
2020-07-04 21:51 ` Joe Perches
2020-07-04 23:39 ` 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:12 ` Matthew Wilcox
2020-07-06 7:06 ` 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-05 0:41 ` Kees Cook
2020-07-07 4:30 ` Dan Williams
2020-07-10 16:52 ` Andy Lutomirski
2020-07-05 4:55 ` Willy Tarreau
2020-07-06 3:13 ` Daniel Palmer
2020-07-06 12:45 ` Chris Mason via Ksummit-discuss
2020-07-06 14:06 ` Laurent Pinchart
2020-07-06 15:55 ` Chris Mason via Ksummit-discuss
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 ` [Ksummit-discuss] [Tech-board-discuss] " Steven Rostedt
2020-07-06 13:23 ` [Ksummit-discuss] " Tibor Raschko
2020-07-06 16:29 ` 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 ` [Ksummit-discuss] [Tech-board-discuss] " Steven Rostedt
2020-07-07 15:24 ` 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 ` [Ksummit-discuss] [Tech-board-discuss] " Steven Rostedt
2020-07-07 14:45 ` 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 ` [Ksummit-discuss] [Tech-board-discuss] " Shuah Khan
2020-07-06 23:58 ` Tibor Raschko
[not found] ` <20200709124327.369781a0@coco.lan>
2020-07-09 16:01 ` Shuah Khan
2020-07-09 16:13 ` Mark Brown
2020-07-09 16:32 ` James Bottomley
2020-07-09 16:35 ` Steven Rostedt
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 ` [Ksummit-discuss] " Pavel Begunkov
2020-07-06 22:10 ` [Ksummit-discuss] [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 ` Stephen Hemminger
2020-07-07 6:56 ` [Ksummit-discuss] " SeongJae Park via Ksummit-discuss
2020-07-08 7:12 ` Dan Williams
2020-07-08 9:28 ` SeongJae Park via Ksummit-discuss
2020-07-07 7:51 ` Christian Brauner
2020-07-17 8:35 ` Pavel Machek
2020-07-26 15:30 ` Laurent Pinchart
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=gregkh@linuxfoundation.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 \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 read-only IMAP folder(s) and NNTP newsgroup(s).