Messages in this thread | | | Subject | Re: [PATCH] CodingStyle: Inclusive Terminology | From | Randy Dunlap <> | Date | Sat, 4 Jul 2020 13:31:42 -0700 |
| |
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
| |