I suppose I was a bit remiss in not unwinding and/or summarizing some of what was in that yetus thread to prime the discussion, but a some of what Andy is mentioning is expanded on a bit in this ietf document [1], which is linked in one of the articles.
1. https://tools.ietf.org/id/draft-knodel-terminology-00.html On Wed, Jun 17, 2020, 10:02 PM Andy LoPresto <[email protected]> wrote: > Hi Edward, thanks for sharing your thoughts. I’ll reply inline. > > > - Some of the terms proposed are not industry standard and may > potentially > > cause significant issue for non-english speakers. > > I actually believe making these changes will _improve_ the clarity for > non-english speakers. “Whitelist” and “blacklist” confer no inherent reason > to mean allow and deny other than connotative biases. “Allow” and “deny” > explicitly indicate the verb that is happening. Another example is branch > naming. “Masters” don’t have “branches”. “Trunks” do. These terms make > _more_ sense for a non-English speaker than the current terms. > > > > > - For each change that is made can we guarantee that we will not lose > > clarity of meaning, and then have revert the change down the line if the > > change causes a drop in usage. > > I don’t expect the community will opt to change the new terms back to ones > with negative connotations in the future. If there is discussion about it, > this thread will provide good historical context for why the decision was > made to change it, just as the mailing list discussions do for other code > changes. > > > > > - Of what percentage of people is this truly an issue for and what > > percentage isn't. Any change that has the potential to cause a major > split > > in the community, there must be as close as possible to a majority, and > not > > just from those that are vocal and active on the mailing lists. > > Disscustions on other groups are turning toxic, and in some cases are > > potentially leading to the collapse of these projects where these changes > > are being implemented with what appears to be without the agreement of a > > signifficant chunk of the community. > > > > In my perspective this should be an issue for the entire community. Being > able to identify an issue that directly affects another person but not > one’s self is the definition of privilege. If I can look at how the use of > these words in someone’s daily life or career impacts them negatively, when > the change would not harm me at all, I see that as a failure on my part. I > understand the desire to hear from the silent majority, but active > participation and discussion on the mailing list is the exact measure > described by the Apache process for participation in the community. Those > who speak here are the ones who will have a voice. > > > - From a personal perspective, I sit on the autism spectrum and have > grown > > up with people using words that are very offensive and have hurt me > badly. > > Instead of having these words as offensive and untouchable. Myself and > > others have instead made these words our own and made them lose the > > negative connotations they have. As such, I do find the current > > disscustions deeply alarming and feels like they start to border into the > > realm of censorship. > > > > I think it’s admirable that you have responded to negative circumstances > in that way. I also recognize that not everyone has that opportunity. If we > can take these actions as a community to improve the experience for others, > I am in favor of that. > > > - One final point (and potentially controversial), A good chunk of the > > wording that is proposed to be changed. Is being done so on the > > "modern"/"street" definition of these words and not the actual > definition. > > Language should change and evolve to introduce clarity, but right now > does > > this change improve the clarity across the engineering sector and I > believe > > it won't. > > > I’ll paraphrase Emily Kager here with “developers spend an inordinate > amount of time and energy arguing about the meaning and semantics of > variable and method names, but pretend exclusionary terms are meaningless.” > [1] If we can expend that much energy deciding if a method creates vs. > builds vs. forms an imaginary concept like a > LibraryFrameworkWrapperDecorator, I refuse to concede that we can and in > fact should do so with the terms that actually affect our community > members’ lives. > > [1] https://twitter.com/EmilyKager/status/1271102865889734656 < > https://twitter.com/EmilyKager/status/1271102865889734656> > > > > > Andy LoPresto > [email protected] > [email protected] > He/Him > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > > On Jun 17, 2020, at 6:43 PM, Edward Armes <[email protected]> > wrote: > > > > This is a difficult issue and causes no small amount of friction every > > time. I'm personally against this for the following reassons: > > > > - Some of the terms proposed are not industry standard and may > potentially > > cause significant issue for non-english speakers. > > > > - For each change that is made can we guarantee that we will not lose > > clarity of meaning, and then have revert the change down the line if the > > change causes a drop in usage. > > > > - Of what percentage of people is this truly an issue for and what > > percentage isn't. Any change that has the potential to cause a major > split > > in the community, there must be as close as possible to a majority, and > not > > just from those that are vocal and active on the mailing lists. > > Disscustions on other groups are turning toxic, and in some cases are > > potentially leading to the collapse of these projects where these changes > > are being implemented with what appears to be without the agreement of a > > signifficant chunk of the community. > > > > - From a personal perspective, I sit on the autism spectrum and have > grown > > up with people using words that are very offensive and have hurt me > badly. > > Instead of having these words as offensive and untouchable. Myself and > > others have instead made these words our own and made them lose the > > negative connotations they have. As such, I do find the current > > disscustions deeply alarming and feels like they start to border into the > > realm of censorship. > > > > - One final point (and potentially controversial), A good chunk of the > > wording that is proposed to be changed. Is being done so on the > > "modern"/"street" definition of these words and not the actual > definition. > > Language should change and evolve to introduce clarity, but right now > does > > this change improve the clarity across the engineering sector and I > believe > > it won't. > > > > Edward > > > > > > On Thu, 18 Jun 2020, 01:11 Andy LoPresto, <[email protected]> wrote: > > > >> I am a proponent of making this change and also using allow/deny list, > >> meddler-in-the-middle, etc. > >> > >> Here is a blog [1] with easy instructions for executing the change in > git, > >> although I don’t know if there is any Apache-integration specific > changes > >> we would also need. > >> > >> [1] > >> > https://www.hanselman.com/blog/EasilyRenameYourGitDefaultBranchFromMasterToMain.aspx > >> > >> Andy LoPresto > >> [email protected] > >> [email protected] > >> He/Him > >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > >> > >>> On Jun 17, 2020, at 3:06 PM, Joe Witt <[email protected]> wrote: > >>> > >>> I suspect it would be fairly easy to make this change. We do, I think, > >>> have whitelist/blacklist in there somewhere but im not sure how > involved. > >>> > >>> On Wed, Jun 17, 2020 at 3:04 PM Tony Kurc <[email protected]> wrote: > >>> > >>>> All, > >>>> I've seen the discussion started on other projects [1][2], so I wanted > >> to > >>>> kick off a discussion to determine whether this is something nifi > could > >>>> look at too. Allen Wittenauer's post to yetus captures the why and > some > >> of > >>>> the how, so rather than copy and pasting, you can take a look at what > >> he's > >>>> done. Thoughts? > >>>> > >>>> Tony > >>>> > >>>> 1. > >>>> > >>>> > >> > https://lists.apache.org/thread.html/rd38afa9fb6c0dcd77d1a677f1152b7398b3bda93c9106b3393149d10%40%3Cdev.yetus.apache.org%3E > >>>> 2. > >>>> > >>>> > >> > https://lists.apache.org/thread.html/r0825eec0c84296bdab7cf898a987f06355443241ca02b2aaa51d3ef9%40%3Cdev.accumulo.apache.org%3E > >>>> > >> > >> > >
