Thanks Carlo and Eric for the initiative. I am all for it and I'll do my part to mind the code. This is a small yet meaningful step we can take. Meanwhile, I'd like to take this opportunity to open up conversation around the Diversity & Inclusion within the community.
If you read this quarter's Hadoop board report, I am starting to collect metrics about the composition of our community in order to understand if we are building a diverse & inclusive community. Things that are obvious to me that I thought I should report are the following: affiliation among commiters, and demographics of committers. As of last quarter, 4 out of 7 newly minted committers are affiliated with Cloudera. 4 out of the 7 said committers are located in Asia. Those facts suggest we have a good international participation (I am being US-centric), which is good. However, having half of the active committers affiliated with one company is a potential problem. I'd like to hear your thoughts on this. What other metrics should we collect, and what actions can we take. On Fri, Jul 10, 2020 at 11:29 AM Carlo Aldo Curino <carlo.cur...@gmail.com> wrote: > Eric, > > Thank you so much for the support and for stepping up offering to work on > this. I am super +1 on this. Let's give folks a few more days to chime in, > in case there is anything to discuss before we get cracking! > > (Really) Thanks, > Carlo > > On Fri, Jul 10, 2020, 10:38 AM Eric Badger <ebad...@verizonmedia.com> > wrote: > > > 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 > >> > > >
