Thanks for writing this up, Carlo. I'm +1 (idk if I'm technically binding on this or not) for the changes moving forward and I think we refactor away any instances that are internal to the code (i.e. not APIs or other things that would break compatibility) in all active branches and then also change the APIs in trunk (an incompatible change).
I just came across an internal issue related to the NM whitelist/blacklist. I would be happy to go refactor the code and look for instances of these and replace them with allowlist/blocklist. Doing a quick "git grep" of trunk, I see 270 instances of "whitelist" and 1318 instances of "blacklist". If there are no objections, I'll create a JIRA to clean this specific stuff up. It would be wonderful if others could pick up a different portion (e.g. master/slave) so that we can spread the work out. Eric On Tue, Jul 7, 2020 at 6:27 PM Carlo Aldo Curino <carlo.cur...@gmail.com> wrote: > Hello Folks, > > I hope you are all doing well... > > *The problem* > The recent protests made me realize that we are not just a bystanders of > the systematic racism that affect our society, but we are active > participants of it. Being "non-racist" is not enough, I strongly feel we > should be actively "anti-racist" in our day to day lives, and continuously > check our biases. I assume most of you will agree with the general > sentiment, but based on your exposure to the recent events and US > culture/history might have more or less strong feelings about your role in > the problem and potential solution. > > *What can we do about it?* I think a simple action we can take is to work > on our code/comments/documentation/websites and remove racist terminology. > Here is a IETF draft to fix up some of the most egregious examples > (master/slave, whitelist/backlist) with proposed alternatives. > > https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1.1 > Also as we go about this effort, we should also consider other > "non-inclusive" terminology issues around gender (e.g., binary gendered > examples, "Alice" doing the wrong security thing systematically), and > ableism (e.g., referring to misbehaving hardware as "lame" or "limping", > etc.). > The easiest action item is to avoid this going forward (ideally adding it > to the checkstyles if possible), a more costly one is to start going back > and refactor away existing instances. > > I know this requires a bunch of work as refactorings might break dev > branches and non-committed patches, possibly scripts, etc. but I think this > is something important and relatively simple we can do. The effect goes > well beyond some text in github, it signals what we believe in, and forces > hundreds of users and contributors to notice and think about it. Our > force-multiplier is huge and it matches our responsibility. > > What do you folks think? > > Thanks, > Carlo >
