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 <[email protected]> wrote:

> This is a difficult issue and causes no small amount of friction every
> time. I'm personally against this for the following reassons:
>
> - Some of the terms proposed are not industry standard and may potentially
> cause significant issue for non-english speakers.
>
> - For each change that is made can we guarantee that we will not lose
> clarity of meaning, and then have revert the change down the line if the
> change causes a drop in usage.
>
> - Of what percentage of people is this truly an issue for and what
> percentage isn't. Any change that has the potential to cause a major split
> in the community, there must be as close as possible to a majority, and not
> just from those that are vocal and active on the mailing lists.
> Disscustions on other groups are turning toxic, and in some cases are
> potentially leading to the collapse of these projects where these changes
> are being implemented with what appears to be without the agreement of a
> signifficant chunk of the community.
>
> - From a personal perspective, I sit on the autism spectrum and have grown
> up with people using words that are very offensive and have hurt me badly.
> Instead of having these words as offensive and untouchable. Myself and
> others have instead made these words our own and made them lose the
> negative connotations they have. As such, I do find the current
> disscustions deeply alarming and feels like they start to border into the
> realm of censorship.
>
> - One final point (and potentially controversial), A good chunk of the
> wording that is proposed to be changed. Is being done so on the
> "modern"/"street" definition of these words and not the actual definition.
> Language should change and evolve to introduce clarity, but right now does
> this change improve the clarity across the engineering sector and I believe
> it won't.
>
> Edward
>
>
> On Thu, 18 Jun 2020, 01:11 Andy LoPresto, <[email protected]> wrote:
>
> > I am a proponent of making this change and also using allow/deny list,
> > meddler-in-the-middle, etc.
> >
> > Here is a blog [1] with easy instructions for executing the change in
> git,
> > although I don’t know if there is any Apache-integration specific changes
> > we would also need.
> >
> > [1]
> >
> https://www.hanselman.com/blog/EasilyRenameYourGitDefaultBranchFromMasterToMain.aspx
> >
> > Andy LoPresto
> > [email protected]
> > [email protected]
> > He/Him
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >
> > > On Jun 17, 2020, at 3:06 PM, Joe Witt <[email protected]> wrote:
> > >
> > > I suspect it would be fairly easy to make this change.  We do, I think,
> > > have whitelist/blacklist in there somewhere but im not sure how
> involved.
> > >
> > > On Wed, Jun 17, 2020 at 3:04 PM Tony Kurc <[email protected]> wrote:
> > >
> > >> All,
> > >> I've seen the discussion started on other projects [1][2], so I wanted
> > to
> > >> kick off a discussion to determine whether this is something nifi
> could
> > >> look at too. Allen Wittenauer's post to yetus captures the why and
> some
> > of
> > >> the how, so rather than copy and pasting, you can take a look at what
> > he's
> > >> done. Thoughts?
> > >>
> > >> Tony
> > >>
> > >> 1.
> > >>
> > >>
> >
> https://lists.apache.org/thread.html/rd38afa9fb6c0dcd77d1a677f1152b7398b3bda93c9106b3393149d10%40%3Cdev.yetus.apache.org%3E
> > >> 2.
> > >>
> > >>
> >
> https://lists.apache.org/thread.html/r0825eec0c84296bdab7cf898a987f06355443241ca02b2aaa51d3ef9%40%3Cdev.accumulo.apache.org%3E
> > >>
> >
> >
>

Reply via email to