I agree with this, and maybe that is the potential the step forward here is: issue a statement is issued saying something like this is a complex issue and instead of making changes that could cause further division within the community we are looking for those that are interested to help form a constructive working group that will help influence and resolve all of these issues in a positive way for all not only for project but also within the wider group of apache projects.
Edward On Thu, 18 Jun 2020, 11:17 [email protected], <[email protected]> wrote: > Language is always changing and the meaning of words is changing, > sometimes positively and sometimes negatively. > I think that now is time for change again and we should discuss the use > of phrases and meanings. > > Of course we should change "Master Branch" to "Main Branch". > But I also think that we shouldn't just make quick changes because it's > opportune and hastily change a few words. > > An example: We could change Master/Slave to Leader/Follower. This may be > a perfect choice for most people in the world. > In German Leader is the English word for "Führer". And it is precisely > this word that we in Germany do not actually want to use for it. > > What I mean is that every country and every group (e.g. religion etc.) > has its own history and certain words or phrases are just not a perfect > choice. > We should try to go the ethically correct way worldwide. > > This concerns the adaptation of current words and phrases with a view to > all: in English, Indian, Chinese, German etc. but also for indigenous > peoples, different religions etc. > And cultural differences should also be taken into account. > > What I would wish for: > Apache.org should set up an "Ethics Board". A group of people of > different genders, all colors, religions and from different countries > and cultures all over our world. > This Ethics Board should find good and for no one discriminating words > or phrases for all the areas that stand out today as offensive. > > And it would be nice if not only computer scientists participated, but > also ethicists, philosophers, engineers, various religious people, > chemists, biologists, physicists, sociologists, etc. > > And this Council should set binding targets for all projects. > > Am 18.06.2020 um 09:36 schrieb Pierre Villard: > >> 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 <[email protected]> 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 <[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 > >>>>> > >>> > >
