I have created https://issues.apache.org/jira/browse/HADOOP-17168 to remove non-inclusive terminology from Hadoop. However I would like input on how to go about putting up patches. This umbrella JIRA is under Hadoop Common, but there are sure to be instances in YARN, HDFS, and Mapreduce. Should I create an umbrella like this for each subproject? Or should I do all whitelist/blacklist fixes in a single JIRA that fixes them across all Hadoop subprojects?
Thanks, Eric On Thu, Jul 30, 2020 at 8:47 AM Carlo Aldo Curino <carlo.cur...@gmail.com> wrote: > RE Mentorship: I think the Mentorship program is an interesting idea. The > concerns with these efforts is always the follow-through. If you can find a > group of folks that are motivated and will work on this I think it could be > a great idea, especially if you focus on a diverse set of mentees, and the > focus in on teaching not just code but a bit of the "apache way" of > interacting, and conducting yourself in open-source. > > RE Diversity and representation: Wei-Chiu I think you raise an important > problem. The main force behind this is typically for a company to be deeply > invested in a project and valuing OSS and putting lots full-time > developers on it. Those will naturally become committers. On one side this > is good to the project, unless it becomes so unbalance that the OSS nature > of the effort is in question. Attracting more contributors across > companies/countries (and any other dimension of diversity is important) > @Vinod I am sure you have been thinking about this issue, any thoughts? > > Thanks, > Carlo > > On Fri, Jul 10, 2020 at 1:49 PM Ahmed Hussein <a...@ahussein.me> wrote: > >> +1, this is great folks. >> >> In addition to that initiative, Do you think there is a chance to launch >> a "*Hadoop Mentorship Program for Minority Students*" >> >> *The program will work as follows:* >> >> - Define a programme committee to administrate and mentor candidates. >> - The Committee defines a timeline for applications and projects. >> Let's say it is some sort of 3 months. (Similar to an internship) >> - Define a list of ideas/projects that can be picked by the candidates >> - Candidates can propose their idea as well. This can be a good way >> to inject new blood and research ideas into Hadoop. >> - Pick top top applications and assign them to mentors. >> - If sponsors can allocate money, then candidates with good >> evaluation can get some sort of prize. If no money is allocated, then we >> can discuss any other kind of motivation. >> >> I remember there were Student Mentorship programmes in Open source >> projects like "JikesRVM" and several proposals were actually merged and/or >> transformed into publications. >> There are many missing links that need to be filled like how to define >> the target and the audience of the programme >> >> Let me know WDYT guys. >> >> On Fri, Jul 10, 2020 at 1:45 PM Wei-Chiu Chuang <weic...@apache.org> >> wrote: >> >>> 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 >>> <https://urldefense.com/v3/__https://tools.ietf.org/id/draft-knodel-terminology-00.html*rfc.section.1.1.1__;Iw!!Op6eflyXZCqGR5I!W9THsx9iZb2VObBrVY5_8ZRJKCws3YRAXARB-YTUElcUtxOBPWpiHWfGaWE7Lbogn7k$> >>> > >> 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 >>> > >> >>> > > >>> > >>> >> >> >> -- >> -- >> Best Regards, >> >> *Ahmed Hussein, PhD* >> >
