[DISCUSS] rename master branch, look through code for other related issues

[Tony Kurc <tk...@apache.org>]

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

Re: [DISCUSS] rename master branch, look through code for other related issues

[Robert Fellows <ro...@gmail.com>]

I am a +1 for making the changes.

- Rob Fellows

On Thu, Jun 18, 2020 at 7:52 AM Adam Hunyadi <hu...@cloudera.com.invalid>
wrote:

> <sarcasm>
>
> I propose naming the master branch Voldemort, so that people do not
> speak of its name. Of course this recommendation only applies if noone
> finds choosing the name of a "dark" lord offensive.
>
> </sarcasm>
>
> Adam Hunyadi
>
> On 2020. 06. 18. 12:17, Uwe@Moosheimer.com 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 <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 <al...@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
> >>>> alopresto@apache.org
> >>>> alopresto.apache@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 <ed...@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, <al...@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
> >>>>>> alopresto@apache.org
> >>>>>> alopresto.apache@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 <jo...@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
> >
>


-- 
-------------------------------
Rob Fellows

Re: [DISCUSS] rename master branch, look through code for other related issues

[Adam Hunyadi <hu...@cloudera.com.INVALID>]

<sarcasm>

I propose naming the master branch Voldemort, so that people do not 
speak of its name. Of course this recommendation only applies if noone 
finds choosing the name of a "dark" lord offensive.

</sarcasm>

Adam Hunyadi

On 2020. 06. 18. 12:17, Uwe@Moosheimer.com 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 <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 <al...@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
>>>> alopresto@apache.org
>>>> alopresto.apache@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 <ed...@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, <al...@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
>>>>>> alopresto@apache.org
>>>>>> alopresto.apache@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 <jo...@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
>

Re: [DISCUSS] rename master branch, look through code for other related issues

[Joe Witt <jo...@gmail.com>]

Team,

I think the key for us, in this community, is that there are couple simple
things we can do which just make it better.

1. Change the name of the default branch from 'master' to 'main' consistent
with what is happening in Github/and beyond.
2. Change from whitelist/blacklist to allow/deny or some other frankly more
clear combination.

We used to have an architecture that was master/slave.  That is long gone
and not just because the terminology wasn't helpful - the architecture
wasnt good enough.

So all that is left as far as I can tell for now is some easy stuff that at
worst makes our stuff align to common changes in the broader dev community
and uses terms that are more precise.  At best we make the community feel a
bit more welcoming for someone.  Easy day.

Thanks

On Thu, Jun 18, 2020 at 8:58 AM Brandon DeVries <br...@jhu.edu> wrote:

> "Instead of banning every word out
> there, we should make the mental effort to do better than the
> political correctness movement that stops at the surface."
>
> I think this is a pretty clear false dichotomy.  Doing one doesn't preclude
> the other.  The statement above goes on:
>
> "So, let’s call it master-slave, and instead make a call for US, where
> a sizable black population is very poor, to have free healthcare, to
> have cops that are less biased against non-white people, to stop death
> penalty. This makes really a difference."
>
> ... those things seem outside the direct control of the ASF.  We should try
> to improve the things we can when we can.
>
> +1 on the change
>
> On Thu, Jun 18, 2020 at 11:24 AM Jon Logan <jm...@buffalo.edu> wrote:
>
> > I think this blog post from the founder of Redis sums things up:
> > http://antirez.com/news/122
> >
> > From the post:
> >
> > For example if I’m terminally ill, the “short living request”
> > terminology may be offensive, it reminds me that I’m going to die, or
> > that my father is going to die. Instead of banning every word out
> > there, we should make the mental effort to do better than the
> > political correctness movement that stops at the surface.
> >
> >
> > On Thu, Jun 18, 2020 at 11:05 AM Edward Armes <ed...@gmail.com>
> > wrote:
> >
> > > 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 Uwe@Moosheimer.com, <Uw...@moosheimer.com>
> > 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 <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 <
> alopresto@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
> > > > >>> alopresto@apache.org
> > > > >>> alopresto.apache@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.armes@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, <alopresto@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
> > > > >>>>> alopresto@apache.org
> > > > >>>>> alopresto.apache@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 <jo...@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
> > > > >>>>>
> > > > >>>
> > > >
> > > >
> > >
> >
>

Re: [DISCUSS] rename master branch, look through code for other related issues

[Brandon DeVries <br...@jhu.edu>]

"Instead of banning every word out
there, we should make the mental effort to do better than the
political correctness movement that stops at the surface."

I think this is a pretty clear false dichotomy.  Doing one doesn't preclude
the other.  The statement above goes on:

"So, let’s call it master-slave, and instead make a call for US, where
a sizable black population is very poor, to have free healthcare, to
have cops that are less biased against non-white people, to stop death
penalty. This makes really a difference."

... those things seem outside the direct control of the ASF.  We should try
to improve the things we can when we can.

+1 on the change

On Thu, Jun 18, 2020 at 11:24 AM Jon Logan <jm...@buffalo.edu> wrote:

> I think this blog post from the founder of Redis sums things up:
> http://antirez.com/news/122
>
> From the post:
>
> For example if I’m terminally ill, the “short living request”
> terminology may be offensive, it reminds me that I’m going to die, or
> that my father is going to die. Instead of banning every word out
> there, we should make the mental effort to do better than the
> political correctness movement that stops at the surface.
>
>
> On Thu, Jun 18, 2020 at 11:05 AM Edward Armes <ed...@gmail.com>
> wrote:
>
> > 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 Uwe@Moosheimer.com, <Uw...@moosheimer.com>
> 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 <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 <al...@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
> > > >>> alopresto@apache.org
> > > >>> alopresto.apache@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.armes@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, <al...@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
> > > >>>>> alopresto@apache.org
> > > >>>>> alopresto.apache@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 <jo...@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
> > > >>>>>
> > > >>>
> > >
> > >
> >
>

Re: [DISCUSS] rename master branch, look through code for other related issues

[Jon Logan <jm...@buffalo.edu>]

I think this blog post from the founder of Redis sums things up:
http://antirez.com/news/122

From the post:

For example if I’m terminally ill, the “short living request”
terminology may be offensive, it reminds me that I’m going to die, or
that my father is going to die. Instead of banning every word out
there, we should make the mental effort to do better than the
political correctness movement that stops at the surface.


On Thu, Jun 18, 2020 at 11:05 AM Edward Armes <ed...@gmail.com>
wrote:

> 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 Uwe@Moosheimer.com, <Uw...@moosheimer.com> 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 <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 <al...@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
> > >>> alopresto@apache.org
> > >>> alopresto.apache@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 <ed...@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, <al...@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
> > >>>>> alopresto@apache.org
> > >>>>> alopresto.apache@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 <jo...@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
> > >>>>>
> > >>>
> >
> >
>

Re: [DISCUSS] rename master branch, look through code for other related issues

[Andy LoPresto <al...@apache.org>]

I will make a Jira for the key management references. I have already removed a large portion of the legacy terms from the proxy path handling and related documentation in [1]. 

[1] https://github.com/apache/nifi/pull/4351

Andy LoPresto
alopresto@apache.org
alopresto.apache@gmail.com
He/Him
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Jul 6, 2020, at 8:21 PM, Tony Kurc <tr...@gmail.com> wrote:
> 
> After a quick review, in nifi, I wasn't able to find references to the
> properties Joe mentioned, but I did use crude recursive greps to look. A
> majority of the blacklist references were in wali in method names and log
> messages. Picking a more useful term in wali would probably make sense.
> I'll make a jira, but we'd need to be a bit more deliberate about when that
> change could happen, no? Long story short, since assumptions were maybe a
> bit off (i.e. not an additive change), I think a later release may make
> sense.
> 
> There was a blacklist property in nifi-cpp. I'll make a jira and work on a
> pr for that.
> 
> Most prevalent in my grep analysis related to master/slave were carrying
> over terms from dependencies (e.g. MySQL, zookeeper, or third-party libs in
> nifi-cpp) and "master key" crypt related stuff.
> 
> On Mon, Jul 6, 2020, 6:02 PM Tony Kurc <tr...@gmail.com> wrote:
> 
>> Mike,
>> I did a quick check to see if anyone had done a jira or pr for #2, so I'll
>> take a stab at doing that today.
>> 
>> Tony
>> 
>> On Thu, Jul 2, 2020 at 10:27 PM Mike Thomsen <mi...@gmail.com>
>> wrote:
>> 
>>> Didn't see any commits or PRs for any of these yet. Do we want to consider
>>> these blockers for 1.12 or hold off until a post 1.12 release?
>>> 
>>> On Mon, Jun 22, 2020 at 12:48 PM Joe Witt <jo...@gmail.com> wrote:
>>> 
>>>> Not that I'm aware of.  All this so far just looks really easy to deal
>>>> with.
>>>> 
>>>> On Mon, Jun 22, 2020 at 9:46 AM Mike Thomsen <mi...@gmail.com>
>>>> wrote:
>>>> 
>>>>> Out of curiosity... are there any cases you've found where we might
>>> have
>>>> a
>>>>> term misalignment with what another product calls them? Like we might
>>>> have
>>>>> primary/replica and the supported system uses master/slave?
>>>>> 
>>>>> On Mon, Jun 22, 2020 at 11:32 AM Joe Witt <jo...@gmail.com> wrote:
>>>>> 
>>>>>> ...additional note after reviewing the presence of
>>>> 'whitelist/blacklist'
>>>>> I
>>>>>> remain of the view what we need to do here is easy.  There is
>>> minimal
>>>> API
>>>>>> impact and it appears to be just the nifi.properties file for a
>>>> property.
>>>>>> Other code changes do not appear to be API related and seem fair
>>> game
>>>>> now.
>>>>>> We can easily support the old naming and create a different property
>>>> name
>>>>>> for the properties file case.  We dont need to wait for any major
>>>> release
>>>>>> as far as I can tell
>>>>>> 
>>>>>> Thanks
>>>>>> 
>>>>>> On Sat, Jun 20, 2020 at 4:47 PM Mike Thomsen <
>>> mikerthomsen@gmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> I think just shooting for #1 right away makes sense, but #2 will
>>> need
>>>>> to
>>>>>> be
>>>>>>> done as part of a major release. I think we go all-in to be
>>>> consistent
>>>>> on
>>>>>>> allow/block vs white/black and similar changes that are needed. We
>>>>> should
>>>>>>> also avoid things like the proposal to use "allowlist/denylist"
>>> that
>>>>>> other
>>>>>>> teams are debating since that is just a pointless spawning of
>>>>> neologisms
>>>>>>> for the sake of creating them. The best approach is to use clear,
>>>>> concise
>>>>>>> language that is preferably as limited on jargon as possible, and
>>> I
>>>>> feel
>>>>>>> like those teams are missing the mark on that. If we do find
>>> language
>>>>>> that
>>>>>>> needs to be changed in descriptor name fields, I think it would
>>> also
>>>>>>> prevent any problems by making part of the messaging being that
>>> those
>>>>>>> changes are non-negotiable as they represent real potential
>>> breakage
>>>> to
>>>>>>> users. I think most folks would be fine with that, but it might
>>> need
>>>> to
>>>>>> be
>>>>>>> spelled out for some that there is a balance that has to be
>>>> maintained
>>>>>>> until a proper transition can take place.
>>>>>>> 
>>>>>>> On Sat, Jun 20, 2020 at 6:23 PM Tony Kurc <tk...@apache.org>
>>> wrote:
>>>>>>> 
>>>>>>>> This discussion has died down quite a bit. I got the impression
>>>> there
>>>>>> was
>>>>>>>> at least majority support, although not consensus, for Joe's two
>>>>>>> proposals
>>>>>>>> [1].
>>>>>>>> 
>>>>>>>> #1 ( s/master/main/ ) is probably the most straightforward -
>>> change
>>>>>>>> developer docs and make the necessary repository changes. Can be
>>>> done
>>>>>>>> seemingly independent of software releases. Is it time for
>>> jiras on
>>>>>> that?
>>>>>>>> My sense is that 'main' appears to be a common term that
>>> projects
>>>>>> appear
>>>>>>> to
>>>>>>>> be gravitating to, but that discussion still abounds. This
>>> comment
>>>>> [2]
>>>>>> on
>>>>>>>> the git project's mailing list hurt my head quite a bit, but
>>>>> definitely
>>>>>>>> reinforced that main makes a whole lot more sense than master,
>>> as
>>>>> Andy
>>>>>>>> pointed out [3].
>>>>>>>> 
>>>>>>>> #2 is a bit less straightforward, going to require a code change
>>>> and
>>>>>>> figure
>>>>>>>> out where that fits with the versioning scheme commitments [4].
>>> Do
>>>> we
>>>>>>>> support both allow/block (or deny?) along with white/black in a
>>>> minor
>>>>>>>> release, and then prune white/black on next major release?
>>>>>>>> 
>>>>>>>> 1.
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> https://lists.apache.org/thread.html/r6c133a31f882d3c818e63fa44dbc451f61d423a22dbe72396483127b%40%3Cdev.nifi.apache.org%3E
>>>>>>>> 
>>>>>>>> 2.
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> https://lore.kernel.org/git/CANgJU+Ut+ANPHud1JQw1Wo+zb37_=EWx-vgap6FGC+T=-dzn4A@mail.gmail.com/
>>>>>>>> 3.
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> https://lists.apache.org/thread.html/r86a9a390f023a0298488084bdcb4caaa4bedfe406f1c86a1ca4bdac3%40%3Cdev.nifi.apache.org%3E
>>>>>>>> 4.
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme+and+API+Compatibility
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Thu, Jun 18, 2020 at 9:36 PM Otto Fowler <
>>>> ottobackwards@gmail.com
>>>>>> 
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> As long as it isn’t renamed to zeek or something, I think we
>>>>> should
>>>>>>>> change
>>>>>>>>> it and not look back.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On June 18, 2020 at 19:05:38, Mike Thomsen (
>>>> mikerthomsen@gmail.com
>>>>> )
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> As teammates and friends, it was an easy change, even if
>>> code
>>>> was
>>>>>>>>> involved. And I assume much easier than having the courage to
>>> ask
>>>>> for
>>>>>>> it.
>>>>>>>>> 
>>>>>>>>> Ironically, around the same time I had a colleague who was
>>> like
>>>> the
>>>>>>> evil
>>>>>>>>> opposite of that. Friend is the last word any of us would use
>>> to
>>>>>>> describe
>>>>>>>>> him. He was a cautionary tale in why teams have to also
>>> maintain
>>>>>>> defense
>>>>>>>>> mechanisms against toxic people who exploit empathy as a power
>>>>> play;
>>>>>>>> it's a
>>>>>>>>> common tactic of abusers/toxic people to make demands on
>>> people
>>>> to
>>>>>>> change
>>>>>>>>> their behavior to see how compliant they are. That former
>>>>> colleague,
>>>>>> if
>>>>>>>> you
>>>>>>>>> got them talking about their views, could wax eloquent about
>>>>>> tolerance,
>>>>>>>>> inclusiveness, etc. and then without a hint of irony turn
>>> around
>>>>> and
>>>>>>>> wage a
>>>>>>>>> one man war on everyone else.
>>>>>>>>> 
>>>>>>>>> On Thu, Jun 18, 2020 at 11:53 AM Joey Frazee <
>>>>> joey.frazee@icloud.com
>>>>>>>>> .invalid>
>>>>>>>>> 
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> +1
>>>>>>>>>> 
>>>>>>>>>> I’m repeating this from elsewhere but I was on a team 7
>>> years
>>>> ago
>>>>>>>> where a
>>>>>>>>>> teammate asked us to stop using master and slave
>>> terminology,
>>>>> even
>>>>>>>> master
>>>>>>>>>> alone, because it made them uncomfortable. I can’t estimate
>>> how
>>>>>>> common
>>>>>>>>> that
>>>>>>>>>> feeling is but this isn’t a theoretical exercise. As
>>> teammates
>>>>> and
>>>>>>>>> friends,
>>>>>>>>>> it was an easy change, even if code was involved. And I
>>> assume
>>>>> much
>>>>>>>>> easier
>>>>>>>>>> than having the courage to ask for it.
>>>>>>>>>> 
>>>>>>>>>> I’d say it’s also important to note that “but that’s not the
>>>>>> original
>>>>>>>>>> intended word sense” doesn’t alleviate that alienating
>>>>> experience.
>>>>>>>> While
>>>>>>>>>> potentially a matter of fact of the intent for some uses, “I
>>>> want
>>>>>> to
>>>>>>>> use
>>>>>>>>>> that word” is pretty unfriendly stacked against “that makes
>>> me
>>>>> feel
>>>>>>>>>> unwelcome”.
>>>>>>>>>> 
>>>>>>>>>> Two guidelines from the code of conduct seem particularly
>>>>> apropos:
>>>>>>>>>> 
>>>>>>>>>> - Be empathetic, welcoming, friendly, and patient
>>>>>>>>>> 
>>>>>>>>>> - Be careful in the words that we choose
>>>>>>>>>> 
>>>>>>>>>> AFAICT there’s not an escape hatch for code, tools, or
>>> effort.
>>>>>>>>>> 
>>>>>>>>>> -joey
>>>>>>>>>> 
>>>>>>>>>> On Jun 18, 2020, 10:05 AM -0500, Edward Armes <
>>>>>>> edward.armes@gmail.com
>>>>>>>>> ,
>>>>>>>>>> wrote:
>>>>>>>>>>> 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 Uwe@Moosheimer.com, <
>>>>>> Uwe@moosheimer.com
>>>>>>>> 
>>>>>>>>>> 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 <
>>>> tkurc@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 <
>>>>>>>>> alopresto@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
>>>>>>>>>>>>>>> alopresto@apache.org
>>>>>>>>>>>>>>> alopresto.apache@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.armes@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, <
>>>>>>>>>> alopresto@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
>>>>>>>>>>>>>>>>> alopresto@apache.org
>>>>>>>>>>>>>>>>> alopresto.apache@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.witt@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 <
>>>>>>>>>> tkurc@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
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 

Re: [DISCUSS] rename master branch, look through code for other related issues

[Tony Kurc <tr...@gmail.com>]

After a quick review, in nifi, I wasn't able to find references to the
properties Joe mentioned, but I did use crude recursive greps to look. A
majority of the blacklist references were in wali in method names and log
messages. Picking a more useful term in wali would probably make sense.
I'll make a jira, but we'd need to be a bit more deliberate about when that
change could happen, no? Long story short, since assumptions were maybe a
bit off (i.e. not an additive change), I think a later release may make
sense.

There was a blacklist property in nifi-cpp. I'll make a jira and work on a
pr for that.

Most prevalent in my grep analysis related to master/slave were carrying
over terms from dependencies (e.g. MySQL, zookeeper, or third-party libs in
nifi-cpp) and "master key" crypt related stuff.

On Mon, Jul 6, 2020, 6:02 PM Tony Kurc <tr...@gmail.com> wrote:

> Mike,
> I did a quick check to see if anyone had done a jira or pr for #2, so I'll
> take a stab at doing that today.
>
> Tony
>
> On Thu, Jul 2, 2020 at 10:27 PM Mike Thomsen <mi...@gmail.com>
> wrote:
>
>> Didn't see any commits or PRs for any of these yet. Do we want to consider
>> these blockers for 1.12 or hold off until a post 1.12 release?
>>
>> On Mon, Jun 22, 2020 at 12:48 PM Joe Witt <jo...@gmail.com> wrote:
>>
>> > Not that I'm aware of.  All this so far just looks really easy to deal
>> > with.
>> >
>> > On Mon, Jun 22, 2020 at 9:46 AM Mike Thomsen <mi...@gmail.com>
>> > wrote:
>> >
>> > > Out of curiosity... are there any cases you've found where we might
>> have
>> > a
>> > > term misalignment with what another product calls them? Like we might
>> > have
>> > > primary/replica and the supported system uses master/slave?
>> > >
>> > > On Mon, Jun 22, 2020 at 11:32 AM Joe Witt <jo...@gmail.com> wrote:
>> > >
>> > > > ...additional note after reviewing the presence of
>> > 'whitelist/blacklist'
>> > > I
>> > > > remain of the view what we need to do here is easy.  There is
>> minimal
>> > API
>> > > > impact and it appears to be just the nifi.properties file for a
>> > property.
>> > > > Other code changes do not appear to be API related and seem fair
>> game
>> > > now.
>> > > > We can easily support the old naming and create a different property
>> > name
>> > > > for the properties file case.  We dont need to wait for any major
>> > release
>> > > > as far as I can tell
>> > > >
>> > > > Thanks
>> > > >
>> > > > On Sat, Jun 20, 2020 at 4:47 PM Mike Thomsen <
>> mikerthomsen@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > I think just shooting for #1 right away makes sense, but #2 will
>> need
>> > > to
>> > > > be
>> > > > > done as part of a major release. I think we go all-in to be
>> > consistent
>> > > on
>> > > > > allow/block vs white/black and similar changes that are needed. We
>> > > should
>> > > > > also avoid things like the proposal to use "allowlist/denylist"
>> that
>> > > > other
>> > > > > teams are debating since that is just a pointless spawning of
>> > > neologisms
>> > > > > for the sake of creating them. The best approach is to use clear,
>> > > concise
>> > > > > language that is preferably as limited on jargon as possible, and
>> I
>> > > feel
>> > > > > like those teams are missing the mark on that. If we do find
>> language
>> > > > that
>> > > > > needs to be changed in descriptor name fields, I think it would
>> also
>> > > > > prevent any problems by making part of the messaging being that
>> those
>> > > > > changes are non-negotiable as they represent real potential
>> breakage
>> > to
>> > > > > users. I think most folks would be fine with that, but it might
>> need
>> > to
>> > > > be
>> > > > > spelled out for some that there is a balance that has to be
>> > maintained
>> > > > > until a proper transition can take place.
>> > > > >
>> > > > > On Sat, Jun 20, 2020 at 6:23 PM Tony Kurc <tk...@apache.org>
>> wrote:
>> > > > >
>> > > > > > This discussion has died down quite a bit. I got the impression
>> > there
>> > > > was
>> > > > > > at least majority support, although not consensus, for Joe's two
>> > > > > proposals
>> > > > > > [1].
>> > > > > >
>> > > > > > #1 ( s/master/main/ ) is probably the most straightforward -
>> change
>> > > > > > developer docs and make the necessary repository changes. Can be
>> > done
>> > > > > > seemingly independent of software releases. Is it time for
>> jiras on
>> > > > that?
>> > > > > > My sense is that 'main' appears to be a common term that
>> projects
>> > > > appear
>> > > > > to
>> > > > > > be gravitating to, but that discussion still abounds. This
>> comment
>> > > [2]
>> > > > on
>> > > > > > the git project's mailing list hurt my head quite a bit, but
>> > > definitely
>> > > > > > reinforced that main makes a whole lot more sense than master,
>> as
>> > > Andy
>> > > > > > pointed out [3].
>> > > > > >
>> > > > > > #2 is a bit less straightforward, going to require a code change
>> > and
>> > > > > figure
>> > > > > > out where that fits with the versioning scheme commitments [4].
>> Do
>> > we
>> > > > > > support both allow/block (or deny?) along with white/black in a
>> > minor
>> > > > > > release, and then prune white/black on next major release?
>> > > > > >
>> > > > > > 1.
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://lists.apache.org/thread.html/r6c133a31f882d3c818e63fa44dbc451f61d423a22dbe72396483127b%40%3Cdev.nifi.apache.org%3E
>> > > > > >
>> > > > > > 2.
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://lore.kernel.org/git/CANgJU+Ut+ANPHud1JQw1Wo+zb37_=EWx-vgap6FGC+T=-dzn4A@mail.gmail.com/
>> > > > > > 3.
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://lists.apache.org/thread.html/r86a9a390f023a0298488084bdcb4caaa4bedfe406f1c86a1ca4bdac3%40%3Cdev.nifi.apache.org%3E
>> > > > > > 4.
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme+and+API+Compatibility
>> > > > > >
>> > > > > >
>> > > > > > On Thu, Jun 18, 2020 at 9:36 PM Otto Fowler <
>> > ottobackwards@gmail.com
>> > > >
>> > > > > > wrote:
>> > > > > >
>> > > > > > >  As long as it isn’t renamed to zeek or something, I think we
>> > > should
>> > > > > > change
>> > > > > > > it and not look back.
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > On June 18, 2020 at 19:05:38, Mike Thomsen (
>> > mikerthomsen@gmail.com
>> > > )
>> > > > > > wrote:
>> > > > > > >
>> > > > > > > > As teammates and friends, it was an easy change, even if
>> code
>> > was
>> > > > > > > involved. And I assume much easier than having the courage to
>> ask
>> > > for
>> > > > > it.
>> > > > > > >
>> > > > > > > Ironically, around the same time I had a colleague who was
>> like
>> > the
>> > > > > evil
>> > > > > > > opposite of that. Friend is the last word any of us would use
>> to
>> > > > > describe
>> > > > > > > him. He was a cautionary tale in why teams have to also
>> maintain
>> > > > > defense
>> > > > > > > mechanisms against toxic people who exploit empathy as a power
>> > > play;
>> > > > > > it's a
>> > > > > > > common tactic of abusers/toxic people to make demands on
>> people
>> > to
>> > > > > change
>> > > > > > > their behavior to see how compliant they are. That former
>> > > colleague,
>> > > > if
>> > > > > > you
>> > > > > > > got them talking about their views, could wax eloquent about
>> > > > tolerance,
>> > > > > > > inclusiveness, etc. and then without a hint of irony turn
>> around
>> > > and
>> > > > > > wage a
>> > > > > > > one man war on everyone else.
>> > > > > > >
>> > > > > > > On Thu, Jun 18, 2020 at 11:53 AM Joey Frazee <
>> > > joey.frazee@icloud.com
>> > > > > > > .invalid>
>> > > > > > >
>> > > > > > > wrote:
>> > > > > > >
>> > > > > > > > +1
>> > > > > > > >
>> > > > > > > > I’m repeating this from elsewhere but I was on a team 7
>> years
>> > ago
>> > > > > > where a
>> > > > > > > > teammate asked us to stop using master and slave
>> terminology,
>> > > even
>> > > > > > master
>> > > > > > > > alone, because it made them uncomfortable. I can’t estimate
>> how
>> > > > > common
>> > > > > > > that
>> > > > > > > > feeling is but this isn’t a theoretical exercise. As
>> teammates
>> > > and
>> > > > > > > friends,
>> > > > > > > > it was an easy change, even if code was involved. And I
>> assume
>> > > much
>> > > > > > > easier
>> > > > > > > > than having the courage to ask for it.
>> > > > > > > >
>> > > > > > > > I’d say it’s also important to note that “but that’s not the
>> > > > original
>> > > > > > > > intended word sense” doesn’t alleviate that alienating
>> > > experience.
>> > > > > > While
>> > > > > > > > potentially a matter of fact of the intent for some uses, “I
>> > want
>> > > > to
>> > > > > > use
>> > > > > > > > that word” is pretty unfriendly stacked against “that makes
>> me
>> > > feel
>> > > > > > > > unwelcome”.
>> > > > > > > >
>> > > > > > > > Two guidelines from the code of conduct seem particularly
>> > > apropos:
>> > > > > > > >
>> > > > > > > > - Be empathetic, welcoming, friendly, and patient
>> > > > > > > >
>> > > > > > > > - Be careful in the words that we choose
>> > > > > > > >
>> > > > > > > > AFAICT there’s not an escape hatch for code, tools, or
>> effort.
>> > > > > > > >
>> > > > > > > > -joey
>> > > > > > > >
>> > > > > > > > On Jun 18, 2020, 10:05 AM -0500, Edward Armes <
>> > > > > edward.armes@gmail.com
>> > > > > > >,
>> > > > > > > > wrote:
>> > > > > > > > > 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 Uwe@Moosheimer.com, <
>> > > > Uwe@moosheimer.com
>> > > > > >
>> > > > > > > > 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 <
>> > tkurc@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 <
>> > > > > > > alopresto@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
>> > > > > > > > > > > > > alopresto@apache.org
>> > > > > > > > > > > > > alopresto.apache@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.armes@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, <
>> > > > > > > > alopresto@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
>> > > > > > > > > > > > > > > alopresto@apache.org
>> > > > > > > > > > > > > > > alopresto.apache@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.witt@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 <
>> > > > > > > > tkurc@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
>> > > > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>

Re: [DISCUSS] rename master branch, look through code for other related issues

[Tony Kurc <tr...@gmail.com>]

Mike,
I did a quick check to see if anyone had done a jira or pr for #2, so I'll
take a stab at doing that today.

Tony

On Thu, Jul 2, 2020 at 10:27 PM Mike Thomsen <mi...@gmail.com> wrote:

> Didn't see any commits or PRs for any of these yet. Do we want to consider
> these blockers for 1.12 or hold off until a post 1.12 release?
>
> On Mon, Jun 22, 2020 at 12:48 PM Joe Witt <jo...@gmail.com> wrote:
>
> > Not that I'm aware of.  All this so far just looks really easy to deal
> > with.
> >
> > On Mon, Jun 22, 2020 at 9:46 AM Mike Thomsen <mi...@gmail.com>
> > wrote:
> >
> > > Out of curiosity... are there any cases you've found where we might
> have
> > a
> > > term misalignment with what another product calls them? Like we might
> > have
> > > primary/replica and the supported system uses master/slave?
> > >
> > > On Mon, Jun 22, 2020 at 11:32 AM Joe Witt <jo...@gmail.com> wrote:
> > >
> > > > ...additional note after reviewing the presence of
> > 'whitelist/blacklist'
> > > I
> > > > remain of the view what we need to do here is easy.  There is minimal
> > API
> > > > impact and it appears to be just the nifi.properties file for a
> > property.
> > > > Other code changes do not appear to be API related and seem fair game
> > > now.
> > > > We can easily support the old naming and create a different property
> > name
> > > > for the properties file case.  We dont need to wait for any major
> > release
> > > > as far as I can tell
> > > >
> > > > Thanks
> > > >
> > > > On Sat, Jun 20, 2020 at 4:47 PM Mike Thomsen <mikerthomsen@gmail.com
> >
> > > > wrote:
> > > >
> > > > > I think just shooting for #1 right away makes sense, but #2 will
> need
> > > to
> > > > be
> > > > > done as part of a major release. I think we go all-in to be
> > consistent
> > > on
> > > > > allow/block vs white/black and similar changes that are needed. We
> > > should
> > > > > also avoid things like the proposal to use "allowlist/denylist"
> that
> > > > other
> > > > > teams are debating since that is just a pointless spawning of
> > > neologisms
> > > > > for the sake of creating them. The best approach is to use clear,
> > > concise
> > > > > language that is preferably as limited on jargon as possible, and I
> > > feel
> > > > > like those teams are missing the mark on that. If we do find
> language
> > > > that
> > > > > needs to be changed in descriptor name fields, I think it would
> also
> > > > > prevent any problems by making part of the messaging being that
> those
> > > > > changes are non-negotiable as they represent real potential
> breakage
> > to
> > > > > users. I think most folks would be fine with that, but it might
> need
> > to
> > > > be
> > > > > spelled out for some that there is a balance that has to be
> > maintained
> > > > > until a proper transition can take place.
> > > > >
> > > > > On Sat, Jun 20, 2020 at 6:23 PM Tony Kurc <tk...@apache.org>
> wrote:
> > > > >
> > > > > > This discussion has died down quite a bit. I got the impression
> > there
> > > > was
> > > > > > at least majority support, although not consensus, for Joe's two
> > > > > proposals
> > > > > > [1].
> > > > > >
> > > > > > #1 ( s/master/main/ ) is probably the most straightforward -
> change
> > > > > > developer docs and make the necessary repository changes. Can be
> > done
> > > > > > seemingly independent of software releases. Is it time for jiras
> on
> > > > that?
> > > > > > My sense is that 'main' appears to be a common term that projects
> > > > appear
> > > > > to
> > > > > > be gravitating to, but that discussion still abounds. This
> comment
> > > [2]
> > > > on
> > > > > > the git project's mailing list hurt my head quite a bit, but
> > > definitely
> > > > > > reinforced that main makes a whole lot more sense than master, as
> > > Andy
> > > > > > pointed out [3].
> > > > > >
> > > > > > #2 is a bit less straightforward, going to require a code change
> > and
> > > > > figure
> > > > > > out where that fits with the versioning scheme commitments [4].
> Do
> > we
> > > > > > support both allow/block (or deny?) along with white/black in a
> > minor
> > > > > > release, and then prune white/black on next major release?
> > > > > >
> > > > > > 1.
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/r6c133a31f882d3c818e63fa44dbc451f61d423a22dbe72396483127b%40%3Cdev.nifi.apache.org%3E
> > > > > >
> > > > > > 2.
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://lore.kernel.org/git/CANgJU+Ut+ANPHud1JQw1Wo+zb37_=EWx-vgap6FGC+T=-dzn4A@mail.gmail.com/
> > > > > > 3.
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/r86a9a390f023a0298488084bdcb4caaa4bedfe406f1c86a1ca4bdac3%40%3Cdev.nifi.apache.org%3E
> > > > > > 4.
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme+and+API+Compatibility
> > > > > >
> > > > > >
> > > > > > On Thu, Jun 18, 2020 at 9:36 PM Otto Fowler <
> > ottobackwards@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > >  As long as it isn’t renamed to zeek or something, I think we
> > > should
> > > > > > change
> > > > > > > it and not look back.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On June 18, 2020 at 19:05:38, Mike Thomsen (
> > mikerthomsen@gmail.com
> > > )
> > > > > > wrote:
> > > > > > >
> > > > > > > > As teammates and friends, it was an easy change, even if code
> > was
> > > > > > > involved. And I assume much easier than having the courage to
> ask
> > > for
> > > > > it.
> > > > > > >
> > > > > > > Ironically, around the same time I had a colleague who was like
> > the
> > > > > evil
> > > > > > > opposite of that. Friend is the last word any of us would use
> to
> > > > > describe
> > > > > > > him. He was a cautionary tale in why teams have to also
> maintain
> > > > > defense
> > > > > > > mechanisms against toxic people who exploit empathy as a power
> > > play;
> > > > > > it's a
> > > > > > > common tactic of abusers/toxic people to make demands on people
> > to
> > > > > change
> > > > > > > their behavior to see how compliant they are. That former
> > > colleague,
> > > > if
> > > > > > you
> > > > > > > got them talking about their views, could wax eloquent about
> > > > tolerance,
> > > > > > > inclusiveness, etc. and then without a hint of irony turn
> around
> > > and
> > > > > > wage a
> > > > > > > one man war on everyone else.
> > > > > > >
> > > > > > > On Thu, Jun 18, 2020 at 11:53 AM Joey Frazee <
> > > joey.frazee@icloud.com
> > > > > > > .invalid>
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > +1
> > > > > > > >
> > > > > > > > I’m repeating this from elsewhere but I was on a team 7 years
> > ago
> > > > > > where a
> > > > > > > > teammate asked us to stop using master and slave terminology,
> > > even
> > > > > > master
> > > > > > > > alone, because it made them uncomfortable. I can’t estimate
> how
> > > > > common
> > > > > > > that
> > > > > > > > feeling is but this isn’t a theoretical exercise. As
> teammates
> > > and
> > > > > > > friends,
> > > > > > > > it was an easy change, even if code was involved. And I
> assume
> > > much
> > > > > > > easier
> > > > > > > > than having the courage to ask for it.
> > > > > > > >
> > > > > > > > I’d say it’s also important to note that “but that’s not the
> > > > original
> > > > > > > > intended word sense” doesn’t alleviate that alienating
> > > experience.
> > > > > > While
> > > > > > > > potentially a matter of fact of the intent for some uses, “I
> > want
> > > > to
> > > > > > use
> > > > > > > > that word” is pretty unfriendly stacked against “that makes
> me
> > > feel
> > > > > > > > unwelcome”.
> > > > > > > >
> > > > > > > > Two guidelines from the code of conduct seem particularly
> > > apropos:
> > > > > > > >
> > > > > > > > - Be empathetic, welcoming, friendly, and patient
> > > > > > > >
> > > > > > > > - Be careful in the words that we choose
> > > > > > > >
> > > > > > > > AFAICT there’s not an escape hatch for code, tools, or
> effort.
> > > > > > > >
> > > > > > > > -joey
> > > > > > > >
> > > > > > > > On Jun 18, 2020, 10:05 AM -0500, Edward Armes <
> > > > > edward.armes@gmail.com
> > > > > > >,
> > > > > > > > wrote:
> > > > > > > > > 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 Uwe@Moosheimer.com, <
> > > > Uwe@moosheimer.com
> > > > > >
> > > > > > > > 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 <
> > tkurc@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 <
> > > > > > > alopresto@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
> > > > > > > > > > > > > alopresto@apache.org
> > > > > > > > > > > > > alopresto.apache@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.armes@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, <
> > > > > > > > alopresto@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
> > > > > > > > > > > > > > > alopresto@apache.org
> > > > > > > > > > > > > > > alopresto.apache@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.witt@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 <
> > > > > > > > tkurc@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
> > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] rename master branch, look through code for other related issues

[Mike Thomsen <mi...@gmail.com>]

Didn't see any commits or PRs for any of these yet. Do we want to consider
these blockers for 1.12 or hold off until a post 1.12 release?

On Mon, Jun 22, 2020 at 12:48 PM Joe Witt <jo...@gmail.com> wrote:

> Not that I'm aware of.  All this so far just looks really easy to deal
> with.
>
> On Mon, Jun 22, 2020 at 9:46 AM Mike Thomsen <mi...@gmail.com>
> wrote:
>
> > Out of curiosity... are there any cases you've found where we might have
> a
> > term misalignment with what another product calls them? Like we might
> have
> > primary/replica and the supported system uses master/slave?
> >
> > On Mon, Jun 22, 2020 at 11:32 AM Joe Witt <jo...@gmail.com> wrote:
> >
> > > ...additional note after reviewing the presence of
> 'whitelist/blacklist'
> > I
> > > remain of the view what we need to do here is easy.  There is minimal
> API
> > > impact and it appears to be just the nifi.properties file for a
> property.
> > > Other code changes do not appear to be API related and seem fair game
> > now.
> > > We can easily support the old naming and create a different property
> name
> > > for the properties file case.  We dont need to wait for any major
> release
> > > as far as I can tell
> > >
> > > Thanks
> > >
> > > On Sat, Jun 20, 2020 at 4:47 PM Mike Thomsen <mi...@gmail.com>
> > > wrote:
> > >
> > > > I think just shooting for #1 right away makes sense, but #2 will need
> > to
> > > be
> > > > done as part of a major release. I think we go all-in to be
> consistent
> > on
> > > > allow/block vs white/black and similar changes that are needed. We
> > should
> > > > also avoid things like the proposal to use "allowlist/denylist" that
> > > other
> > > > teams are debating since that is just a pointless spawning of
> > neologisms
> > > > for the sake of creating them. The best approach is to use clear,
> > concise
> > > > language that is preferably as limited on jargon as possible, and I
> > feel
> > > > like those teams are missing the mark on that. If we do find language
> > > that
> > > > needs to be changed in descriptor name fields, I think it would also
> > > > prevent any problems by making part of the messaging being that those
> > > > changes are non-negotiable as they represent real potential breakage
> to
> > > > users. I think most folks would be fine with that, but it might need
> to
> > > be
> > > > spelled out for some that there is a balance that has to be
> maintained
> > > > until a proper transition can take place.
> > > >
> > > > On Sat, Jun 20, 2020 at 6:23 PM Tony Kurc <tk...@apache.org> wrote:
> > > >
> > > > > This discussion has died down quite a bit. I got the impression
> there
> > > was
> > > > > at least majority support, although not consensus, for Joe's two
> > > > proposals
> > > > > [1].
> > > > >
> > > > > #1 ( s/master/main/ ) is probably the most straightforward - change
> > > > > developer docs and make the necessary repository changes. Can be
> done
> > > > > seemingly independent of software releases. Is it time for jiras on
> > > that?
> > > > > My sense is that 'main' appears to be a common term that projects
> > > appear
> > > > to
> > > > > be gravitating to, but that discussion still abounds. This comment
> > [2]
> > > on
> > > > > the git project's mailing list hurt my head quite a bit, but
> > definitely
> > > > > reinforced that main makes a whole lot more sense than master, as
> > Andy
> > > > > pointed out [3].
> > > > >
> > > > > #2 is a bit less straightforward, going to require a code change
> and
> > > > figure
> > > > > out where that fits with the versioning scheme commitments [4]. Do
> we
> > > > > support both allow/block (or deny?) along with white/black in a
> minor
> > > > > release, and then prune white/black on next major release?
> > > > >
> > > > > 1.
> > > > >
> > > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/r6c133a31f882d3c818e63fa44dbc451f61d423a22dbe72396483127b%40%3Cdev.nifi.apache.org%3E
> > > > >
> > > > > 2.
> > > > >
> > > > >
> > > >
> > >
> >
> https://lore.kernel.org/git/CANgJU+Ut+ANPHud1JQw1Wo+zb37_=EWx-vgap6FGC+T=-dzn4A@mail.gmail.com/
> > > > > 3.
> > > > >
> > > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/r86a9a390f023a0298488084bdcb4caaa4bedfe406f1c86a1ca4bdac3%40%3Cdev.nifi.apache.org%3E
> > > > > 4.
> > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme+and+API+Compatibility
> > > > >
> > > > >
> > > > > On Thu, Jun 18, 2020 at 9:36 PM Otto Fowler <
> ottobackwards@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > >  As long as it isn’t renamed to zeek or something, I think we
> > should
> > > > > change
> > > > > > it and not look back.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On June 18, 2020 at 19:05:38, Mike Thomsen (
> mikerthomsen@gmail.com
> > )
> > > > > wrote:
> > > > > >
> > > > > > > As teammates and friends, it was an easy change, even if code
> was
> > > > > > involved. And I assume much easier than having the courage to ask
> > for
> > > > it.
> > > > > >
> > > > > > Ironically, around the same time I had a colleague who was like
> the
> > > > evil
> > > > > > opposite of that. Friend is the last word any of us would use to
> > > > describe
> > > > > > him. He was a cautionary tale in why teams have to also maintain
> > > > defense
> > > > > > mechanisms against toxic people who exploit empathy as a power
> > play;
> > > > > it's a
> > > > > > common tactic of abusers/toxic people to make demands on people
> to
> > > > change
> > > > > > their behavior to see how compliant they are. That former
> > colleague,
> > > if
> > > > > you
> > > > > > got them talking about their views, could wax eloquent about
> > > tolerance,
> > > > > > inclusiveness, etc. and then without a hint of irony turn around
> > and
> > > > > wage a
> > > > > > one man war on everyone else.
> > > > > >
> > > > > > On Thu, Jun 18, 2020 at 11:53 AM Joey Frazee <
> > joey.frazee@icloud.com
> > > > > > .invalid>
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > I’m repeating this from elsewhere but I was on a team 7 years
> ago
> > > > > where a
> > > > > > > teammate asked us to stop using master and slave terminology,
> > even
> > > > > master
> > > > > > > alone, because it made them uncomfortable. I can’t estimate how
> > > > common
> > > > > > that
> > > > > > > feeling is but this isn’t a theoretical exercise. As teammates
> > and
> > > > > > friends,
> > > > > > > it was an easy change, even if code was involved. And I assume
> > much
> > > > > > easier
> > > > > > > than having the courage to ask for it.
> > > > > > >
> > > > > > > I’d say it’s also important to note that “but that’s not the
> > > original
> > > > > > > intended word sense” doesn’t alleviate that alienating
> > experience.
> > > > > While
> > > > > > > potentially a matter of fact of the intent for some uses, “I
> want
> > > to
> > > > > use
> > > > > > > that word” is pretty unfriendly stacked against “that makes me
> > feel
> > > > > > > unwelcome”.
> > > > > > >
> > > > > > > Two guidelines from the code of conduct seem particularly
> > apropos:
> > > > > > >
> > > > > > > - Be empathetic, welcoming, friendly, and patient
> > > > > > >
> > > > > > > - Be careful in the words that we choose
> > > > > > >
> > > > > > > AFAICT there’s not an escape hatch for code, tools, or effort.
> > > > > > >
> > > > > > > -joey
> > > > > > >
> > > > > > > On Jun 18, 2020, 10:05 AM -0500, Edward Armes <
> > > > edward.armes@gmail.com
> > > > > >,
> > > > > > > wrote:
> > > > > > > > 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 Uwe@Moosheimer.com, <
> > > Uwe@moosheimer.com
> > > > >
> > > > > > > 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 <
> tkurc@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 <
> > > > > > alopresto@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
> > > > > > > > > > > > alopresto@apache.org
> > > > > > > > > > > > alopresto.apache@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.armes@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, <
> > > > > > > alopresto@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
> > > > > > > > > > > > > > alopresto@apache.org
> > > > > > > > > > > > > > alopresto.apache@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.witt@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 <
> > > > > > > tkurc@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
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] rename master branch, look through code for other related issues

[Joe Witt <jo...@gmail.com>]

Not that I'm aware of.  All this so far just looks really easy to deal with.

On Mon, Jun 22, 2020 at 9:46 AM Mike Thomsen <mi...@gmail.com> wrote:

> Out of curiosity... are there any cases you've found where we might have a
> term misalignment with what another product calls them? Like we might have
> primary/replica and the supported system uses master/slave?
>
> On Mon, Jun 22, 2020 at 11:32 AM Joe Witt <jo...@gmail.com> wrote:
>
> > ...additional note after reviewing the presence of 'whitelist/blacklist'
> I
> > remain of the view what we need to do here is easy.  There is minimal API
> > impact and it appears to be just the nifi.properties file for a property.
> > Other code changes do not appear to be API related and seem fair game
> now.
> > We can easily support the old naming and create a different property name
> > for the properties file case.  We dont need to wait for any major release
> > as far as I can tell
> >
> > Thanks
> >
> > On Sat, Jun 20, 2020 at 4:47 PM Mike Thomsen <mi...@gmail.com>
> > wrote:
> >
> > > I think just shooting for #1 right away makes sense, but #2 will need
> to
> > be
> > > done as part of a major release. I think we go all-in to be consistent
> on
> > > allow/block vs white/black and similar changes that are needed. We
> should
> > > also avoid things like the proposal to use "allowlist/denylist" that
> > other
> > > teams are debating since that is just a pointless spawning of
> neologisms
> > > for the sake of creating them. The best approach is to use clear,
> concise
> > > language that is preferably as limited on jargon as possible, and I
> feel
> > > like those teams are missing the mark on that. If we do find language
> > that
> > > needs to be changed in descriptor name fields, I think it would also
> > > prevent any problems by making part of the messaging being that those
> > > changes are non-negotiable as they represent real potential breakage to
> > > users. I think most folks would be fine with that, but it might need to
> > be
> > > spelled out for some that there is a balance that has to be maintained
> > > until a proper transition can take place.
> > >
> > > On Sat, Jun 20, 2020 at 6:23 PM Tony Kurc <tk...@apache.org> wrote:
> > >
> > > > This discussion has died down quite a bit. I got the impression there
> > was
> > > > at least majority support, although not consensus, for Joe's two
> > > proposals
> > > > [1].
> > > >
> > > > #1 ( s/master/main/ ) is probably the most straightforward - change
> > > > developer docs and make the necessary repository changes. Can be done
> > > > seemingly independent of software releases. Is it time for jiras on
> > that?
> > > > My sense is that 'main' appears to be a common term that projects
> > appear
> > > to
> > > > be gravitating to, but that discussion still abounds. This comment
> [2]
> > on
> > > > the git project's mailing list hurt my head quite a bit, but
> definitely
> > > > reinforced that main makes a whole lot more sense than master, as
> Andy
> > > > pointed out [3].
> > > >
> > > > #2 is a bit less straightforward, going to require a code change and
> > > figure
> > > > out where that fits with the versioning scheme commitments [4]. Do we
> > > > support both allow/block (or deny?) along with white/black in a minor
> > > > release, and then prune white/black on next major release?
> > > >
> > > > 1.
> > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/r6c133a31f882d3c818e63fa44dbc451f61d423a22dbe72396483127b%40%3Cdev.nifi.apache.org%3E
> > > >
> > > > 2.
> > > >
> > > >
> > >
> >
> https://lore.kernel.org/git/CANgJU+Ut+ANPHud1JQw1Wo+zb37_=EWx-vgap6FGC+T=-dzn4A@mail.gmail.com/
> > > > 3.
> > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/r86a9a390f023a0298488084bdcb4caaa4bedfe406f1c86a1ca4bdac3%40%3Cdev.nifi.apache.org%3E
> > > > 4.
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme+and+API+Compatibility
> > > >
> > > >
> > > > On Thu, Jun 18, 2020 at 9:36 PM Otto Fowler <ottobackwards@gmail.com
> >
> > > > wrote:
> > > >
> > > > >  As long as it isn’t renamed to zeek or something, I think we
> should
> > > > change
> > > > > it and not look back.
> > > > >
> > > > >
> > > > >
> > > > > On June 18, 2020 at 19:05:38, Mike Thomsen (mikerthomsen@gmail.com
> )
> > > > wrote:
> > > > >
> > > > > > As teammates and friends, it was an easy change, even if code was
> > > > > involved. And I assume much easier than having the courage to ask
> for
> > > it.
> > > > >
> > > > > Ironically, around the same time I had a colleague who was like the
> > > evil
> > > > > opposite of that. Friend is the last word any of us would use to
> > > describe
> > > > > him. He was a cautionary tale in why teams have to also maintain
> > > defense
> > > > > mechanisms against toxic people who exploit empathy as a power
> play;
> > > > it's a
> > > > > common tactic of abusers/toxic people to make demands on people to
> > > change
> > > > > their behavior to see how compliant they are. That former
> colleague,
> > if
> > > > you
> > > > > got them talking about their views, could wax eloquent about
> > tolerance,
> > > > > inclusiveness, etc. and then without a hint of irony turn around
> and
> > > > wage a
> > > > > one man war on everyone else.
> > > > >
> > > > > On Thu, Jun 18, 2020 at 11:53 AM Joey Frazee <
> joey.frazee@icloud.com
> > > > > .invalid>
> > > > >
> > > > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > I’m repeating this from elsewhere but I was on a team 7 years ago
> > > > where a
> > > > > > teammate asked us to stop using master and slave terminology,
> even
> > > > master
> > > > > > alone, because it made them uncomfortable. I can’t estimate how
> > > common
> > > > > that
> > > > > > feeling is but this isn’t a theoretical exercise. As teammates
> and
> > > > > friends,
> > > > > > it was an easy change, even if code was involved. And I assume
> much
> > > > > easier
> > > > > > than having the courage to ask for it.
> > > > > >
> > > > > > I’d say it’s also important to note that “but that’s not the
> > original
> > > > > > intended word sense” doesn’t alleviate that alienating
> experience.
> > > > While
> > > > > > potentially a matter of fact of the intent for some uses, “I want
> > to
> > > > use
> > > > > > that word” is pretty unfriendly stacked against “that makes me
> feel
> > > > > > unwelcome”.
> > > > > >
> > > > > > Two guidelines from the code of conduct seem particularly
> apropos:
> > > > > >
> > > > > > - Be empathetic, welcoming, friendly, and patient
> > > > > >
> > > > > > - Be careful in the words that we choose
> > > > > >
> > > > > > AFAICT there’s not an escape hatch for code, tools, or effort.
> > > > > >
> > > > > > -joey
> > > > > >
> > > > > > On Jun 18, 2020, 10:05 AM -0500, Edward Armes <
> > > edward.armes@gmail.com
> > > > >,
> > > > > > wrote:
> > > > > > > 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 Uwe@Moosheimer.com, <
> > Uwe@moosheimer.com
> > > >
> > > > > > 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 <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 <
> > > > > alopresto@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
> > > > > > > > > > > alopresto@apache.org
> > > > > > > > > > > alopresto.apache@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.armes@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, <
> > > > > > alopresto@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
> > > > > > > > > > > > > alopresto@apache.org
> > > > > > > > > > > > > alopresto.apache@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.witt@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 <
> > > > > > tkurc@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
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] rename master branch, look through code for other related issues

[Mike Thomsen <mi...@gmail.com>]

Out of curiosity... are there any cases you've found where we might have a
term misalignment with what another product calls them? Like we might have
primary/replica and the supported system uses master/slave?

On Mon, Jun 22, 2020 at 11:32 AM Joe Witt <jo...@gmail.com> wrote:

> ...additional note after reviewing the presence of 'whitelist/blacklist' I
> remain of the view what we need to do here is easy.  There is minimal API
> impact and it appears to be just the nifi.properties file for a property.
> Other code changes do not appear to be API related and seem fair game now.
> We can easily support the old naming and create a different property name
> for the properties file case.  We dont need to wait for any major release
> as far as I can tell
>
> Thanks
>
> On Sat, Jun 20, 2020 at 4:47 PM Mike Thomsen <mi...@gmail.com>
> wrote:
>
> > I think just shooting for #1 right away makes sense, but #2 will need to
> be
> > done as part of a major release. I think we go all-in to be consistent on
> > allow/block vs white/black and similar changes that are needed. We should
> > also avoid things like the proposal to use "allowlist/denylist" that
> other
> > teams are debating since that is just a pointless spawning of neologisms
> > for the sake of creating them. The best approach is to use clear, concise
> > language that is preferably as limited on jargon as possible, and I feel
> > like those teams are missing the mark on that. If we do find language
> that
> > needs to be changed in descriptor name fields, I think it would also
> > prevent any problems by making part of the messaging being that those
> > changes are non-negotiable as they represent real potential breakage to
> > users. I think most folks would be fine with that, but it might need to
> be
> > spelled out for some that there is a balance that has to be maintained
> > until a proper transition can take place.
> >
> > On Sat, Jun 20, 2020 at 6:23 PM Tony Kurc <tk...@apache.org> wrote:
> >
> > > This discussion has died down quite a bit. I got the impression there
> was
> > > at least majority support, although not consensus, for Joe's two
> > proposals
> > > [1].
> > >
> > > #1 ( s/master/main/ ) is probably the most straightforward - change
> > > developer docs and make the necessary repository changes. Can be done
> > > seemingly independent of software releases. Is it time for jiras on
> that?
> > > My sense is that 'main' appears to be a common term that projects
> appear
> > to
> > > be gravitating to, but that discussion still abounds. This comment [2]
> on
> > > the git project's mailing list hurt my head quite a bit, but definitely
> > > reinforced that main makes a whole lot more sense than master, as Andy
> > > pointed out [3].
> > >
> > > #2 is a bit less straightforward, going to require a code change and
> > figure
> > > out where that fits with the versioning scheme commitments [4]. Do we
> > > support both allow/block (or deny?) along with white/black in a minor
> > > release, and then prune white/black on next major release?
> > >
> > > 1.
> > >
> > >
> >
> https://lists.apache.org/thread.html/r6c133a31f882d3c818e63fa44dbc451f61d423a22dbe72396483127b%40%3Cdev.nifi.apache.org%3E
> > >
> > > 2.
> > >
> > >
> >
> https://lore.kernel.org/git/CANgJU+Ut+ANPHud1JQw1Wo+zb37_=EWx-vgap6FGC+T=-dzn4A@mail.gmail.com/
> > > 3.
> > >
> > >
> >
> https://lists.apache.org/thread.html/r86a9a390f023a0298488084bdcb4caaa4bedfe406f1c86a1ca4bdac3%40%3Cdev.nifi.apache.org%3E
> > > 4.
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme+and+API+Compatibility
> > >
> > >
> > > On Thu, Jun 18, 2020 at 9:36 PM Otto Fowler <ot...@gmail.com>
> > > wrote:
> > >
> > > >  As long as it isn’t renamed to zeek or something, I think we should
> > > change
> > > > it and not look back.
> > > >
> > > >
> > > >
> > > > On June 18, 2020 at 19:05:38, Mike Thomsen (mikerthomsen@gmail.com)
> > > wrote:
> > > >
> > > > > As teammates and friends, it was an easy change, even if code was
> > > > involved. And I assume much easier than having the courage to ask for
> > it.
> > > >
> > > > Ironically, around the same time I had a colleague who was like the
> > evil
> > > > opposite of that. Friend is the last word any of us would use to
> > describe
> > > > him. He was a cautionary tale in why teams have to also maintain
> > defense
> > > > mechanisms against toxic people who exploit empathy as a power play;
> > > it's a
> > > > common tactic of abusers/toxic people to make demands on people to
> > change
> > > > their behavior to see how compliant they are. That former colleague,
> if
> > > you
> > > > got them talking about their views, could wax eloquent about
> tolerance,
> > > > inclusiveness, etc. and then without a hint of irony turn around and
> > > wage a
> > > > one man war on everyone else.
> > > >
> > > > On Thu, Jun 18, 2020 at 11:53 AM Joey Frazee <joey.frazee@icloud.com
> > > > .invalid>
> > > >
> > > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > I’m repeating this from elsewhere but I was on a team 7 years ago
> > > where a
> > > > > teammate asked us to stop using master and slave terminology, even
> > > master
> > > > > alone, because it made them uncomfortable. I can’t estimate how
> > common
> > > > that
> > > > > feeling is but this isn’t a theoretical exercise. As teammates and
> > > > friends,
> > > > > it was an easy change, even if code was involved. And I assume much
> > > > easier
> > > > > than having the courage to ask for it.
> > > > >
> > > > > I’d say it’s also important to note that “but that’s not the
> original
> > > > > intended word sense” doesn’t alleviate that alienating experience.
> > > While
> > > > > potentially a matter of fact of the intent for some uses, “I want
> to
> > > use
> > > > > that word” is pretty unfriendly stacked against “that makes me feel
> > > > > unwelcome”.
> > > > >
> > > > > Two guidelines from the code of conduct seem particularly apropos:
> > > > >
> > > > > - Be empathetic, welcoming, friendly, and patient
> > > > >
> > > > > - Be careful in the words that we choose
> > > > >
> > > > > AFAICT there’s not an escape hatch for code, tools, or effort.
> > > > >
> > > > > -joey
> > > > >
> > > > > On Jun 18, 2020, 10:05 AM -0500, Edward Armes <
> > edward.armes@gmail.com
> > > >,
> > > > > wrote:
> > > > > > 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 Uwe@Moosheimer.com, <
> Uwe@moosheimer.com
> > >
> > > > > 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 <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 <
> > > > alopresto@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
> > > > > > > > > > alopresto@apache.org
> > > > > > > > > > alopresto.apache@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.armes@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, <
> > > > > alopresto@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
> > > > > > > > > > > > alopresto@apache.org
> > > > > > > > > > > > alopresto.apache@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.witt@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 <
> > > > > tkurc@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
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] rename master branch, look through code for other related issues

[Joe Witt <jo...@gmail.com>]

...additional note after reviewing the presence of 'whitelist/blacklist' I
remain of the view what we need to do here is easy.  There is minimal API
impact and it appears to be just the nifi.properties file for a property.
Other code changes do not appear to be API related and seem fair game now.
We can easily support the old naming and create a different property name
for the properties file case.  We dont need to wait for any major release
as far as I can tell

Thanks

On Sat, Jun 20, 2020 at 4:47 PM Mike Thomsen <mi...@gmail.com> wrote:

> I think just shooting for #1 right away makes sense, but #2 will need to be
> done as part of a major release. I think we go all-in to be consistent on
> allow/block vs white/black and similar changes that are needed. We should
> also avoid things like the proposal to use "allowlist/denylist" that other
> teams are debating since that is just a pointless spawning of neologisms
> for the sake of creating them. The best approach is to use clear, concise
> language that is preferably as limited on jargon as possible, and I feel
> like those teams are missing the mark on that. If we do find language that
> needs to be changed in descriptor name fields, I think it would also
> prevent any problems by making part of the messaging being that those
> changes are non-negotiable as they represent real potential breakage to
> users. I think most folks would be fine with that, but it might need to be
> spelled out for some that there is a balance that has to be maintained
> until a proper transition can take place.
>
> On Sat, Jun 20, 2020 at 6:23 PM Tony Kurc <tk...@apache.org> wrote:
>
> > This discussion has died down quite a bit. I got the impression there was
> > at least majority support, although not consensus, for Joe's two
> proposals
> > [1].
> >
> > #1 ( s/master/main/ ) is probably the most straightforward - change
> > developer docs and make the necessary repository changes. Can be done
> > seemingly independent of software releases. Is it time for jiras on that?
> > My sense is that 'main' appears to be a common term that projects appear
> to
> > be gravitating to, but that discussion still abounds. This comment [2] on
> > the git project's mailing list hurt my head quite a bit, but definitely
> > reinforced that main makes a whole lot more sense than master, as Andy
> > pointed out [3].
> >
> > #2 is a bit less straightforward, going to require a code change and
> figure
> > out where that fits with the versioning scheme commitments [4]. Do we
> > support both allow/block (or deny?) along with white/black in a minor
> > release, and then prune white/black on next major release?
> >
> > 1.
> >
> >
> https://lists.apache.org/thread.html/r6c133a31f882d3c818e63fa44dbc451f61d423a22dbe72396483127b%40%3Cdev.nifi.apache.org%3E
> >
> > 2.
> >
> >
> https://lore.kernel.org/git/CANgJU+Ut+ANPHud1JQw1Wo+zb37_=EWx-vgap6FGC+T=-dzn4A@mail.gmail.com/
> > 3.
> >
> >
> https://lists.apache.org/thread.html/r86a9a390f023a0298488084bdcb4caaa4bedfe406f1c86a1ca4bdac3%40%3Cdev.nifi.apache.org%3E
> > 4.
> >
> >
> https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme+and+API+Compatibility
> >
> >
> > On Thu, Jun 18, 2020 at 9:36 PM Otto Fowler <ot...@gmail.com>
> > wrote:
> >
> > >  As long as it isn’t renamed to zeek or something, I think we should
> > change
> > > it and not look back.
> > >
> > >
> > >
> > > On June 18, 2020 at 19:05:38, Mike Thomsen (mikerthomsen@gmail.com)
> > wrote:
> > >
> > > > As teammates and friends, it was an easy change, even if code was
> > > involved. And I assume much easier than having the courage to ask for
> it.
> > >
> > > Ironically, around the same time I had a colleague who was like the
> evil
> > > opposite of that. Friend is the last word any of us would use to
> describe
> > > him. He was a cautionary tale in why teams have to also maintain
> defense
> > > mechanisms against toxic people who exploit empathy as a power play;
> > it's a
> > > common tactic of abusers/toxic people to make demands on people to
> change
> > > their behavior to see how compliant they are. That former colleague, if
> > you
> > > got them talking about their views, could wax eloquent about tolerance,
> > > inclusiveness, etc. and then without a hint of irony turn around and
> > wage a
> > > one man war on everyone else.
> > >
> > > On Thu, Jun 18, 2020 at 11:53 AM Joey Frazee <joey.frazee@icloud.com
> > > .invalid>
> > >
> > > wrote:
> > >
> > > > +1
> > > >
> > > > I’m repeating this from elsewhere but I was on a team 7 years ago
> > where a
> > > > teammate asked us to stop using master and slave terminology, even
> > master
> > > > alone, because it made them uncomfortable. I can’t estimate how
> common
> > > that
> > > > feeling is but this isn’t a theoretical exercise. As teammates and
> > > friends,
> > > > it was an easy change, even if code was involved. And I assume much
> > > easier
> > > > than having the courage to ask for it.
> > > >
> > > > I’d say it’s also important to note that “but that’s not the original
> > > > intended word sense” doesn’t alleviate that alienating experience.
> > While
> > > > potentially a matter of fact of the intent for some uses, “I want to
> > use
> > > > that word” is pretty unfriendly stacked against “that makes me feel
> > > > unwelcome”.
> > > >
> > > > Two guidelines from the code of conduct seem particularly apropos:
> > > >
> > > > - Be empathetic, welcoming, friendly, and patient
> > > >
> > > > - Be careful in the words that we choose
> > > >
> > > > AFAICT there’s not an escape hatch for code, tools, or effort.
> > > >
> > > > -joey
> > > >
> > > > On Jun 18, 2020, 10:05 AM -0500, Edward Armes <
> edward.armes@gmail.com
> > >,
> > > > wrote:
> > > > > 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 Uwe@Moosheimer.com, <Uwe@moosheimer.com
> >
> > > > 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 <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 <
> > > alopresto@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
> > > > > > > > > alopresto@apache.org
> > > > > > > > > alopresto.apache@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.armes@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, <
> > > > alopresto@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
> > > > > > > > > > > alopresto@apache.org
> > > > > > > > > > > alopresto.apache@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.witt@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 <
> > > > tkurc@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
> > > > > > > > > > >
> > > > > > > > >
> > > > > >
> > > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] rename master branch, look through code for other related issues

[Mike Thomsen <mi...@gmail.com>]

I think just shooting for #1 right away makes sense, but #2 will need to be
done as part of a major release. I think we go all-in to be consistent on
allow/block vs white/black and similar changes that are needed. We should
also avoid things like the proposal to use "allowlist/denylist" that other
teams are debating since that is just a pointless spawning of neologisms
for the sake of creating them. The best approach is to use clear, concise
language that is preferably as limited on jargon as possible, and I feel
like those teams are missing the mark on that. If we do find language that
needs to be changed in descriptor name fields, I think it would also
prevent any problems by making part of the messaging being that those
changes are non-negotiable as they represent real potential breakage to
users. I think most folks would be fine with that, but it might need to be
spelled out for some that there is a balance that has to be maintained
until a proper transition can take place.

On Sat, Jun 20, 2020 at 6:23 PM Tony Kurc <tk...@apache.org> wrote:

> This discussion has died down quite a bit. I got the impression there was
> at least majority support, although not consensus, for Joe's two proposals
> [1].
>
> #1 ( s/master/main/ ) is probably the most straightforward - change
> developer docs and make the necessary repository changes. Can be done
> seemingly independent of software releases. Is it time for jiras on that?
> My sense is that 'main' appears to be a common term that projects appear to
> be gravitating to, but that discussion still abounds. This comment [2] on
> the git project's mailing list hurt my head quite a bit, but definitely
> reinforced that main makes a whole lot more sense than master, as Andy
> pointed out [3].
>
> #2 is a bit less straightforward, going to require a code change and figure
> out where that fits with the versioning scheme commitments [4]. Do we
> support both allow/block (or deny?) along with white/black in a minor
> release, and then prune white/black on next major release?
>
> 1.
>
> https://lists.apache.org/thread.html/r6c133a31f882d3c818e63fa44dbc451f61d423a22dbe72396483127b%40%3Cdev.nifi.apache.org%3E
>
> 2.
>
> https://lore.kernel.org/git/CANgJU+Ut+ANPHud1JQw1Wo+zb37_=EWx-vgap6FGC+T=-dzn4A@mail.gmail.com/
> 3.
>
> https://lists.apache.org/thread.html/r86a9a390f023a0298488084bdcb4caaa4bedfe406f1c86a1ca4bdac3%40%3Cdev.nifi.apache.org%3E
> 4.
>
> https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme+and+API+Compatibility
>
>
> On Thu, Jun 18, 2020 at 9:36 PM Otto Fowler <ot...@gmail.com>
> wrote:
>
> >  As long as it isn’t renamed to zeek or something, I think we should
> change
> > it and not look back.
> >
> >
> >
> > On June 18, 2020 at 19:05:38, Mike Thomsen (mikerthomsen@gmail.com)
> wrote:
> >
> > > As teammates and friends, it was an easy change, even if code was
> > involved. And I assume much easier than having the courage to ask for it.
> >
> > Ironically, around the same time I had a colleague who was like the evil
> > opposite of that. Friend is the last word any of us would use to describe
> > him. He was a cautionary tale in why teams have to also maintain defense
> > mechanisms against toxic people who exploit empathy as a power play;
> it's a
> > common tactic of abusers/toxic people to make demands on people to change
> > their behavior to see how compliant they are. That former colleague, if
> you
> > got them talking about their views, could wax eloquent about tolerance,
> > inclusiveness, etc. and then without a hint of irony turn around and
> wage a
> > one man war on everyone else.
> >
> > On Thu, Jun 18, 2020 at 11:53 AM Joey Frazee <joey.frazee@icloud.com
> > .invalid>
> >
> > wrote:
> >
> > > +1
> > >
> > > I’m repeating this from elsewhere but I was on a team 7 years ago
> where a
> > > teammate asked us to stop using master and slave terminology, even
> master
> > > alone, because it made them uncomfortable. I can’t estimate how common
> > that
> > > feeling is but this isn’t a theoretical exercise. As teammates and
> > friends,
> > > it was an easy change, even if code was involved. And I assume much
> > easier
> > > than having the courage to ask for it.
> > >
> > > I’d say it’s also important to note that “but that’s not the original
> > > intended word sense” doesn’t alleviate that alienating experience.
> While
> > > potentially a matter of fact of the intent for some uses, “I want to
> use
> > > that word” is pretty unfriendly stacked against “that makes me feel
> > > unwelcome”.
> > >
> > > Two guidelines from the code of conduct seem particularly apropos:
> > >
> > > - Be empathetic, welcoming, friendly, and patient
> > >
> > > - Be careful in the words that we choose
> > >
> > > AFAICT there’s not an escape hatch for code, tools, or effort.
> > >
> > > -joey
> > >
> > > On Jun 18, 2020, 10:05 AM -0500, Edward Armes <edward.armes@gmail.com
> >,
> > > wrote:
> > > > 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 Uwe@Moosheimer.com, <Uw...@moosheimer.com>
> > > 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 <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 <
> > alopresto@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
> > > > > > > > alopresto@apache.org
> > > > > > > > alopresto.apache@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.armes@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, <
> > > alopresto@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
> > > > > > > > > > alopresto@apache.org
> > > > > > > > > > alopresto.apache@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.witt@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 <
> > > tkurc@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
> > > > > > > > > >
> > > > > > > >
> > > > >
> > > > >
> > >
> >
>

Re: [DISCUSS] rename master branch, look through code for other related issues

[Tony Kurc <tk...@apache.org>]

This discussion has died down quite a bit. I got the impression there was
at least majority support, although not consensus, for Joe's two proposals
[1].

#1 ( s/master/main/ ) is probably the most straightforward - change
developer docs and make the necessary repository changes. Can be done
seemingly independent of software releases. Is it time for jiras on that?
My sense is that 'main' appears to be a common term that projects appear to
be gravitating to, but that discussion still abounds. This comment [2] on
the git project's mailing list hurt my head quite a bit, but definitely
reinforced that main makes a whole lot more sense than master, as Andy
pointed out [3].

#2 is a bit less straightforward, going to require a code change and figure
out where that fits with the versioning scheme commitments [4]. Do we
support both allow/block (or deny?) along with white/black in a minor
release, and then prune white/black on next major release?

1.
https://lists.apache.org/thread.html/r6c133a31f882d3c818e63fa44dbc451f61d423a22dbe72396483127b%40%3Cdev.nifi.apache.org%3E

2.
https://lore.kernel.org/git/CANgJU+Ut+ANPHud1JQw1Wo+zb37_=EWx-vgap6FGC+T=-dzn4A@mail.gmail.com/
3.
https://lists.apache.org/thread.html/r86a9a390f023a0298488084bdcb4caaa4bedfe406f1c86a1ca4bdac3%40%3Cdev.nifi.apache.org%3E
4.
https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme+and+API+Compatibility


On Thu, Jun 18, 2020 at 9:36 PM Otto Fowler <ot...@gmail.com> wrote:

>  As long as it isn’t renamed to zeek or something, I think we should change
> it and not look back.
>
>
>
> On June 18, 2020 at 19:05:38, Mike Thomsen (mikerthomsen@gmail.com) wrote:
>
> > As teammates and friends, it was an easy change, even if code was
> involved. And I assume much easier than having the courage to ask for it.
>
> Ironically, around the same time I had a colleague who was like the evil
> opposite of that. Friend is the last word any of us would use to describe
> him. He was a cautionary tale in why teams have to also maintain defense
> mechanisms against toxic people who exploit empathy as a power play; it's a
> common tactic of abusers/toxic people to make demands on people to change
> their behavior to see how compliant they are. That former colleague, if you
> got them talking about their views, could wax eloquent about tolerance,
> inclusiveness, etc. and then without a hint of irony turn around and wage a
> one man war on everyone else.
>
> On Thu, Jun 18, 2020 at 11:53 AM Joey Frazee <joey.frazee@icloud.com
> .invalid>
>
> wrote:
>
> > +1
> >
> > I’m repeating this from elsewhere but I was on a team 7 years ago where a
> > teammate asked us to stop using master and slave terminology, even master
> > alone, because it made them uncomfortable. I can’t estimate how common
> that
> > feeling is but this isn’t a theoretical exercise. As teammates and
> friends,
> > it was an easy change, even if code was involved. And I assume much
> easier
> > than having the courage to ask for it.
> >
> > I’d say it’s also important to note that “but that’s not the original
> > intended word sense” doesn’t alleviate that alienating experience. While
> > potentially a matter of fact of the intent for some uses, “I want to use
> > that word” is pretty unfriendly stacked against “that makes me feel
> > unwelcome”.
> >
> > Two guidelines from the code of conduct seem particularly apropos:
> >
> > - Be empathetic, welcoming, friendly, and patient
> >
> > - Be careful in the words that we choose
> >
> > AFAICT there’s not an escape hatch for code, tools, or effort.
> >
> > -joey
> >
> > On Jun 18, 2020, 10:05 AM -0500, Edward Armes <ed...@gmail.com>,
> > wrote:
> > > 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 Uwe@Moosheimer.com, <Uw...@moosheimer.com>
> > 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 <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 <
> alopresto@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
> > > > > > > alopresto@apache.org
> > > > > > > alopresto.apache@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.armes@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, <
> > alopresto@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
> > > > > > > > > alopresto@apache.org
> > > > > > > > > alopresto.apache@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.witt@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 <
> > tkurc@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
> > > > > > > > >
> > > > > > >
> > > >
> > > >
> >
>

Re: [DISCUSS] rename master branch, look through code for other related issues

[Otto Fowler <ot...@gmail.com>]

 As long as it isn’t renamed to zeek or something, I think we should change
it and not look back.



On June 18, 2020 at 19:05:38, Mike Thomsen (mikerthomsen@gmail.com) wrote:

> As teammates and friends, it was an easy change, even if code was
involved. And I assume much easier than having the courage to ask for it.

Ironically, around the same time I had a colleague who was like the evil
opposite of that. Friend is the last word any of us would use to describe
him. He was a cautionary tale in why teams have to also maintain defense
mechanisms against toxic people who exploit empathy as a power play; it's a
common tactic of abusers/toxic people to make demands on people to change
their behavior to see how compliant they are. That former colleague, if you
got them talking about their views, could wax eloquent about tolerance,
inclusiveness, etc. and then without a hint of irony turn around and wage a
one man war on everyone else.

On Thu, Jun 18, 2020 at 11:53 AM Joey Frazee <jo...@icloud.com.invalid>

wrote:

> +1
>
> I’m repeating this from elsewhere but I was on a team 7 years ago where a
> teammate asked us to stop using master and slave terminology, even master
> alone, because it made them uncomfortable. I can’t estimate how common
that
> feeling is but this isn’t a theoretical exercise. As teammates and
friends,
> it was an easy change, even if code was involved. And I assume much
easier
> than having the courage to ask for it.
>
> I’d say it’s also important to note that “but that’s not the original
> intended word sense” doesn’t alleviate that alienating experience. While
> potentially a matter of fact of the intent for some uses, “I want to use
> that word” is pretty unfriendly stacked against “that makes me feel
> unwelcome”.
>
> Two guidelines from the code of conduct seem particularly apropos:
>
> - Be empathetic, welcoming, friendly, and patient
>
> - Be careful in the words that we choose
>
> AFAICT there’s not an escape hatch for code, tools, or effort.
>
> -joey
>
> On Jun 18, 2020, 10:05 AM -0500, Edward Armes <ed...@gmail.com>,
> wrote:
> > 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 Uwe@Moosheimer.com, <Uw...@moosheimer.com>
> 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 <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 <alopresto@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
> > > > > > alopresto@apache.org
> > > > > > alopresto.apache@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.armes@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, <
> alopresto@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
> > > > > > > > alopresto@apache.org
> > > > > > > > alopresto.apache@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 <jo...@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 <
> tkurc@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
> > > > > > > >
> > > > > >
> > >
> > >
>

Re: [DISCUSS] rename master branch, look through code for other related issues

[Mike Thomsen <mi...@gmail.com>]

> As teammates and friends, it was an easy change, even if code was
involved. And I assume much easier than having the courage to ask for it.

Ironically, around the same time I had a colleague who was like the evil
opposite of that. Friend is the last word any of us would use to describe
him. He was a cautionary tale in why teams have to also maintain defense
mechanisms against toxic people who exploit empathy as a power play; it's a
common tactic of abusers/toxic people to make demands on people to change
their behavior to see how compliant they are. That former colleague, if you
got them talking about their views, could wax eloquent about tolerance,
inclusiveness, etc. and then without a hint of irony turn around and wage a
one man war on everyone else.

On Thu, Jun 18, 2020 at 11:53 AM Joey Frazee <jo...@icloud.com.invalid>
wrote:

> +1
>
> I’m repeating this from elsewhere but I was on a team 7 years ago where a
> teammate asked us to stop using master and slave terminology, even master
> alone, because it made them uncomfortable. I can’t estimate how common that
> feeling is but this isn’t a theoretical exercise. As teammates and friends,
> it was an easy change, even if code was involved. And I assume much easier
> than having the courage to ask for it.
>
> I’d say it’s also important to note that “but that’s not the original
> intended word sense” doesn’t alleviate that alienating experience. While
> potentially a matter of fact of the intent for some uses, “I want to use
> that word” is pretty unfriendly stacked against “that makes me feel
> unwelcome”.
>
> Two guidelines from the code of conduct seem particularly apropos:
>
> - Be empathetic, welcoming, friendly, and patient
>
> - Be careful in the words that we choose
>
> AFAICT there’s not an escape hatch for code, tools, or effort.
>
> -joey
>
> On Jun 18, 2020, 10:05 AM -0500, Edward Armes <ed...@gmail.com>,
> wrote:
> > 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 Uwe@Moosheimer.com, <Uw...@moosheimer.com>
> 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 <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 <alopresto@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
> > > > > > alopresto@apache.org
> > > > > > alopresto.apache@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.armes@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, <
> alopresto@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
> > > > > > > > alopresto@apache.org
> > > > > > > > alopresto.apache@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 <jo...@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 <
> tkurc@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
> > > > > > > >
> > > > > >
> > >
> > >
>

Re: [DISCUSS] rename master branch, look through code for other related issues

[Joey Frazee <jo...@icloud.com.INVALID>]

+1

I’m repeating this from elsewhere but I was on a team 7 years ago where a teammate asked us to stop using master and slave terminology, even master alone, because it made them uncomfortable. I can’t estimate how common that feeling is but this isn’t a theoretical exercise. As teammates and friends, it was an easy change, even if code was involved. And I assume much easier than having the courage to ask for it.

I’d say it’s also important to note that “but that’s not the original intended word sense” doesn’t alleviate that alienating experience. While potentially a matter of fact of the intent for some uses, “I want to use that word” is pretty unfriendly stacked against “that makes me feel unwelcome”.

Two guidelines from the code of conduct seem particularly apropos:

- Be empathetic, welcoming, friendly, and patient

- Be careful in the words that we choose

AFAICT there’s not an escape hatch for code, tools, or effort.

-joey

On Jun 18, 2020, 10:05 AM -0500, Edward Armes <ed...@gmail.com>, wrote:
> 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 Uwe@Moosheimer.com, <Uw...@moosheimer.com> 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 <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 <al...@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
> > > > > alopresto@apache.org
> > > > > alopresto.apache@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 <ed...@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, <al...@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
> > > > > > > alopresto@apache.org
> > > > > > > alopresto.apache@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 <jo...@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
> > > > > > >
> > > > >
> >
> >

Re: [DISCUSS] rename master branch, look through code for other related issues

[Edward Armes <ed...@gmail.com>]

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 Uwe@Moosheimer.com, <Uw...@moosheimer.com> 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 <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 <al...@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
> >>> alopresto@apache.org
> >>> alopresto.apache@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 <ed...@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, <al...@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
> >>>>> alopresto@apache.org
> >>>>> alopresto.apache@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 <jo...@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
> >>>>>
> >>>
>
>

Re: [DISCUSS] rename master branch, look through code for other related issues

["Uwe@Moosheimer.com" <Uw...@Moosheimer.com>]

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 <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 <al...@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
>>> alopresto@apache.org
>>> alopresto.apache@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 <ed...@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, <al...@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
>>>>> alopresto@apache.org
>>>>> alopresto.apache@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 <jo...@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
>>>>>
>>>

Re: [DISCUSS] rename master branch, look through code for other related issues

[Pierre Villard <pi...@gmail.com>]

> 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 <al...@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
> > alopresto@apache.org
> > alopresto.apache@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 <ed...@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, <al...@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
> > >> alopresto@apache.org
> > >> alopresto.apache@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 <jo...@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
> > >>>>
> > >>
> > >>
> >
> >
>

Re: [DISCUSS] rename master branch, look through code for other related issues

[Tony Kurc <tk...@apache.org>]

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 <al...@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
> alopresto@apache.org
> alopresto.apache@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 <ed...@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, <al...@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
> >> alopresto@apache.org
> >> alopresto.apache@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 <jo...@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
> >>>>
> >>
> >>
>
>

Re: [DISCUSS] rename master branch, look through code for other related issues

[Andy LoPresto <al...@apache.org>]

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
alopresto@apache.org
alopresto.apache@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 <ed...@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, <al...@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
>> alopresto@apache.org
>> alopresto.apache@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 <jo...@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
>>>> 
>> 
>> 

Re: [DISCUSS] rename master branch, look through code for other related issues

[Joe Witt <jo...@gmail.com>]

Edward

Im not aware of any changes we need to make which move from standard to non
standard.  And as far as I know it is pretty straightforward.   If we come
up with equally useful or slightly better terms and somehow make the
community more approachable for even a single person then I think it is a
win.

Sure for some projects this might be tougher but for NiFi this seems like
an easy effort.

thanks

On Wed, Jun 17, 2020 at 6:43 PM Edward Armes <ed...@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, <al...@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
> > alopresto@apache.org
> > alopresto.apache@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 <jo...@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
> > >>
> >
> >
>

Re: [DISCUSS] rename master branch, look through code for other related issues

[Edward Armes <ed...@gmail.com>]

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, <al...@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
> alopresto@apache.org
> alopresto.apache@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 <jo...@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
> >>
>
>

Re: [DISCUSS] rename master branch, look through code for other related issues

[Kevin Doran <kd...@gmail.com>]

+1 for making this change to NiFi and all NiFi sub-projects. Let me know how I can assist.

Kevin

> On Jun 17, 2020, at 9:23 PM, Aldrin Piri <al...@gmail.com> wrote:
> 
> +1 for making the changes.
> 
> On Wed, Jun 17, 2020 at 8:11 PM Andy LoPresto <al...@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
>> alopresto@apache.org
>> alopresto.apache@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 <jo...@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
>>>> 
>> 
>> 

Re: [DISCUSS] rename master branch, look through code for other related issues

[Aldrin Piri <al...@gmail.com>]

+1 for making the changes.

On Wed, Jun 17, 2020 at 8:11 PM Andy LoPresto <al...@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
> alopresto@apache.org
> alopresto.apache@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 <jo...@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
> >>
>
>

Re: [DISCUSS] rename master branch, look through code for other related issues

[Andy LoPresto <al...@apache.org>]

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
alopresto@apache.org
alopresto.apache@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 <jo...@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
>> 

Re: [DISCUSS] rename master branch, look through code for other related issues

[Joe Witt <jo...@gmail.com>]

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
>