> 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.
I could not agree more with the above. Le jeu. 18 juin 2020 à 04:29, Tony Kurc <tk...@apache.org> a écrit : > 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 <alopre...@apache.org> 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 > > alopre...@apache.org > > alopresto.apa...@gmail.com > > He/Him > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > > > > On Jun 17, 2020, at 6:43 PM, Edward Armes <edward.ar...@gmail.com> > > 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, <alopre...@apache.org> > 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 > > >> alopre...@apache.org > > >> alopresto.apa...@gmail.com > > >> He/Him > > >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > >> > > >>> On Jun 17, 2020, at 3:06 PM, Joe Witt <joe.w...@gmail.com> 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 <tk...@apache.org> 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 > > >>>> > > >> > > >> > > > > >
