Language matters

[Patrick Georgi]

Hi everybody,

in last Wednesdays' leadership meeting we've been discussing how to
deal with language in our code and community. I offered to report on
our results and to start the wider discussion and so that's the aim
of this email.

You might have heard about calls to avoid certain terminology in
tech. For those who haven't heard, here's a short re-cap: tech uses
terminology like "slave" (in conjunction with "master") with little
thought about the impact the non-tech interpretations of such terms
can have for some people.

The issue isn't exactly new, some open source projects retired the
use of certain words years ago, but in light of recent developments
(Black Lives Matter and all that) the topic has been brought up again.

Since it's usually possible to find other terms to describe the same
fact that come with no (or less) historical baggage, and often even
_better_ terms, the proposal is to move away from troublesome words
in favor of more neutral ones.

In some cases such proposals don't come across as proposals (but rather
as pretty forceful demands) and some of these debates ended badly,
both things that we'd like to avoid. We discussed an approach at the
leadership meeting and hope that it's nuanced enough to achieve a code
base and community where people of all stripes can contribute and not
run into stumbling blocks that make them feel not welcome, while also
not making people feel like they're having to watch their words.

So first and foremost, this isn't about playing some blame game. Words
have been used and will be used while not taking into account the
impact they may have on others, and as long as there's no bad intent,
let's try to be gracious about it, point out where things go wrong,
and on the receiving end, strive to improve. Overall I think this
community did pretty well on that, and so I don't see a big issue
with us continuing to do that.

Second: This exercise isn't about achieving world peace by eliminating
bad language or anything similar grandiose, obtuse or nonsensical. It's
about ensuring that coreboot is one of those open source projects
about which people, no matter their background, say that it's a
pleasure to work with.
From what I've heard people say after coming in to coreboot with
experience from other firmware projects, we probably achieved that
on the technical side (although there's always room to improve)
but there's more than just technical merit.

With that out of the way, here's what we came up with:

There's a set of words that we'd try to avoid, and that set can
grow over time as we identify terminology that is picked up badly
by some. Not all such terms are equally bad, and that can certainly
inform our approach with them.

For now, we've identified "slave", "master", "black list", and
"white list".

"slave": There has been no contest in the meeting that this term
carries _lots_ of baggage, and that we should look for alternatives.

"master": This is troublesome due to its connection to "slave", but
there are also different meanings of the term, some decidely positive
(what's bad about being a "master of your trade"?), so it's probably
the poster child of "not equally bad".

"black list": These lists typically aren't "black", neither are the
objects on these lists. I'd dare to say that they come in no color or
at most in whatever color your text editor uses. I'd like to think that
there's a better adjective for any given list to describe its purpose.

"white list": The opposite to the "black list", with the same
rationale. We even have an example for a descriptive rename for that
in the tree: Duncan renamed some white list into "allow list", which
is more descriptive for that particular use case while avoiding the
blanket term.
That doesn't mean that all white lists should become allow lists:
Be descriptive and consider what best describes the object you're
(re)naming.

The way we want to proceed with such terms depends on the context:

1. Some internal representation within coreboot that's called "master"
and "slave" could be renamed without confusing anybody and that's what
we should do there. Luckily, we don't typically deal with multiple
coordinating entities, so these specific terms aren't very widely
used to describe actors within coreboot. A counter example is the
Gerrit project that's developing our code review platform, and they
have a much harder time with these specific words.

For things in this category we'd propose that you think twice before
using them (and if you're comfortable doing so, that you start
a discussion when you see them during code review.) Again, such a
discussion is not about assigning blame or creating any bad outcomes
for your fellow developers, but to ensure a consistent style in our
code. If something slips through, we can clean up later - it's the
same approach we take with technical problems in our code.
There needn't be a huge "stop the world, we'll purge the tree" event
to get the code base into a certain form, but it's not verboten,
either (except for the "stop the world" part - I don't think that
would end well.)

2. Some terms are taken directly from standards or interfaces we deal
with. We can't change the fact that JEDEC talks about SPI "masters"
and "slaves", and changing them in our source code would only make
readers do a double take, which even puts a spotlight on the very
things we wanted to de-emphasize.

It may be possible to hide such terms in abbreviations (talk about
MOSI, not master-out-slave-in, which I think we already do,) but
other than that, such instances are here to stay until JEDEC and the
other sources of interface definitions reconsider - in which case
we'd follow, to avoid confusion.

3. And then there's "master" as in "master branch" on git. There's no
"slave" associated with it, so that's much less pressing, but there
appears to be talk across the git developer (and user) communities
to retire that name, with some preference emerging to use "main"
as a replacement.

I pitched the idea to the Gerrit developers to support branch
aliases, to that "main" and "master" could point to the same branch
transparently, with support for refs/for/master and all the other
little places where branch names appear in git and Gerrit. They seem to
have taken the idea pretty well and I expect that to eventually exist.

Once Gerrit supports such branch aliases, we could rename master as
main but at the same time establish the alias to ensure that we don't
break any workflows.

Please consider the proposal and the approach outlined here. Discuss,
remain friendly and charitable. The issues that sparked this debate
are, to a certain degree, specific to the USA, and if you're not
living there it may seem to you that all this doesn't apply to
you. Fact is that the language we're usually using to communicate
here, on the list, IRC, code comments, and so on, is English, and the
USA is a rather large part of the anglophone community. Therefore,
when it comes to the English language, whatever happens there will
also influence this project and there's little we can do about it.

If you're flat-out opposed to retire words from active circulation,
I'd like to know why. I prepared a good share of this initiative,
and I've heard the position of those who stumble over words like
the ones listed above and I've taken that into account. In the
same way I'm interested in learning about your view on the matter.
Due to the sensitive nature of such statements (as in: it may well
be flame war material and our mailing list isn't exactly secret),
please contact me directly about this, not through the list. I won't
share any statements made to me (as far as the law allows), nor their
authors, although I may try to compile an anonymized cohesive set of
arguments to present the case if there's a need.

Thanks,
Patrick