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 -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
signature.asc
Description: PGP signature
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
