Hope it's a joke. Are you going to create a list with "forbidden" worlds?
-----Original Message----- From: TSC tsc-bounces@lists.trustedfirmware.org On Behalf Of Julius Werner via TSC Sent: Tuesday, September 15, 2020 12:50 AM To: tsc@lists.trustedfirmware.org Subject: [TF-TSC] Avoiding noninclusive language in Trusted Firmware code
Hi all,
I'd like to propose a short discussion topic for the next TSC meeting on Thursday. I've already brought this up in a recent board meeting with generally positive feedback, but we agreed that it's probably more of a topic for the TSC.
As some of you are probably aware, inspired by the recent and ongoing protests and societal discourse in the United States, many open source projects and platforms (from Python to GitHub) have started to reevaluate the terminology they use in code and documentation and updated their style guides to promote the use of inclusive terminology. Probably most closely related to our project, the Linux kernel recently merged a patch to deprecate the usage of the terms 'master' and 'slave' as well as 'blacklist' and 'whitelist' in their codebase: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel...
I would like to propose that the Trusted Firmware projects (I'm primarily interested in TF-A, but this would probably be something worth coordinating across projects) follow suit and start working on a similar change. Since a lot of our developers are also active in Linux and it is facing many of the same challenges (particularly with terminology tied to specific hardware standards), my proposal would be to basically just follow Linux' guidance regarding affected terms and policy here. I of course do not expect that we'll instantly delete every instance of the word 'master' or 'slave' from the repository, especially since like Linux we have many drivers for hardware where this terminology is already present in register names or protocol standards. But I think it would be important to codify the intention in the style guide to get started and provide guidance for reviewers of new submissions, even though cleaning up existing code is a long-term task and some code will probably remain stuck on them due to external dependencies.
I hope we can have a quick discussion in the meeting to gauge overall opinion of this idea and, if positive, decide on the best approach to bring it to the individual projects.
Thanks, Julius