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