Re: More inclusive naming

[Paul King]

Hi Keegan,

Yes, just one class (plus associated tests and doco). It's not internal
exactly but you are right it is not ever seen by normal Groovy users. It's
only used by folks building DSLs which are subsets of the Groovy language.
To me the aliases are clearer in English, quite possibly much clearer for
non-native English speakers, as well as being more neutral.

PR here: https://github.com/apache/groovy/pull/1282

Cheers, Paul.


On Tue, Jun 16, 2020 at 12:14 PM Keegan Witt  wrote:

> I've been reticent on this because I'm more pragmatic than political.
> Please don't interpret this as belittling any particular position, I just
> prefer to view this issue primarily through the lens of a pragmatic
> technologist for this discussion (to the extent possible).  For discussions
> over beers; I'm always interested to hear people's reasons for
> their political and religious beliefs.
>
>1. It's *one* class we're discussing.  If this were a major overhaul,
>renaming things all over the place, I'd be quite reluctant.  But let's keep
>things in perspective.
>2. This is an internal class (correct me if I'm wrong, but that was my
>interpretation, given the package).  As such, its contract is not
>guaranteed, and therefore its naming conventions can be changed without
>overwhelming concern for compatibility.  Conversely, as an internal class,
>naming conventions aren't as critical, as very few people would likely need
>to interact with it.  Although clarity should always be the goal, even
>internally.
>3. Most importantly, names should communicate intent as clearly as
>possible, so the user can stop reading code/documentation and get on with
>getting things done.  In this case, both the old and proposed names seem
>equally understandable (to my eye anyway).  Usually, I'd consider this a
>reason to change nothing.
>
> However, Anne, you might be right about "blacklist" being a cultural
> term.  My first knowledge of it comes from learning American history, where
> "blacklist" referred to lists of people or materials seen as sympathetic to
> the communist cause (particularly associated with the anti-communist
> activities of Senator McCarthy).  As I understand the etymology, it was
> likely named "black" because black is the color of darkness (blackness and
> darkness being almost synonyms); in Abrahamic religious traditions, associated
> with evil (also a well understood cultural reference in America and
> probably most western countries, given historical influences).  Regardless
> of possible connotations, it is clear the word has its origins in some
> cultural-historical event(s), and so may not be clear to all readers.
>
>
> I despise non-functional code changes without good reason, but if the
> current naming convention is confusing to some (I can't speak to that,
> given my cultural background), then let's make it clearer.  If we can agree
> the proposed naming convention is *at least equally clear* (even if it
> doesn't roll off the tongue), then (particularly given the very limited
> scope of this change and the fact we're also going to use aliases) I think
> it makes sense to proceed.
>
> +1 from me
>
> On Mon, Jun 15, 2020 at 7:46 PM MG  wrote:
>
>> Hi Ann,
>>
>> good points in general.
>>
>> With regards to "blacklist" I think we can assume that the non native
>> speakers who actually did not know the term will be familiar with it by
>> now*, since there is a successful TV show that is literally called "The
>> Blacklist" (going into its 8th season), for which Wikipedia lists entries
>> in 34 languages: https://en.wikipedia.org/wiki/The_Blacklist_(TV_series)
>> :-)
>>
>> Keep groovying,
>> mg
>>
>>
>> On 15/06/2020 03:05, Anne wrote:
>>
>> Hi all
>>
>> I support (eventually) removing the terms 'blacklist' and 'whitelist',
>> though my primary reason is different to the reasons already stated, and I
>> thought it might be worth sharing why.
>>
>> It's generally recommended that names in programming be descriptive, and
>> that cultural references be avoided in favour of terms more likely to be
>> understood by non-native English speakers. Blacklist and whitelist go
>> against both recommendations.
>>
>> I've never liked the terms, because when I first encountered them (well
>> before Groovy existed) I found them very confusing. Why is the bad list
>> black and the good list white? To remember which is which, initially I had
>> to keep thinking of the saying "you can always tell the good guy in a
>> Western, he's wearing the white hat". And if the white was the good one,
>> then the black one must be the bad one. Yes, I had somehow missed out on
>> exposure to those terms as a child. I suspect that's a good thing.
>>
>> I never understood why anyone would use those terms in computing, instead
>> of more descriptive terms that also include what is being black/white
>> listed. For example, I'd prefer to see allowedHosts, allowedModules,
>> allowedIps, 

Re: More inclusive naming

[Keegan Witt]

I've been reticent on this because I'm more pragmatic than political.
Please don't interpret this as belittling any particular position, I just
prefer to view this issue primarily through the lens of a pragmatic
technologist for this discussion (to the extent possible).  For discussions
over beers; I'm always interested to hear people's reasons for
their political and religious beliefs.

   1. It's *one* class we're discussing.  If this were a major overhaul,
   renaming things all over the place, I'd be quite reluctant.  But let's keep
   things in perspective.
   2. This is an internal class (correct me if I'm wrong, but that was my
   interpretation, given the package).  As such, its contract is not
   guaranteed, and therefore its naming conventions can be changed without
   overwhelming concern for compatibility.  Conversely, as an internal class,
   naming conventions aren't as critical, as very few people would likely need
   to interact with it.  Although clarity should always be the goal, even
   internally.
   3. Most importantly, names should communicate intent as clearly as
   possible, so the user can stop reading code/documentation and get on with
   getting things done.  In this case, both the old and proposed names seem
   equally understandable (to my eye anyway).  Usually, I'd consider this a
   reason to change nothing.

However, Anne, you might be right about "blacklist" being a cultural term.
My first knowledge of it comes from learning American history, where
"blacklist" referred to lists of people or materials seen as sympathetic to
the communist cause (particularly associated with the anti-communist
activities of Senator McCarthy).  As I understand the etymology, it was
likely named "black" because black is the color of darkness (blackness and
darkness being almost synonyms); in Abrahamic religious traditions, associated
with evil (also a well understood cultural reference in America and
probably most western countries, given historical influences).  Regardless
of possible connotations, it is clear the word has its origins in some
cultural-historical event(s), and so may not be clear to all readers.


I despise non-functional code changes without good reason, but if the
current naming convention is confusing to some (I can't speak to that,
given my cultural background), then let's make it clearer.  If we can agree
the proposed naming convention is *at least equally clear* (even if it
doesn't roll off the tongue), then (particularly given the very limited
scope of this change and the fact we're also going to use aliases) I think
it makes sense to proceed.

+1 from me

On Mon, Jun 15, 2020 at 7:46 PM MG  wrote:

> Hi Ann,
>
> good points in general.
>
> With regards to "blacklist" I think we can assume that the non native
> speakers who actually did not know the term will be familiar with it by
> now*, since there is a successful TV show that is literally called "The
> Blacklist" (going into its 8th season), for which Wikipedia lists entries
> in 34 languages: https://en.wikipedia.org/wiki/The_Blacklist_(TV_series)
> :-)
>
> Keep groovying,
> mg
>
>
> On 15/06/2020 03:05, Anne wrote:
>
> Hi all
>
> I support (eventually) removing the terms 'blacklist' and 'whitelist',
> though my primary reason is different to the reasons already stated, and I
> thought it might be worth sharing why.
>
> It's generally recommended that names in programming be descriptive, and
> that cultural references be avoided in favour of terms more likely to be
> understood by non-native English speakers. Blacklist and whitelist go
> against both recommendations.
>
> I've never liked the terms, because when I first encountered them (well
> before Groovy existed) I found them very confusing. Why is the bad list
> black and the good list white? To remember which is which, initially I had
> to keep thinking of the saying "you can always tell the good guy in a
> Western, he's wearing the white hat". And if the white was the good one,
> then the black one must be the bad one. Yes, I had somehow missed out on
> exposure to those terms as a child. I suspect that's a good thing.
>
> I never understood why anyone would use those terms in computing, instead
> of more descriptive terms that also include what is being black/white
> listed. For example, I'd prefer to see allowedHosts, allowedModules,
> allowedIps, allowedTokens, allowedImports, ... which I find much easier to
> understand at a glance. If whitelist is used instead for all of these,
> surely most people's next thought is "what's being whitelisted?".
>
> Cheers,
> Anne.
>
>
>
> On Fri, 12 Jun 2020 at 09:52, Paul King  wrote:
>
>> As per my comments to Cos, I am inclined to remove the old names slowly.
>> I'll put together a PR where the new aliases become the prominent ones but
>> the old ones remain and are deprecated in 4.
>>
>> Cheers, Paul.
>>
>> On Fri, Jun 12, 2020 at 1:19 AM Andres Almiray 
>> wrote:
>>
>>> +1 Agreed,
>>>
>>> Aliases in 3.x (should we 

Re: More inclusive naming

[MG]

Hi Ann,

good points in general.

With regards to "blacklist" I think we can assume that the non native 
speakers who actually did not know the term will be familiar with it by 
now*, since there is a successful TV show that is literally called "The 
Blacklist" (going into its 8th season), for which Wikipedia lists 
entries in 34 languages: 
https://en.wikipedia.org/wiki/The_Blacklist_(TV_series) :-)


Keep groovying,
mg


On 15/06/2020 03:05, Anne wrote:

Hi all

I support (eventually) removing the terms 'blacklist' and 'whitelist', 
though my primary reason is different to the reasons already stated, 
and I thought it might be worth sharing why.


It's generally recommended that names in programming be descriptive, 
and that cultural references be avoided in favour of terms more likely 
to be understood by non-native English speakers. Blacklist and 
whitelist go against both recommendations.


I've never liked the terms, because when I first encountered them 
(well before Groovy existed) I found them very confusing. Why is the 
bad list black and the good list white? To remember which is which, 
initially I had to keep thinking of the saying "you can always tell 
the good guy in a Western, he's wearing the white hat". And if the 
white was the good one, then the black one must be the bad one. Yes, I 
had somehow missed out on exposure to those terms as a child. I 
suspect that's a good thing.


I never understood why anyone would use those terms in computing, 
instead of more descriptive terms that also include what is being 
black/white listed. For example, I'd prefer to see allowedHosts, 
allowedModules, allowedIps, allowedTokens, allowedImports, ... which I 
find much easier to understand at a glance. If whitelist is used 
instead for all of these, surely most people's next thought is "what's 
being whitelisted?".


Cheers,
Anne.



On Fri, 12 Jun 2020 at 09:52, Paul King > wrote:


As per my comments to Cos, I am inclined to remove the old names
slowly. I'll put together a PR where the new aliases become the
prominent ones but the old ones remain and are deprecated in 4.

Cheers, Paul.

On Fri, Jun 12, 2020 at 1:19 AM Andres Almiray mailto:aalmi...@gmail.com>> wrote:

+1 Agreed,

Aliases in 3.x (should we target 2.x if there's a 2.5.13?)
We know that Groovy 4.0 will break binary compatibility due to
removal of split packages. We can remove the old names in
Groovy 4.0.

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who
understand binary, and those who don't.
To understand recursion, we must first understand recursion.


On Thu, Jun 11, 2020 at 5:13 PM Guillaume Laforge
mailto:glafo...@gmail.com>> wrote:

+1, that's a great idea!


On Thu, Jun 11, 2020 at 5:08 PM Cédric Champeau
mailto:cedric.champ...@gmail.com>> wrote:

+1

Le jeu. 11 juin 2020 à 16:56, Jeff Beck
mailto:beckj...@gmail.com>> a écrit :

I find those aliases easier to understand. So I
think it's a great improvement.

Jeff

On Thu, Jun 11, 2020, 9:50 AM Paul King
mailto:pa...@asert.com.au>>
wrote:

Hi folks,

Given recent world events, there are numerous
projects that are taking the opportunity to
use more inclusive terminology especially in
names within APIs. E.g. getting rid of things
like master/slave, blacklist/whitelist, etc.
While I have never witnessed any racist
behavior in the Groovy community, it seems
worthwhile to be as inclusive as we can. I
scanned our codebase and it seems that the
only potential candidate we have for such a
change would be in SecureASTCustomizer. But
feel free to chime in if you think there are
others.

For backwards compatibility, I wouldn't
propose to remove the old names in the first
instance, just provide friendly aliases. We
can deprecate and/or remove the current names
later if we feel the need. Some example
aliases could be something like:

tokensWhitelist => allowedTokens

Re: More inclusive naming

[MG]

Hi Remko,

I consider Konstantin our esteemed guest, since afaiu Apache picking up 
Groovy was big, and I meant what I said to Jenn exactly the way I said 
it :-)


Cheers,
mg


On 15/06/2020 13:26, Remko Popma wrote:



On Mon, Jun 15, 2020 at 2:12 PM Konstantin Boudnik > wrote:


Precisely, MG!

This is what these discussions are swaying us into: to forget that we
are first and foremost came here to enjoy this great Groovy language
which many of us are using day in and day out (thanks for the team
that
has made this possible!).

We aren't just a bunch of marginalized groups of beef-eaters, vegans,
Taoists, cyclists or whatever - these taxonomies create false and
counterproductive separation.

We are all here because we are interested in Groovy! That what
matters -
nothing else. Please keep this bigger picture in mind before
sending out
another victimization email.


Cos,

I don't think MG was sending out any victimization emails.

Why are you flooding this list with these odd emails?

Remko


--
With regards,
   Cos

On 2020-06-14 23:51, MG wrote:
> On 14/06/2020 15:34, Jenn Strater wrote:
>> may make members of marginalized groups (like myself)
>
> To me you are another person that likes or is interested in
Groovy as a
> programming language
> You are welcome,
> mg

Re: More inclusive naming

[Mikko Värri]

Just to voice my +1 instead of being silent.  To me, "blacklist" associates 
"black" and "deny access" way too closely for 2020, and the suggested names are 
just better.

-mikko


> On 11. Jun 2020, at 17.50, Paul King  wrote:
> 
> Hi folks,
> 
> Given recent world events, there are numerous projects that are taking the 
> opportunity to use more inclusive terminology especially in names within 
> APIs. E.g. getting rid of things like master/slave, blacklist/whitelist, etc. 
> While I have never witnessed any racist behavior in the Groovy community, it 
> seems worthwhile to be as inclusive as we can. I scanned our codebase and it 
> seems that the only potential candidate we have for such a change would be in 
> SecureASTCustomizer. But feel free to chime in if you think there are others.
> 
> For backwards compatibility, I wouldn't propose to remove the old names in 
> the first instance, just provide friendly aliases. We can deprecate and/or 
> remove the current names later if we feel the need. Some example aliases 
> could be something like:
> 
> tokensWhitelist => allowedTokens
> staticStarImportsWhitelist => allowedStaticStarImports
> importsBlacklist => prohibitedImports (or disallowedImports)
> 
> Thoughts?
> 
> Cheers, Paul.
> 

Re: More inclusive naming

[Eric Kinsella]

+1  I also find the new aliases easier to understand and a welcome change.
We should strive for tolerance, inclusivity, and listening to others over
our own personal feelings.

- Eric

On Mon, Jun 15, 2020 at 7:09 AM Konstantin Boudnik  wrote:

> I don't think I was calling his email this way ;) but rather reaffirming
> his point of view.
>
> --
> With regards,
>Cos
>
> On 2020-06-15 18:26, Remko Popma wrote:
> >
> >
> > On Mon, Jun 15, 2020 at 2:12 PM Konstantin Boudnik  > > wrote:
> >
> > Precisely, MG!
> >
> > This is what these discussions are swaying us into: to forget that we
> > are first and foremost came here to enjoy this great Groovy language
> > which many of us are using day in and day out (thanks for the team
> that
> > has made this possible!).
> >
> > We aren't just a bunch of marginalized groups of beef-eaters, vegans,
> > Taoists, cyclists or whatever - these taxonomies create false and
> > counterproductive separation.
> >
> > We are all here because we are interested in Groovy! That what
> > matters -
> > nothing else. Please keep this bigger picture in mind before sending
> > out
> > another victimization email.
> >
> >
> > Cos,
> >
> > I don't think MG was sending out any victimization emails.
> >
> > Why are you flooding this list with these odd emails?
> >
> > Remko
> >
> >
> > --
> > With regards,
> > Cos
> >
> > On 2020-06-14 23:51, MG wrote:
> >  > On 14/06/2020 15:34, Jenn Strater wrote:
> >  >> may make members of marginalized groups (like myself)
> >  >
> >  > To me you are another person that likes or is interested in
> > Groovy as a
> >  > programming language
> >  > You are welcome,
> >  > mg
> >
>

Re: More inclusive naming

[Konstantin Boudnik]

I don't think I was calling his email this way ;) but rather reaffirming 
his point of view.


--
With regards,
  Cos

On 2020-06-15 18:26, Remko Popma wrote:



On Mon, Jun 15, 2020 at 2:12 PM Konstantin Boudnik > wrote:


Precisely, MG!

This is what these discussions are swaying us into: to forget that we
are first and foremost came here to enjoy this great Groovy language
which many of us are using day in and day out (thanks for the team that
has made this possible!).

We aren't just a bunch of marginalized groups of beef-eaters, vegans,
Taoists, cyclists or whatever - these taxonomies create false and
counterproductive separation.

We are all here because we are interested in Groovy! That what
matters -
nothing else. Please keep this bigger picture in mind before sending
out
another victimization email.


Cos,

I don't think MG was sending out any victimization emails.

Why are you flooding this list with these odd emails?

Remko


--
With regards,
    Cos

On 2020-06-14 23:51, MG wrote:
 > On 14/06/2020 15:34, Jenn Strater wrote:
 >> may make members of marginalized groups (like myself)
 >
 > To me you are another person that likes or is interested in
Groovy as a
 > programming language
 > You are welcome,
 > mg

Re: More inclusive naming

[Remko Popma]

On Mon, Jun 15, 2020 at 2:12 PM Konstantin Boudnik  wrote:

> Precisely, MG!
>
> This is what these discussions are swaying us into: to forget that we
> are first and foremost came here to enjoy this great Groovy language
> which many of us are using day in and day out (thanks for the team that
> has made this possible!).
>
> We aren't just a bunch of marginalized groups of beef-eaters, vegans,
> Taoists, cyclists or whatever - these taxonomies create false and
> counterproductive separation.
>
> We are all here because we are interested in Groovy! That what matters -
> nothing else. Please keep this bigger picture in mind before sending out
> another victimization email.
>

Cos,

I don't think MG was sending out any victimization emails.

Why are you flooding this list with these odd emails?

Remko



>
> --
> With regards,
>Cos
>
> On 2020-06-14 23:51, MG wrote:
> > On 14/06/2020 15:34, Jenn Strater wrote:
> >> may make members of marginalized groups (like myself)
> >
> > To me you are another person that likes or is interested in Groovy as a
> > programming language
> > You are welcome,
> > mg
>

Re: More inclusive naming

[Jochen Theodorou]

On 15.06.20 03:05, Anne wrote:

Hi all

I support (eventually) removing the terms 'blacklist' and 'whitelist',
though my primary reason is different to the reasons already stated, and
I thought it might be worth sharing why.

It's generally recommended that names in programming be descriptive, and
that cultural references be avoided in favour of terms more likely to be
understood by non-native English speakers. Blacklist and whitelist go
against both recommendations.


Is there a list of these words somewhere? I tried to google that, but
frankly I do not even know what keywords to use here.


I've never liked the terms, because when I first encountered them (well
before Groovy existed) I found them very confusing. Why is the bad list
black and the good list white? To remember which is which, initially I
had to keep thinking of the saying "you can always tell the good guy in
a Western, he's wearing the white hat". And if the white was the good
one, then the black one must be the bad one. Yes, I had somehow missed
out on exposure to those terms as a child. I suspect that's a good thing.


On the origin of the word: https://www.etymonline.com/word/blacklist


I never understood why anyone would use those terms in computing,
instead of more descriptive terms that also include what is being
black/white listed. For example, I'd prefer to see allowedHosts,
allowedModules, allowedIps, allowedTokens, allowedImports, ... which I
find much easier to understand at a glance. If whitelist is used instead
for all of these, surely most people's next thought is "what's being
whitelisted?".


because very often you work, or at least start, with what to forbid. And
a word combination like forbiddenHosts feels strange from a language
perspective, though I am not a native speaker of any english, thus my
opinion is just an opinion.

bye Jochen

Re: More inclusive naming

[Konstantin Boudnik]

Precisely, MG!

This is what these discussions are swaying us into: to forget that we 
are first and foremost came here to enjoy this great Groovy language 
which many of us are using day in and day out (thanks for the team that 
has made this possible!).


We aren't just a bunch of marginalized groups of beef-eaters, vegans, 
Taoists, cyclists or whatever - these taxonomies create false and 
counterproductive separation.


We are all here because we are interested in Groovy! That what matters - 
nothing else. Please keep this bigger picture in mind before sending out 
another victimization email.


--
With regards,
  Cos

On 2020-06-14 23:51, MG wrote:

On 14/06/2020 15:34, Jenn Strater wrote:

may make members of marginalized groups (like myself)


To me you are another person that likes or is interested in Groovy as a 
programming language

You are welcome,
mg

Re: More inclusive naming

[Anne]

Hi all

I support (eventually) removing the terms 'blacklist' and 'whitelist',
though my primary reason is different to the reasons already stated, and I
thought it might be worth sharing why.

It's generally recommended that names in programming be descriptive, and
that cultural references be avoided in favour of terms more likely to be
understood by non-native English speakers. Blacklist and whitelist go
against both recommendations.

I've never liked the terms, because when I first encountered them (well
before Groovy existed) I found them very confusing. Why is the bad list
black and the good list white? To remember which is which, initially I had
to keep thinking of the saying "you can always tell the good guy in a
Western, he's wearing the white hat". And if the white was the good one,
then the black one must be the bad one. Yes, I had somehow missed out on
exposure to those terms as a child. I suspect that's a good thing.

I never understood why anyone would use those terms in computing, instead
of more descriptive terms that also include what is being black/white
listed. For example, I'd prefer to see allowedHosts, allowedModules,
allowedIps, allowedTokens, allowedImports, ... which I find much easier to
understand at a glance. If whitelist is used instead for all of these,
surely most people's next thought is "what's being whitelisted?".

Cheers,
Anne.



On Fri, 12 Jun 2020 at 09:52, Paul King  wrote:

> As per my comments to Cos, I am inclined to remove the old names slowly.
> I'll put together a PR where the new aliases become the prominent ones but
> the old ones remain and are deprecated in 4.
>
> Cheers, Paul.
>
> On Fri, Jun 12, 2020 at 1:19 AM Andres Almiray  wrote:
>
>> +1 Agreed,
>>
>> Aliases in 3.x (should we target 2.x if there's a 2.5.13?)
>> We know that Groovy 4.0 will break binary compatibility due to removal of
>> split packages. We can remove the old names in Groovy 4.0.
>>
>> Cheers,
>> Andres
>>
>> ---
>> Java Champion; Groovy Enthusiast
>> http://andresalmiray.com
>> http://www.linkedin.com/in/aalmiray
>> --
>> What goes up, must come down. Ask any system administrator.
>> There are 10 types of people in the world: Those who understand binary,
>> and those who don't.
>> To understand recursion, we must first understand recursion.
>>
>>
>> On Thu, Jun 11, 2020 at 5:13 PM Guillaume Laforge 
>> wrote:
>>
>>> +1, that's a great idea!
>>>
>>>
>>> On Thu, Jun 11, 2020 at 5:08 PM Cédric Champeau <
>>> cedric.champ...@gmail.com> wrote:
>>>
 +1

 Le jeu. 11 juin 2020 à 16:56, Jeff Beck  a écrit :

> I find those aliases easier to understand. So I think it's a great
> improvement.
>
> Jeff
>
> On Thu, Jun 11, 2020, 9:50 AM Paul King  wrote:
>
>> Hi folks,
>>
>> Given recent world events, there are numerous projects that are
>> taking the opportunity to use more inclusive terminology especially in
>> names within APIs. E.g. getting rid of things like master/slave,
>> blacklist/whitelist, etc. While I have never witnessed any racist 
>> behavior
>> in the Groovy community, it seems worthwhile to be as inclusive as we 
>> can.
>> I scanned our codebase and it seems that the only potential candidate we
>> have for such a change would be in SecureASTCustomizer. But feel free to
>> chime in if you think there are others.
>>
>> For backwards compatibility, I wouldn't propose to remove the old
>> names in the first instance, just provide friendly aliases. We can
>> deprecate and/or remove the current names later if we feel the need. Some
>> example aliases could be something like:
>>
>> tokensWhitelist => allowedTokens
>> staticStarImportsWhitelist => allowedStaticStarImports
>> importsBlacklist => prohibitedImports (or disallowedImports)
>>
>> Thoughts?
>>
>> Cheers, Paul.
>>
>>
>>>
>>> --
>>> Guillaume Laforge
>>> Apache Groovy committer
>>> Developer Advocate @ Google Cloud Platform
>>>
>>> Blog: http://glaforge.appspot.com/
>>> Twitter: @glaforge 
>>>
>>

-- 
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: (03) 9585 6788
Fax: (03) 9585 1086
Web: https://www.coherentsoftware.com.au/
Email: i...@coherentsoftware.com.au

Re: More inclusive naming

[MG]

On 14/06/2020 15:34, Jenn Strater wrote:

may make members of marginalized groups (like myself)


To me you are another person that likes or is interested in Groovy as a 
programming language

You are welcome,
mg

Re: More inclusive naming

[Konstantin Boudnik]

Appreciate the effort Jenn! We all live in the world which is constantly 
being inconsiderate to someone's feelings and comfort zones. And - from 
a strictly mathematical standpoint - finding a common subset of terms 
that won't be offensive for an arbitrary reason to an unknown someone 
will leave us with a very small and poor semantic space. That's how 
common denominators work.


And this is exactly why people discriminate. In fact, we discriminate 
all the time, every choice we make is an act of discrimination: from 
color of the shirt, to preferences of our soul mates, to the way we are 
going to depart this world (as some might not be as carbon neurtal as 
others).


This morning I chose a burger with bacon for my branch. Perhaps I have 
offended a few people in that restaurant with different dietary choices, 
but they went their ways and I went mine. And may be another three 
hundred vegans will faint from just reading this. I don't know for sure. 
But I would make the same choice again even if knew. Because my choice 
is a voluntary act and doesn't coerse anyone into doing the same thing. 
Exactly as I don't mind people drinking Pepsi although I know that HFCS 
gives one diabetes. I am not complaining that people make their choices 
which might offend me in some way, unless they actually cause harm to my 
being.


This is why the world we inhabit worth living in: we all different and 
it is great! Let's just accept it.


--
With regards,
  Cos

On 2020-06-14 20:34, Jenn Strater wrote:
I was trying to be polite. I meant that seeing some of the 
offensive things that have been said in this conversation, in 
particular, may make members of marginalized groups(like myself) feel 
less comfortable bringing up issues of inclusivity. Just because no one 
has felt comfortable enough to report being pushed out, doesn't mean it 
hasn't happened. The community is much larger than just the people here. 
Many people watch these lists without engaging and many don't subscribe 
at all.


We should also probably end this conversation. We've deviated quite a 
bit from the original proposal for one instance of more inclusive naming.


Jenn

On Sun, Jun 14, 2020 at 7:06 AM Remko Popma <mailto:remko.po...@gmail.com>> wrote:


Cos,

Thank you for the clarification. I have a slightly different
worldview, but that is okay. :-)
We may not be as perfect as we think we are. Our goal is to make our
community more inclusive.
Jenn, being one of the rare female engineers we have in our larger
IT community, may have some interesting insights.

So let's not get all defensive about some words that could be taken
many ways.

I consider you a guest in this community, just like Jenn. If she is
an occasional passerby, then so are you. :-)
Guests are welcome, and I would like everyone in our community, as
well as our guests, to be nice to each other, so that more guests
stay and become part of our community.

Remko.

On Sun, Jun 14, 2020 at 4:12 PM Konstantin Boudnik mailto:c...@apache.org>> wrote:

Thanks for kind words Remko. But I am not trying to blame myself
for anything.

I am perfectly aware about my limits as in 'you can lead a horse
to the water,
but can't force it to drink'. In fact, I know for sure that ASF
in general
hasn't ever pushed anyone out, not even for brain-dead coding ;)
Most of the
problems you're mentioning don't stand critical multi-factor
analysis
that includes personal interests, education preferences, and so on.

Just to give you an example: would you consider problematic that
I am never
wanted to become a nurse or a botanist? Would you encourage me
to go for it?
Why? And why would I pay any attention whatsoever for
encouragement of this
sort?

I know this community never had aforementioned issues. And this
is exactly why
I asked for an example, because for an occasional passerby with
heightened
demand for social justice the expression

     "problems our community faces with inclusivity"

being left without an answer would be indicative of some deep
rooted practices
of rejecting people for whatever reasons.

Perhaps, you'll find of interest [1] where community development
is being
discussed regularly.

[1]
https://lists.apache.org/list.html?d...@community.apache.org:lte=3M:

With best regards,
   Cos

On Sun, Jun 14, 2020 at 03:20PM, Remko Popma wrote:
 > Thank you for chiming in, Cos.
 >
 > I actually read Jenn's comment to mean the IT community in
general, not
 > this project.
 > In general I am a big fan of blaming myself first to try and
learn, rather
 > t

Re: More inclusive naming

[Jenn Strater]

I was trying to be polite. I meant that seeing some of the offensive things
that have been said in this conversation, in particular, may make members
of marginalized groups(like myself) feel less comfortable bringing up
issues of inclusivity. Just because no one has felt comfortable enough to
report being pushed out, doesn't mean it hasn't happened. The community is
much larger than just the people here. Many people watch these lists
without engaging and many don't subscribe at all.

We should also probably end this conversation. We've deviated quite a bit
from the original proposal for one instance of more inclusive naming.

Jenn

On Sun, Jun 14, 2020 at 7:06 AM Remko Popma  wrote:

> Cos,
>
> Thank you for the clarification. I have a slightly different worldview,
> but that is okay. :-)
>
> We may not be as perfect as we think we are. Our goal is to make our
> community more inclusive.
> Jenn, being one of the rare female engineers we have in our larger IT
> community, may have some interesting insights.
>
> So let's not get all defensive about some words that could be taken many
> ways.
>
> I consider you a guest in this community, just like Jenn. If she is an
> occasional passerby, then so are you. :-)
> Guests are welcome, and I would like everyone in our community, as well as
> our guests, to be nice to each other, so that more guests stay and become
> part of our community.
>
> Remko.
>
> On Sun, Jun 14, 2020 at 4:12 PM Konstantin Boudnik  wrote:
>
>> Thanks for kind words Remko. But I am not trying to blame myself for
>> anything.
>>
>> I am perfectly aware about my limits as in 'you can lead a horse to the
>> water,
>> but can't force it to drink'. In fact, I know for sure that ASF in general
>> hasn't ever pushed anyone out, not even for brain-dead coding ;) Most of
>> the
>> problems you're mentioning don't stand critical multi-factor analysis
>> that includes personal interests, education preferences, and so on.
>>
>> Just to give you an example: would you consider problematic that I am
>> never
>> wanted to become a nurse or a botanist? Would you encourage me to go for
>> it?
>> Why? And why would I pay any attention whatsoever for encouragement of
>> this
>> sort?
>>
>> I know this community never had aforementioned issues. And this is
>> exactly why
>> I asked for an example, because for an occasional passerby with heightened
>> demand for social justice the expression
>>
>> "problems our community faces with inclusivity"
>>
>> being left without an answer would be indicative of some deep rooted
>> practices
>> of rejecting people for whatever reasons.
>>
>> Perhaps, you'll find of interest [1] where community development is being
>> discussed regularly.
>>
>> [1] https://lists.apache.org/list.html?d...@community.apache.org:lte=3M:
>>
>> With best regards,
>>   Cos
>>
>> On Sun, Jun 14, 2020 at 03:20PM, Remko Popma wrote:
>> > Thank you for chiming in, Cos.
>> >
>> > I actually read Jenn's comment to mean the IT community in general, not
>> > this project.
>> > In general I am a big fan of blaming myself first to try and learn,
>> rather
>> > than seeking to blame outside factors, but I would not recommend that
>> you
>> > try to take personal responsibility for the very low percentage of for
>> > example female engineers, female managers, or people of color in IT in
>> > general.
>> > We can only try to be aware of the biases that we inevitably have, and
>> make
>> > our projects and interactions as welcoming as possible.
>> > I joined this project fairly recently, so I wasn't there when you were
>> > mentoring, but I am sure you did a great job.
>> >
>> > Remko
>> >
>> >
>> > On Sun, Jun 14, 2020 at 1:13 PM Konstantin Boudnik 
>> wrote:
>> >
>> > > Thank you for chiming in, Jenn.
>> > >
>> > > As you mention "problems our community faces with inclusivity" - would
>> > > you mind mention a case of such a problem in the past? I was one of
>> the
>> > > mentors of this project (as in was a part of it from its early days in
>> > > ASF), so I guess I am missing something in this regard. And it would
>> > > help me to do my job better next time as a mentor of new projects.
>> > >
>> > > Feel free to send me a private note if you feel uncomfortable to share
>> > > this on dev@
>> > >
>> > > --
>> > > Thank you,
>> >

Re: More inclusive naming

[Remko Popma]

Cos,

Thank you for the clarification. I have a slightly different worldview, but
that is okay. :-)

We may not be as perfect as we think we are. Our goal is to make our
community more inclusive.
Jenn, being one of the rare female engineers we have in our larger IT
community, may have some interesting insights.

So let's not get all defensive about some words that could be taken many
ways.

I consider you a guest in this community, just like Jenn. If she is an
occasional passerby, then so are you. :-)
Guests are welcome, and I would like everyone in our community, as well as
our guests, to be nice to each other, so that more guests stay and become
part of our community.

Remko.

On Sun, Jun 14, 2020 at 4:12 PM Konstantin Boudnik  wrote:

> Thanks for kind words Remko. But I am not trying to blame myself for
> anything.
>
> I am perfectly aware about my limits as in 'you can lead a horse to the
> water,
> but can't force it to drink'. In fact, I know for sure that ASF in general
> hasn't ever pushed anyone out, not even for brain-dead coding ;) Most of
> the
> problems you're mentioning don't stand critical multi-factor analysis
> that includes personal interests, education preferences, and so on.
>
> Just to give you an example: would you consider problematic that I am never
> wanted to become a nurse or a botanist? Would you encourage me to go for
> it?
> Why? And why would I pay any attention whatsoever for encouragement of this
> sort?
>
> I know this community never had aforementioned issues. And this is exactly
> why
> I asked for an example, because for an occasional passerby with heightened
> demand for social justice the expression
>
> "problems our community faces with inclusivity"
>
> being left without an answer would be indicative of some deep rooted
> practices
> of rejecting people for whatever reasons.
>
> Perhaps, you'll find of interest [1] where community development is being
> discussed regularly.
>
> [1] https://lists.apache.org/list.html?d...@community.apache.org:lte=3M:
>
> With best regards,
>   Cos
>
> On Sun, Jun 14, 2020 at 03:20PM, Remko Popma wrote:
> > Thank you for chiming in, Cos.
> >
> > I actually read Jenn's comment to mean the IT community in general, not
> > this project.
> > In general I am a big fan of blaming myself first to try and learn,
> rather
> > than seeking to blame outside factors, but I would not recommend that you
> > try to take personal responsibility for the very low percentage of for
> > example female engineers, female managers, or people of color in IT in
> > general.
> > We can only try to be aware of the biases that we inevitably have, and
> make
> > our projects and interactions as welcoming as possible.
> > I joined this project fairly recently, so I wasn't there when you were
> > mentoring, but I am sure you did a great job.
> >
> > Remko
> >
> >
> > On Sun, Jun 14, 2020 at 1:13 PM Konstantin Boudnik 
> wrote:
> >
> > > Thank you for chiming in, Jenn.
> > >
> > > As you mention "problems our community faces with inclusivity" - would
> > > you mind mention a case of such a problem in the past? I was one of the
> > > mentors of this project (as in was a part of it from its early days in
> > > ASF), so I guess I am missing something in this regard. And it would
> > > help me to do my job better next time as a mentor of new projects.
> > >
> > > Feel free to send me a private note if you feel uncomfortable to share
> > > this on dev@
> > >
> > > --
> > > Thank you,
> > >Cos
> > >
> > > On 2020-06-13 23:23, Jenn Strater wrote:
> > > > Hi everyone,
> > > >
> > > > I find this thread especially the responses very educational in
> regards
> > > > to the problems our community faces with inclusivity. I know my vote
> > > > doesn't count, but +1 from me.
> > > >
> > > > Jenn
> > > >
> > > > On Sat, Jun 13, 2020 at 9:59 AM Thibault Kruse <
> tibokr...@googlemail.com
> > > > > wrote:
> > > >
> > > > On Sat, Jun 13, 2020, 19:18 Alessio Stalla <
> alessiosta...@gmail.com
> > > > > wrote:
> > > >
> > > > Well, perhaps it ought to be "black" people who get to say
> > > > whether they feel offended by white/blacklist, and in that E.
> > > > Kemokai's answer is very valuable.
> > > >
> > > >
> > > > Some expressions are non-inclusive even if no person were to feel
> > > > offended by them. The typical case against "blacklist" can be
> found
> > > > e.g here:
> > > >
> > >
> https://chromium.googlesource.com/chromium/src/+/master/styleguide/inclusive_code.md
> > > >
> > > > "Terms such as “blacklist” and “whitelist” reinforce the notion
> that
> > > > black==bad and white==good. 'That Word /Black'/, by Langston
> Hughes
> > > > <
> > >
> https://mcwriting11.blogspot.com/2014/06/that-word-black-by-langston-hughes.html
> > > > illustrates
> > > > this problem in a lighthearted, if somewhat pointed way."
> > > >
> > > > This has 

Re: More inclusive naming

[Konstantin Boudnik]

Thanks for kind words Remko. But I am not trying to blame myself for anything.

I am perfectly aware about my limits as in 'you can lead a horse to the water,
but can't force it to drink'. In fact, I know for sure that ASF in general
hasn't ever pushed anyone out, not even for brain-dead coding ;) Most of the
problems you're mentioning don't stand critical multi-factor analysis
that includes personal interests, education preferences, and so on.

Just to give you an example: would you consider problematic that I am never
wanted to become a nurse or a botanist? Would you encourage me to go for it?
Why? And why would I pay any attention whatsoever for encouragement of this
sort?

I know this community never had aforementioned issues. And this is exactly why
I asked for an example, because for an occasional passerby with heightened
demand for social justice the expression 

"problems our community faces with inclusivity"

being left without an answer would be indicative of some deep rooted practices
of rejecting people for whatever reasons.

Perhaps, you'll find of interest [1] where community development is being
discussed regularly.

[1] https://lists.apache.org/list.html?d...@community.apache.org:lte=3M:

With best regards,
  Cos

On Sun, Jun 14, 2020 at 03:20PM, Remko Popma wrote:
> Thank you for chiming in, Cos.
> 
> I actually read Jenn's comment to mean the IT community in general, not
> this project.
> In general I am a big fan of blaming myself first to try and learn, rather
> than seeking to blame outside factors, but I would not recommend that you
> try to take personal responsibility for the very low percentage of for
> example female engineers, female managers, or people of color in IT in
> general.
> We can only try to be aware of the biases that we inevitably have, and make
> our projects and interactions as welcoming as possible.
> I joined this project fairly recently, so I wasn't there when you were
> mentoring, but I am sure you did a great job.
> 
> Remko
> 
> 
> On Sun, Jun 14, 2020 at 1:13 PM Konstantin Boudnik  wrote:
> 
> > Thank you for chiming in, Jenn.
> >
> > As you mention "problems our community faces with inclusivity" - would
> > you mind mention a case of such a problem in the past? I was one of the
> > mentors of this project (as in was a part of it from its early days in
> > ASF), so I guess I am missing something in this regard. And it would
> > help me to do my job better next time as a mentor of new projects.
> >
> > Feel free to send me a private note if you feel uncomfortable to share
> > this on dev@
> >
> > --
> > Thank you,
> >Cos
> >
> > On 2020-06-13 23:23, Jenn Strater wrote:
> > > Hi everyone,
> > >
> > > I find this thread especially the responses very educational in regards
> > > to the problems our community faces with inclusivity. I know my vote
> > > doesn't count, but +1 from me.
> > >
> > > Jenn
> > >
> > > On Sat, Jun 13, 2020 at 9:59 AM Thibault Kruse  > > > wrote:
> > >
> > > On Sat, Jun 13, 2020, 19:18 Alessio Stalla  > > > wrote:
> > >
> > > Well, perhaps it ought to be "black" people who get to say
> > > whether they feel offended by white/blacklist, and in that E.
> > > Kemokai's answer is very valuable.
> > >
> > >
> > > Some expressions are non-inclusive even if no person were to feel
> > > offended by them. The typical case against "blacklist" can be found
> > > e.g here:
> > >
> > https://chromium.googlesource.com/chromium/src/+/master/styleguide/inclusive_code.md
> > >
> > > "Terms such as “blacklist” and “whitelist” reinforce the notion that
> > > black==bad and white==good. 'That Word /Black'/, by Langston Hughes
> > > <
> > https://mcwriting11.blogspot.com/2014/06/that-word-black-by-langston-hughes.html
> > > illustrates
> > > this problem in a lighthearted, if somewhat pointed way."
> > >
> > > This has been discussed so often online right now, it does not seem
> > > useful to discuss it again starting at zero without reference to an
> > > existing discussion.
> > >
> >



signature.asc
Description: PGP signature

Re: More inclusive naming

[Remko Popma]

Thank you for chiming in, Cos.

I actually read Jenn's comment to mean the IT community in general, not
this project.
In general I am a big fan of blaming myself first to try and learn, rather
than seeking to blame outside factors, but I would not recommend that you
try to take personal responsibility for the very low percentage of for
example female engineers, female managers, or people of color in IT in
general.
We can only try to be aware of the biases that we inevitably have, and make
our projects and interactions as welcoming as possible.
I joined this project fairly recently, so I wasn't there when you were
mentoring, but I am sure you did a great job.

Remko


On Sun, Jun 14, 2020 at 1:13 PM Konstantin Boudnik  wrote:

> Thank you for chiming in, Jenn.
>
> As you mention "problems our community faces with inclusivity" - would
> you mind mention a case of such a problem in the past? I was one of the
> mentors of this project (as in was a part of it from its early days in
> ASF), so I guess I am missing something in this regard. And it would
> help me to do my job better next time as a mentor of new projects.
>
> Feel free to send me a private note if you feel uncomfortable to share
> this on dev@
>
> --
> Thank you,
>Cos
>
> On 2020-06-13 23:23, Jenn Strater wrote:
> > Hi everyone,
> >
> > I find this thread especially the responses very educational in regards
> > to the problems our community faces with inclusivity. I know my vote
> > doesn't count, but +1 from me.
> >
> > Jenn
> >
> > On Sat, Jun 13, 2020 at 9:59 AM Thibault Kruse  > > wrote:
> >
> > On Sat, Jun 13, 2020, 19:18 Alessio Stalla  > > wrote:
> >
> > Well, perhaps it ought to be "black" people who get to say
> > whether they feel offended by white/blacklist, and in that E.
> > Kemokai's answer is very valuable.
> >
> >
> > Some expressions are non-inclusive even if no person were to feel
> > offended by them. The typical case against "blacklist" can be found
> > e.g here:
> >
> https://chromium.googlesource.com/chromium/src/+/master/styleguide/inclusive_code.md
> >
> > "Terms such as “blacklist” and “whitelist” reinforce the notion that
> > black==bad and white==good. 'That Word /Black'/, by Langston Hughes
> > <
> https://mcwriting11.blogspot.com/2014/06/that-word-black-by-langston-hughes.html
> > illustrates
> > this problem in a lighthearted, if somewhat pointed way."
> >
> > This has been discussed so often online right now, it does not seem
> > useful to discuss it again starting at zero without reference to an
> > existing discussion.
> >
>

Re: More inclusive naming

[Konstantin Boudnik]

Thank you for chiming in, Jenn.

As you mention "problems our community faces with inclusivity" - would 
you mind mention a case of such a problem in the past? I was one of the 
mentors of this project (as in was a part of it from its early days in 
ASF), so I guess I am missing something in this regard. And it would 
help me to do my job better next time as a mentor of new projects.


Feel free to send me a private note if you feel uncomfortable to share 
this on dev@


--
Thank you,
  Cos

On 2020-06-13 23:23, Jenn Strater wrote:

Hi everyone,

I find this thread especially the responses very educational in regards 
to the problems our community faces with inclusivity. I know my vote 
doesn't count, but +1 from me.


Jenn

On Sat, Jun 13, 2020 at 9:59 AM Thibault Kruse > wrote:


On Sat, Jun 13, 2020, 19:18 Alessio Stalla mailto:alessiosta...@gmail.com>> wrote:

Well, perhaps it ought to be "black" people who get to say
whether they feel offended by white/blacklist, and in that E.
Kemokai's answer is very valuable.


Some expressions are non-inclusive even if no person were to feel
offended by them. The typical case against "blacklist" can be found
e.g here:

https://chromium.googlesource.com/chromium/src/+/master/styleguide/inclusive_code.md

"Terms such as “blacklist” and “whitelist” reinforce the notion that
black==bad and white==good. 'That Word /Black'/, by Langston Hughes


 illustrates
this problem in a lighthearted, if somewhat pointed way."

This has been discussed so often online right now, it does not seem
useful to discuss it again starting at zero without reference to an
existing discussion.

Re: More inclusive naming

[Jenn Strater]

Hi everyone,

I find this thread especially the responses very educational in regards to
the problems our community faces with inclusivity. I know my vote doesn't
count, but +1 from me.

Jenn

On Sat, Jun 13, 2020 at 9:59 AM Thibault Kruse 
wrote:

> On Sat, Jun 13, 2020, 19:18 Alessio Stalla 
> wrote:
>
>> Well, perhaps it ought to be "black" people who get to say whether they
>> feel offended by white/blacklist, and in that E. Kemokai's answer is very
>> valuable.
>>
>
> Some expressions are non-inclusive even if no person were to feel offended
> by them. The typical case against "blacklist" can be found e.g here:
> https://chromium.googlesource.com/chromium/src/+/master/styleguide/inclusive_code.md
>
> "Terms such as “blacklist” and “whitelist” reinforce the notion that
> black==bad and white==good. 'That Word *Black'*, by Langston Hughes
> 
>  illustrates
> this problem in a lighthearted, if somewhat pointed way."
>
> This has been discussed so often online right now, it does not seem useful
> to discuss it again starting at zero without reference to an existing
> discussion.
>
>>

Re: More inclusive naming

[Thibault Kruse]

On Sat, Jun 13, 2020, 19:18 Alessio Stalla  wrote:

> Well, perhaps it ought to be "black" people who get to say whether they
> feel offended by white/blacklist, and in that E. Kemokai's answer is very
> valuable.
>

Some expressions are non-inclusive even if no person were to feel offended
by them. The typical case against "blacklist" can be found e.g here:
https://chromium.googlesource.com/chromium/src/+/master/styleguide/inclusive_code.md

"Terms such as “blacklist” and “whitelist” reinforce the notion that
black==bad and white==good. 'That Word *Black'*, by Langston Hughes

illustrates
this problem in a lighthearted, if somewhat pointed way."

This has been discussed so often online right now, it does not seem useful
to discuss it again starting at zero without reference to an existing
discussion.

>

Re: More inclusive naming

[OCsite]

Ladies — if any in this sad debate — and gentlemen,

> Well, perhaps it ought to be "black" people who get to say whether they feel 
> offended by white/blacklist

Indeed. Myself, I invariably find thoughts of Walter E. Williams highly worth 
studying. Amongst others, he also wrote

“The true test of one’s commitment to free speech comes when others are 
permitted to say and publish ideas they deem offensive 
.”

All the best,
OC

> On 13 Jun 2020, at 12:18, Alessio Stalla  wrote:
> 
> Well, perhaps it ought to be "black" people who get to say whether they feel 
> offended by white/blacklist, and in that E. Kemokai's answer is very valuable.
> If we're doing this because someone is being hurt by some offending language, 
> then +1.
> If we're doing this to "be on the right side", then -1 for me as this doesn't 
> solve anyone's problem but our own fear of "being on the wrong side", and we 
> can be much more effective as a community if we actually do something 
> concrete against racism and other inequalities (off the top of my head: give 
> a spotlight to minority Groovy developers on official channels, create 
> sponsorship programs, etc.).
> 
> On Sat, 13 Jun 2020 at 08:41, Balachandran Sivakumar 
> mailto:balachand...@balachandran.org>> wrote:
> Hi,
> 
> On 2020-06-13 07:45, MG wrote:
> > Believe me, I do so understand that - but as an atheist by choice from
> > a young age, I do not want to live in a deeply irrational world, where
> > everything you say can be considered racist or insensitive, even if
> > that makes no sense whatsoever, just because somebody believes it to
> > be that way.
> 
>   The problem we are trying to solve is "If something could be 
> offensive to even a small subset of people, let's try and avoid that as 
> much as possible".
> 
> And being "sensitive" is about how a person "feels". Rationalism deals 
> with "thought" and cannot be used with feelings :) So, this initiative 
> is a good one by all of us in an attempt to ensure that even the most 
> sensitive person feels "welcome" and included.
> 
> > The base of any free and just society for me needs to be reason and
> > concensus, not any part dictating their perceived truth to the other.
> 
>   This is a very true statement that we all should keep in mind in 
> any community effort. And here, like always, Paul did ask for 
> comments/thought :) And I am in favour of the aliases and gradual 
> deprecation of names that could be deemed offensive.
> 
> 
> --
> Thank you,
> Balachandran Sivakumar

Re: More inclusive naming

[Konstantin Boudnik]

Well said!

> If we're doing this to "be on the right side"

Or "there are some groups projecting their own inner guilt and trying to 
convince the rest of us they are on a moral high ground aka right side".


But because of their record of implementing poly-logism and moral 
relativism arguments it is impossible to define which side is right and 
which of is wrong.


--
With regards,
  Cos

Re: More inclusive naming

[Alessio Stalla]

Well, perhaps it ought to be "black" people who get to say whether they
feel offended by white/blacklist, and in that E. Kemokai's answer is very
valuable.
If we're doing this because someone is being hurt by some offending
language, then +1.
If we're doing this to "be on the right side", then -1 for me as this
doesn't solve anyone's problem but our own fear of "being on the wrong
side", and we can be much more effective as a community if we actually do
something concrete against racism and other inequalities (off the top of my
head: give a spotlight to minority Groovy developers on official channels,
create sponsorship programs, etc.).

On Sat, 13 Jun 2020 at 08:41, Balachandran Sivakumar <
balachand...@balachandran.org> wrote:

> Hi,
>
> On 2020-06-13 07:45, MG wrote:
> > Believe me, I do so understand that - but as an atheist by choice from
> > a young age, I do not want to live in a deeply irrational world, where
> > everything you say can be considered racist or insensitive, even if
> > that makes no sense whatsoever, just because somebody believes it to
> > be that way.
>
>   The problem we are trying to solve is "If something could be
> offensive to even a small subset of people, let's try and avoid that as
> much as possible".
>
> And being "sensitive" is about how a person "feels". Rationalism deals
> with "thought" and cannot be used with feelings :) So, this initiative
> is a good one by all of us in an attempt to ensure that even the most
> sensitive person feels "welcome" and included.
>
> > The base of any free and just society for me needs to be reason and
> > concensus, not any part dictating their perceived truth to the other.
>
>   This is a very true statement that we all should keep in mind in
> any community effort. And here, like always, Paul did ask for
> comments/thought :) And I am in favour of the aliases and gradual
> deprecation of names that could be deemed offensive.
>
>
> --
> Thank you,
> Balachandran Sivakumar
>

Re: More inclusive naming

[Balachandran Sivakumar]

Hi,

On 2020-06-13 07:45, MG wrote:

Believe me, I do so understand that - but as an atheist by choice from
a young age, I do not want to live in a deeply irrational world, where
everything you say can be considered racist or insensitive, even if
that makes no sense whatsoever, just because somebody believes it to
be that way.


 The problem we are trying to solve is "If something could be 
offensive to even a small subset of people, let's try and avoid that as 
much as possible".


And being "sensitive" is about how a person "feels". Rationalism deals 
with "thought" and cannot be used with feelings :) So, this initiative 
is a good one by all of us in an attempt to ensure that even the most 
sensitive person feels "welcome" and included.



The base of any free and just society for me needs to be reason and
concensus, not any part dictating their perceived truth to the other.


 This is a very true statement that we all should keep in mind in 
any community effort. And here, like always, Paul did ask for 
comments/thought :) And I am in favour of the aliases and gradual 
deprecation of names that could be deemed offensive.



--
Thank you,
Balachandran Sivakumar

Re: More inclusive naming

[MG]

Believe me, I do so understand that - but as an atheist by choice from a 
young age, I do not want to live in a deeply irrational world, where 
everything you say can be considered racist or insensitive, even if that 
makes no sense whatsoever, just because somebody believes it to be that way.
The base of any free and just society for me needs to be reason and 
concensus, not any part dictating their perceived truth to the other. To 
deviate from that leads down a slippery slope and into a new dark age, 
however enlightened/progessive the people propagating it unerringly 
believe themselves to be.

Cheers,
mg

On 12/06/2020 21:25, Jochen Theodorou wrote:

On 12.06.20 19:25, MG wrote:

Well said.

I would add to that, that in IT "blacklist" is a purely technical term,
with the "black" having imho no association to people.


Logic has nothing to do with this. There are trends in the public views
and language you have to follow, unless you want to stand out the wrong
way. You can see that with our logo, you can see that with the name of
the language. Its just that the stronger the trends are the more the
negative impact. And these things have a lot of momentum these days.

[..]

and if it actually "will result in a better and more just world
somehow".


it may not, but logic and believe exclude each other, and this is the
area of believe.

bye Jochen

Re: More inclusive naming

[Edmond Kemokai]

+1

Lurker on the Groovy forum and developer of this thing (
https://codesolvent.com/) which makes use of Groovy. I also happen to be
"black".

I am not personally offended by the use of these labels since I know the
initiation of their use was probably not motivated by malice, I do however
understand how they
could be deemed at the very least insensitive.

I think injecting sensitivity into how language is used is always helpful,
especially in our modern world where there is just a lot more opportunity
to be inadvertently offensive.



On Fri, Jun 12, 2020 at 3:25 PM Jochen Theodorou  wrote:

> On 12.06.20 19:25, MG wrote:
> > Well said.
> >
> > I would add to that, that in IT "blacklist" is a purely technical term,
> > with the "black" having imho no association to people.
>
> Logic has nothing to do with this. There are trends in the public views
> and language you have to follow, unless you want to stand out the wrong
> way. You can see that with our logo, you can see that with the name of
> the language. Its just that the stronger the trends are the more the
> negative impact. And these things have a lot of momentum these days.
>
> [..]
> > and if it actually "will result in a better and more just world
> > somehow".
>
> it may not, but logic and believe exclude each other, and this is the
> area of believe.
>
> bye Jochen
>

Re: More inclusive naming

[MG]

Well said.

I would add to that, that in IT "blacklist" is a purely technical term, 
with the "black" having imho no association to people. Even if etymology 
can be problematic in such questions, I also could not find any 
indication in the etymology of the word* that it has anything to do with 
the much newer, special meaning of the word "black" for a subgroup of 
the group of persons which have a higher amount of pigment in their skin 
(since their ancestors lived closer to the equator and it protected them 
against the damaging effects of sun rays, contrary to other people whose 
ancestors had moved farther north, which meant that higher amounts of 
pigment in their skin became an evolutionary disadvantage).


Apart from that many other areas exist where the color black is 
associated with negativity, like (from the top of my hat) warning signs 
of radiation/chemicals/etc being colored yellow-black, being afraid of 
the dark, depression and songs about depression/loss like "Paint it 
Black" by the Rolling Stones,  Star Wars, Lord of the Rings, death in 
many parts of the world, etc, etc.


In general negative associations with the term black - black is of 
course e.g. also the color of cool, sleek elegance - seem utterly 
impossible to remove, independent of whether one sees it as a good idea 
or not. So I am very doubtful how much good such a move in Groovy would 
do, and if it actually "will result in a better and more just world 
somehow".


Here are two links on people who evidently disagree with me:
https://jmla.pitt.edu/ojs/jmla/article/view/490 (here a connection is 
postulated between the first known use of the word "blacklist" and the 
beginning of the slave trade, but no evidence besides temporal coherence 
is given)

https://www.zdnet.com/article/uk-ncsc-to-stop-using-whitelist-and-blacklist-due-to-racial-stereotyping/

In closing, if one wants to change the situation of poor people in the 
US, many of which are "black", my suggestion would be to introduce a 
public school & university system which gives you a free & good 
education (like it exists in many European countries), give people 
access to universal health care (respectively do not dismantle the 
efforts already made in this direction, derogatively dubbed "Obamacare" 
by the right), try to keep people of all shades from starting to take 
drugs, etc - and in general reduce the huge difference between the rich 
and the poor. And, yes, of course, try to keep people who are clearly 
unfit for being in a profession that is supposed to protect all people 
out of the police force & prosecute them if they have commited a crime :-)


Cheers,
mg

*https://en.wikipedia.org/wiki/Blacklisting
https://www.etymonline.com/word/blacklist
https://www.macmillandictionaryblog.com/blacklist
https://en.wiktionary.org/wiki/blacklist



On 12/06/2020 05:05, Konstantin Boudnik wrote:
Thank you, Paul, appreciate the details! Aliases seem like a 
reasonable way to go. Let's keep them both for a while and see how the 
new stuff getting traction.


After all, forcing someone to use 'blacklist' or 'disallowed' seem to 
be arbitrary and equally sub-optimal. The keyword in this case is 
'forcing': in Apache we always strive to reach consensus (not through 
the voting) and consensus doesn't mean we all have to wear the same 
jackets or sunglasses as far as we keep on doing what we do best - 
developing the software.


Here's my +0 to that effect.
--
With best regards,
  Cos

On 2020-06-12 06:50, Paul King wrote:
I agree we should minimise breaking existing code. I suspect 
deprecating in 4 but leaving around might be the best compromise. The 
goal of the change is that anyone who doesn't want to see/use the old 
aliases shouldn't have to. And we should make the new names the 
prominent ones in the documentation. My understanding is that in some 
cultures/languages "black" represents a sign of strength and perhaps 
allowed/prohibited might not be considered neutral somewhere else. 
So, it is difficult to be totally neutral, this proposal does seem to 
provide terms that many would find more neutral, so having that 
option seems like a good thing from my point of view.


Cheers, Paul.

On Fri, Jun 12, 2020 at 1:15 AM Konstantin Boudnik > wrote:


    Hey fellas!

    Wearing my hat of a software developer, using Groovy quite 
extensively

    for the last decade, I'd like to understand the ramifications of the
    initiative:
   - at some point I would have to go back and comb through my 
code and
    change/recompile everything that would be affected by the 
proposed APIs

    changes, right?
   - no gain in performance, no improvements in the semantic
    expressions
    - just find/replace and recompile for the sake of it?

    But hopefully it will result in a better and more just world
    somehow. Am
    I summing this up correctly?

    --
    Thanks,
    Cos

    On 2020-06-11 21:50, Paul King wrote:
 > Hi folks,

Re: More inclusive naming

[Konstantin Boudnik]

Thank you, Paul, appreciate the details! Aliases seem like a reasonable 
way to go. Let's keep them both for a while and see how the new stuff 
getting traction.


After all, forcing someone to use 'blacklist' or 'disallowed' seem to be 
arbitrary and equally sub-optimal. The keyword in this case is 
'forcing': in Apache we always strive to reach consensus (not through 
the voting) and consensus doesn't mean we all have to wear the same 
jackets or sunglasses as far as we keep on doing what we do best - 
developing the software.


Here's my +0 to that effect.
--
With best regards,
  Cos

On 2020-06-12 06:50, Paul King wrote:
I agree we should minimise breaking existing code. I suspect deprecating 
in 4 but leaving around might be the best compromise. The goal of the 
change is that anyone who doesn't want to see/use the old aliases 
shouldn't have to. And we should make the new names the prominent ones 
in the documentation. My understanding is that in some 
cultures/languages "black" represents a sign of strength and perhaps 
allowed/prohibited might not be considered neutral somewhere else. So, 
it is difficult to be totally neutral, this proposal does seem to 
provide terms that many would find more neutral, so having that option 
seems like a good thing from my point of view.


Cheers, Paul.

On Fri, Jun 12, 2020 at 1:15 AM Konstantin Boudnik > wrote:


Hey fellas!

Wearing my hat of a software developer, using Groovy quite extensively
for the last decade, I'd like to understand the ramifications of the
initiative:
   - at some point I would have to go back and comb through my code and
change/recompile everything that would be affected by the proposed APIs
changes, right?
   - no gain in performance, no improvements in the semantic
expressions
- just find/replace and recompile for the sake of it?

But hopefully it will result in a better and more just world
somehow. Am
I summing this up correctly?

--
Thanks,
    Cos

On 2020-06-11 21:50, Paul King wrote:
 > Hi folks,
 >
 > Given recent world events, there are numerous projects that are
taking
 > the opportunity to use more inclusive terminology especially in
names
 > within APIs. E.g. getting rid of things like master/slave,
 > blacklist/whitelist, etc. While I have never witnessed any racist
 > behavior in the Groovy community, it seems worthwhile to be as
inclusive
 > as we can. I scanned our codebase and it seems that the only
potential
 > candidate we have for such a change would be
in SecureASTCustomizer. But
 > feel free to chime in if you think there are others.
 >
 > For backwards compatibility, I wouldn't propose to remove the old
names
 > in the first instance, just provide friendly aliases. We can
deprecate
 > and/or remove the current names later if we feel the need. Some
example
 > aliases could be something like:
 >
 > tokensWhitelist => allowedTokens
 > staticStarImportsWhitelist => allowedStaticStarImports
 > importsBlacklist => prohibitedImports (or disallowedImports)
 >
 > Thoughts?
 >
 > Cheers, Paul.
 >
a

Re: More inclusive naming

[Paul King]

As per my comments to Cos, I am inclined to remove the old names slowly.
I'll put together a PR where the new aliases become the prominent ones but
the old ones remain and are deprecated in 4.

Cheers, Paul.

On Fri, Jun 12, 2020 at 1:19 AM Andres Almiray  wrote:

> +1 Agreed,
>
> Aliases in 3.x (should we target 2.x if there's a 2.5.13?)
> We know that Groovy 4.0 will break binary compatibility due to removal of
> split packages. We can remove the old names in Groovy 4.0.
>
> Cheers,
> Andres
>
> ---
> Java Champion; Groovy Enthusiast
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary,
> and those who don't.
> To understand recursion, we must first understand recursion.
>
>
> On Thu, Jun 11, 2020 at 5:13 PM Guillaume Laforge 
> wrote:
>
>> +1, that's a great idea!
>>
>>
>> On Thu, Jun 11, 2020 at 5:08 PM Cédric Champeau <
>> cedric.champ...@gmail.com> wrote:
>>
>>> +1
>>>
>>> Le jeu. 11 juin 2020 à 16:56, Jeff Beck  a écrit :
>>>
 I find those aliases easier to understand. So I think it's a great
 improvement.

 Jeff

 On Thu, Jun 11, 2020, 9:50 AM Paul King  wrote:

> Hi folks,
>
> Given recent world events, there are numerous projects that are taking
> the opportunity to use more inclusive terminology especially in names
> within APIs. E.g. getting rid of things like master/slave,
> blacklist/whitelist, etc. While I have never witnessed any racist behavior
> in the Groovy community, it seems worthwhile to be as inclusive as we can.
> I scanned our codebase and it seems that the only potential candidate we
> have for such a change would be in SecureASTCustomizer. But feel free to
> chime in if you think there are others.
>
> For backwards compatibility, I wouldn't propose to remove the old
> names in the first instance, just provide friendly aliases. We can
> deprecate and/or remove the current names later if we feel the need. Some
> example aliases could be something like:
>
> tokensWhitelist => allowedTokens
> staticStarImportsWhitelist => allowedStaticStarImports
> importsBlacklist => prohibitedImports (or disallowedImports)
>
> Thoughts?
>
> Cheers, Paul.
>
>
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer
>> Developer Advocate @ Google Cloud Platform
>>
>> Blog: http://glaforge.appspot.com/
>> Twitter: @glaforge 
>>
>

Re: More inclusive naming

[Paul King]

I agree we should minimise breaking existing code. I suspect deprecating in
4 but leaving around might be the best compromise.  The goal of the change
is that anyone who doesn't want to see/use the old aliases shouldn't have
to. And we should make the new names the prominent ones in the
documentation. My understanding is that in some cultures/languages "black"
represents a sign of strength and perhaps allowed/prohibited might not be
considered neutral somewhere else. So, it is difficult to be totally
neutral, this proposal does seem to provide terms that many would find more
neutral, so having that option seems like a good thing from my point of
view.

Cheers, Paul.

On Fri, Jun 12, 2020 at 1:15 AM Konstantin Boudnik  wrote:

> Hey fellas!
>
> Wearing my hat of a software developer, using Groovy quite extensively
> for the last decade, I'd like to understand the ramifications of the
> initiative:
>   - at some point I would have to go back and comb through my code and
> change/recompile everything that would be affected by the proposed APIs
> changes, right?
>   - no gain in performance, no improvements in the semantic expressions
> - just find/replace and recompile for the sake of it?
>
> But hopefully it will result in a better and more just world somehow. Am
> I summing this up correctly?
>
> --
> Thanks,
>Cos
>
> On 2020-06-11 21:50, Paul King wrote:
> > Hi folks,
> >
> > Given recent world events, there are numerous projects that are taking
> > the opportunity to use more inclusive terminology especially in names
> > within APIs. E.g. getting rid of things like master/slave,
> > blacklist/whitelist, etc. While I have never witnessed any racist
> > behavior in the Groovy community, it seems worthwhile to be as inclusive
> > as we can. I scanned our codebase and it seems that the only potential
> > candidate we have for such a change would be in SecureASTCustomizer. But
> > feel free to chime in if you think there are others.
> >
> > For backwards compatibility, I wouldn't propose to remove the old names
> > in the first instance, just provide friendly aliases. We can deprecate
> > and/or remove the current names later if we feel the need. Some example
> > aliases could be something like:
> >
> > tokensWhitelist => allowedTokens
> > staticStarImportsWhitelist => allowedStaticStarImports
> > importsBlacklist => prohibitedImports (or disallowedImports)
> >
> > Thoughts?
> >
> > Cheers, Paul.
> >
> a
>

Re: More inclusive naming

[Remko Popma]

+1

"In the end, we will remember not the words of our enemies, but the silence
of our friends."
-- Martin Luther King

Remko.


On Fri, Jun 12, 2020 at 2:17 AM Adam L. Davis  wrote:

> +1
>
> On Thu, Jun 11, 2020 at 12:12 PM Søren Berg Glasius 
> wrote:
> >
> > +1
> >
> > Best regards / Med venlig hilsen,
> > Søren Berg Glasius
> >
> > Hedevej 1, Gl. Rye, 8680 Ry, Denmark
> > Mobile: +45 40 44 91 88, Skype: sbglasius
> > --- Press ESC once to quit - twice to save the changes.
> >
> >
> > Den tor. 11. jun. 2020 kl. 16.50 skrev Paul King :
> >>
> >> Hi folks,
> >>
> >> Given recent world events, there are numerous projects that are taking
> the opportunity to use more inclusive terminology especially in names
> within APIs. E.g. getting rid of things like master/slave,
> blacklist/whitelist, etc. While I have never witnessed any racist behavior
> in the Groovy community, it seems worthwhile to be as inclusive as we can.
> I scanned our codebase and it seems that the only potential candidate we
> have for such a change would be in SecureASTCustomizer. But feel free to
> chime in if you think there are others.
> >>
> >> For backwards compatibility, I wouldn't propose to remove the old names
> in the first instance, just provide friendly aliases. We can deprecate
> and/or remove the current names later if we feel the need. Some example
> aliases could be something like:
> >>
> >> tokensWhitelist => allowedTokens
> >> staticStarImportsWhitelist => allowedStaticStarImports
> >> importsBlacklist => prohibitedImports (or disallowedImports)
> >>
> >> Thoughts?
> >>
> >> Cheers, Paul.
> >>
>
>
> --
> Adam Davis
> Web: github.adamldavis.com
>

Re: More inclusive naming

[Adam L. Davis]

+1

On Thu, Jun 11, 2020 at 12:12 PM Søren Berg Glasius  wrote:
>
> +1
>
> Best regards / Med venlig hilsen,
> Søren Berg Glasius
>
> Hedevej 1, Gl. Rye, 8680 Ry, Denmark
> Mobile: +45 40 44 91 88, Skype: sbglasius
> --- Press ESC once to quit - twice to save the changes.
>
>
> Den tor. 11. jun. 2020 kl. 16.50 skrev Paul King :
>>
>> Hi folks,
>>
>> Given recent world events, there are numerous projects that are taking the 
>> opportunity to use more inclusive terminology especially in names within 
>> APIs. E.g. getting rid of things like master/slave, blacklist/whitelist, 
>> etc. While I have never witnessed any racist behavior in the Groovy 
>> community, it seems worthwhile to be as inclusive as we can. I scanned our 
>> codebase and it seems that the only potential candidate we have for such a 
>> change would be in SecureASTCustomizer. But feel free to chime in if you 
>> think there are others.
>>
>> For backwards compatibility, I wouldn't propose to remove the old names in 
>> the first instance, just provide friendly aliases. We can deprecate and/or 
>> remove the current names later if we feel the need. Some example aliases 
>> could be something like:
>>
>> tokensWhitelist => allowedTokens
>> staticStarImportsWhitelist => allowedStaticStarImports
>> importsBlacklist => prohibitedImports (or disallowedImports)
>>
>> Thoughts?
>>
>> Cheers, Paul.
>>


-- 
Adam Davis
Web: github.adamldavis.com

Re: More inclusive naming

[Søren Berg Glasius]

+1

Best regards / Med venlig hilsen,
Søren Berg Glasius

Hedevej 1, Gl. Rye, 8680 Ry, Denmark
Mobile: +45 40 44 91 88, Skype: sbglasius
--- Press ESC once to quit - twice to save the changes.


Den tor. 11. jun. 2020 kl. 16.50 skrev Paul King :

> Hi folks,
>
> Given recent world events, there are numerous projects that are taking the
> opportunity to use more inclusive terminology especially in names within
> APIs. E.g. getting rid of things like master/slave, blacklist/whitelist,
> etc. While I have never witnessed any racist behavior in the Groovy
> community, it seems worthwhile to be as inclusive as we can. I scanned our
> codebase and it seems that the only potential candidate we have for such a
> change would be in SecureASTCustomizer. But feel free to chime in if you
> think there are others.
>
> For backwards compatibility, I wouldn't propose to remove the old names in
> the first instance, just provide friendly aliases. We can deprecate and/or
> remove the current names later if we feel the need. Some example aliases
> could be something like:
>
> tokensWhitelist => allowedTokens
> staticStarImportsWhitelist => allowedStaticStarImports
> importsBlacklist => prohibitedImports (or disallowedImports)
>
> Thoughts?
>
> Cheers, Paul.
>
>

Re: More inclusive naming

[Jeff MAURY]

+1

Le jeu. 11 juin 2020 à 17:19, Andres Almiray  a écrit :

> +1 Agreed,
>
> Aliases in 3.x (should we target 2.x if there's a 2.5.13?)
> We know that Groovy 4.0 will break binary compatibility due to removal of
> split packages. We can remove the old names in Groovy 4.0.
>
> Cheers,
> Andres
>
> ---
> Java Champion; Groovy Enthusiast
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary,
> and those who don't.
> To understand recursion, we must first understand recursion.
>
>
> On Thu, Jun 11, 2020 at 5:13 PM Guillaume Laforge 
> wrote:
>
>> +1, that's a great idea!
>>
>>
>> On Thu, Jun 11, 2020 at 5:08 PM Cédric Champeau <
>> cedric.champ...@gmail.com> wrote:
>>
>>> +1
>>>
>>> Le jeu. 11 juin 2020 à 16:56, Jeff Beck  a écrit :
>>>
 I find those aliases easier to understand. So I think it's a great
 improvement.

 Jeff

 On Thu, Jun 11, 2020, 9:50 AM Paul King  wrote:

> Hi folks,
>
> Given recent world events, there are numerous projects that are taking
> the opportunity to use more inclusive terminology especially in names
> within APIs. E.g. getting rid of things like master/slave,
> blacklist/whitelist, etc. While I have never witnessed any racist behavior
> in the Groovy community, it seems worthwhile to be as inclusive as we can.
> I scanned our codebase and it seems that the only potential candidate we
> have for such a change would be in SecureASTCustomizer. But feel free to
> chime in if you think there are others.
>
> For backwards compatibility, I wouldn't propose to remove the old
> names in the first instance, just provide friendly aliases. We can
> deprecate and/or remove the current names later if we feel the need. Some
> example aliases could be something like:
>
> tokensWhitelist => allowedTokens
> staticStarImportsWhitelist => allowedStaticStarImports
> importsBlacklist => prohibitedImports (or disallowedImports)
>
> Thoughts?
>
> Cheers, Paul.
>
>
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer
>> Developer Advocate @ Google Cloud Platform
>>
>> Blog: http://glaforge.appspot.com/
>> Twitter: @glaforge 
>>
>

Re: More inclusive naming

[Andres Almiray]

+1 Agreed,

Aliases in 3.x (should we target 2.x if there's a 2.5.13?)
We know that Groovy 4.0 will break binary compatibility due to removal of
split packages. We can remove the old names in Groovy 4.0.

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Thu, Jun 11, 2020 at 5:13 PM Guillaume Laforge 
wrote:

> +1, that's a great idea!
>
>
> On Thu, Jun 11, 2020 at 5:08 PM Cédric Champeau 
> wrote:
>
>> +1
>>
>> Le jeu. 11 juin 2020 à 16:56, Jeff Beck  a écrit :
>>
>>> I find those aliases easier to understand. So I think it's a great
>>> improvement.
>>>
>>> Jeff
>>>
>>> On Thu, Jun 11, 2020, 9:50 AM Paul King  wrote:
>>>
 Hi folks,

 Given recent world events, there are numerous projects that are taking
 the opportunity to use more inclusive terminology especially in names
 within APIs. E.g. getting rid of things like master/slave,
 blacklist/whitelist, etc. While I have never witnessed any racist behavior
 in the Groovy community, it seems worthwhile to be as inclusive as we can.
 I scanned our codebase and it seems that the only potential candidate we
 have for such a change would be in SecureASTCustomizer. But feel free to
 chime in if you think there are others.

 For backwards compatibility, I wouldn't propose to remove the old names
 in the first instance, just provide friendly aliases. We can deprecate
 and/or remove the current names later if we feel the need. Some example
 aliases could be something like:

 tokensWhitelist => allowedTokens
 staticStarImportsWhitelist => allowedStaticStarImports
 importsBlacklist => prohibitedImports (or disallowedImports)

 Thoughts?

 Cheers, Paul.


>
> --
> Guillaume Laforge
> Apache Groovy committer
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Twitter: @glaforge 
>

Re: More inclusive naming

[Konstantin Boudnik]

Hey fellas!

Wearing my hat of a software developer, using Groovy quite extensively 
for the last decade, I'd like to understand the ramifications of the 
initiative:
 - at some point I would have to go back and comb through my code and 
change/recompile everything that would be affected by the proposed APIs 
changes, right?
 - no gain in performance, no improvements in the semantic expressions 
- just find/replace and recompile for the sake of it?


But hopefully it will result in a better and more just world somehow. Am 
I summing this up correctly?


--
Thanks,
  Cos

On 2020-06-11 21:50, Paul King wrote:

Hi folks,

Given recent world events, there are numerous projects that are taking 
the opportunity to use more inclusive terminology especially in names 
within APIs. E.g. getting rid of things like master/slave, 
blacklist/whitelist, etc. While I have never witnessed any racist 
behavior in the Groovy community, it seems worthwhile to be as inclusive 
as we can. I scanned our codebase and it seems that the only potential 
candidate we have for such a change would be in SecureASTCustomizer. But 
feel free to chime in if you think there are others.


For backwards compatibility, I wouldn't propose to remove the old names 
in the first instance, just provide friendly aliases. We can deprecate 
and/or remove the current names later if we feel the need. Some example 
aliases could be something like:


tokensWhitelist => allowedTokens
staticStarImportsWhitelist => allowedStaticStarImports
importsBlacklist => prohibitedImports (or disallowedImports)

Thoughts?

Cheers, Paul.


a

Re: More inclusive naming

[Guillaume Laforge]

+1, that's a great idea!


On Thu, Jun 11, 2020 at 5:08 PM Cédric Champeau 
wrote:

> +1
>
> Le jeu. 11 juin 2020 à 16:56, Jeff Beck  a écrit :
>
>> I find those aliases easier to understand. So I think it's a great
>> improvement.
>>
>> Jeff
>>
>> On Thu, Jun 11, 2020, 9:50 AM Paul King  wrote:
>>
>>> Hi folks,
>>>
>>> Given recent world events, there are numerous projects that are taking
>>> the opportunity to use more inclusive terminology especially in names
>>> within APIs. E.g. getting rid of things like master/slave,
>>> blacklist/whitelist, etc. While I have never witnessed any racist behavior
>>> in the Groovy community, it seems worthwhile to be as inclusive as we can.
>>> I scanned our codebase and it seems that the only potential candidate we
>>> have for such a change would be in SecureASTCustomizer. But feel free to
>>> chime in if you think there are others.
>>>
>>> For backwards compatibility, I wouldn't propose to remove the old names
>>> in the first instance, just provide friendly aliases. We can deprecate
>>> and/or remove the current names later if we feel the need. Some example
>>> aliases could be something like:
>>>
>>> tokensWhitelist => allowedTokens
>>> staticStarImportsWhitelist => allowedStaticStarImports
>>> importsBlacklist => prohibitedImports (or disallowedImports)
>>>
>>> Thoughts?
>>>
>>> Cheers, Paul.
>>>
>>>

-- 
Guillaume Laforge
Apache Groovy committer
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Twitter: @glaforge 

Re: More inclusive naming

[Graeme Rocher]

+1

On Thu, Jun 11, 2020 at 5:08 PM Cédric Champeau 
wrote:

> +1
>
> Le jeu. 11 juin 2020 à 16:56, Jeff Beck  a écrit :
>
>> I find those aliases easier to understand. So I think it's a great
>> improvement.
>>
>> Jeff
>>
>> On Thu, Jun 11, 2020, 9:50 AM Paul King  wrote:
>>
>>> Hi folks,
>>>
>>> Given recent world events, there are numerous projects that are taking
>>> the opportunity to use more inclusive terminology especially in names
>>> within APIs. E.g. getting rid of things like master/slave,
>>> blacklist/whitelist, etc. While I have never witnessed any racist behavior
>>> in the Groovy community, it seems worthwhile to be as inclusive as we can.
>>> I scanned our codebase and it seems that the only potential candidate we
>>> have for such a change would be in SecureASTCustomizer. But feel free to
>>> chime in if you think there are others.
>>>
>>> For backwards compatibility, I wouldn't propose to remove the old names
>>> in the first instance, just provide friendly aliases. We can deprecate
>>> and/or remove the current names later if we feel the need. Some example
>>> aliases could be something like:
>>>
>>> tokensWhitelist => allowedTokens
>>> staticStarImportsWhitelist => allowedStaticStarImports
>>> importsBlacklist => prohibitedImports (or disallowedImports)
>>>
>>> Thoughts?
>>>
>>> Cheers, Paul.
>>>
>>>

-- 
Graeme Rocher

Re: More inclusive naming

[Cédric Champeau]

+1

Le jeu. 11 juin 2020 à 16:56, Jeff Beck  a écrit :

> I find those aliases easier to understand. So I think it's a great
> improvement.
>
> Jeff
>
> On Thu, Jun 11, 2020, 9:50 AM Paul King  wrote:
>
>> Hi folks,
>>
>> Given recent world events, there are numerous projects that are taking
>> the opportunity to use more inclusive terminology especially in names
>> within APIs. E.g. getting rid of things like master/slave,
>> blacklist/whitelist, etc. While I have never witnessed any racist behavior
>> in the Groovy community, it seems worthwhile to be as inclusive as we can.
>> I scanned our codebase and it seems that the only potential candidate we
>> have for such a change would be in SecureASTCustomizer. But feel free to
>> chime in if you think there are others.
>>
>> For backwards compatibility, I wouldn't propose to remove the old names
>> in the first instance, just provide friendly aliases. We can deprecate
>> and/or remove the current names later if we feel the need. Some example
>> aliases could be something like:
>>
>> tokensWhitelist => allowedTokens
>> staticStarImportsWhitelist => allowedStaticStarImports
>> importsBlacklist => prohibitedImports (or disallowedImports)
>>
>> Thoughts?
>>
>> Cheers, Paul.
>>
>>

Re: More inclusive naming

[Jeff Beck]

I find those aliases easier to understand. So I think it's a great
improvement.

Jeff

On Thu, Jun 11, 2020, 9:50 AM Paul King  wrote:

> Hi folks,
>
> Given recent world events, there are numerous projects that are taking the
> opportunity to use more inclusive terminology especially in names within
> APIs. E.g. getting rid of things like master/slave, blacklist/whitelist,
> etc. While I have never witnessed any racist behavior in the Groovy
> community, it seems worthwhile to be as inclusive as we can. I scanned our
> codebase and it seems that the only potential candidate we have for such a
> change would be in SecureASTCustomizer. But feel free to chime in if you
> think there are others.
>
> For backwards compatibility, I wouldn't propose to remove the old names in
> the first instance, just provide friendly aliases. We can deprecate and/or
> remove the current names later if we feel the need. Some example aliases
> could be something like:
>
> tokensWhitelist => allowedTokens
> staticStarImportsWhitelist => allowedStaticStarImports
> importsBlacklist => prohibitedImports (or disallowedImports)
>
> Thoughts?
>
> Cheers, Paul.
>
>

More inclusive naming

[Paul King]

Hi folks,

Given recent world events, there are numerous projects that are taking the
opportunity to use more inclusive terminology especially in names within
APIs. E.g. getting rid of things like master/slave, blacklist/whitelist,
etc. While I have never witnessed any racist behavior in the Groovy
community, it seems worthwhile to be as inclusive as we can. I scanned our
codebase and it seems that the only potential candidate we have for such a
change would be in SecureASTCustomizer. But feel free to chime in if you
think there are others.

For backwards compatibility, I wouldn't propose to remove the old names in
the first instance, just provide friendly aliases. We can deprecate and/or
remove the current names later if we feel the need. Some example aliases
could be something like:

tokensWhitelist => allowedTokens
staticStarImportsWhitelist => allowedStaticStarImports
importsBlacklist => prohibitedImports (or disallowedImports)

Thoughts?

Cheers, Paul.