Hi Internals,
I'd like to start a discussion period for my RFC which proposes to change
the use of "blacklist" in Opcache configuration with better
self-descriptive terminology.
The RFC is here https://wiki.php.net/rfc/change-terminology-to-excludelist
Discussions should remain on the list.
Any emails sent directly are likely to be replied to on the list.
Cheers,
Michał Marcin Brzuchalski
On Tue, 16 Jun 2020 at 13:15, Michał Brzuchalski
michal.brzuchalski@gmail.com wrote:
Hi Internals,
I'd like to start a discussion period for my RFC which proposes to change
the use of "blacklist" in Opcache configuration with better
self-descriptive terminology.
Hi Michał,
Thanks for posting the RFC.
In my opinion it costs very little to change.
Having 'white' == good, and 'black' == bad is not a good thing to have
in the English language.
You can argue the cause and effect of whether racism led to that
meaning, or whether that meaning could lead to people being racist,
but it costs so little to change it, we should.
cheers
Dan
Ack
Maintainer of Imagick
I'd like to start a discussion period for my RFC which proposes to change
the use of "blacklist" in Opcache configuration with better
self-descriptive terminology.
IMHO this RFC should not come to a vote, the current RFC process is
ill-equipped to handle such a vote.
This RFC, disguised in a cloak of wanting to improve readability, is
clearly political. Not political in terms of the inner politics of the
PHP internals group, but in terms of the larger world.
At the time of publishing, there are currently countless riots,
protests, counter-protests, harassment and criminal acts surrounding
this issue. It cannot reasonably be argued that the timing is anything
other than a political statement, the commonly accepted term would be
virtue signalling.
In this climate, it is likely impossible to hold a meaningful vote on
the issue. Internals on internals are not hidden behind some corporate
monolith like Github / Microsoft. Our names are our own, our contact
details readily available.
Anyone voting against this RFC on the proposal on any of the perfectly
legitimate grounds to do so, such as the BC issues, will still
immediately be labeled a racist and is likely to receive threats or
harassment.
Anyone voting for it is likely to receive harassment too.
As I said, the current voting system is ill-equipped to handle such a
setup. If you expect everyone who wants to have a free say, to have a
free say, there must be an element of anonymity that simply does not
exist in our current processes.
The RFC author has already stated in R11 that they have started
receiving harassing emails in relation to it.
Hi
Den tir. 16. jun. 2020 kl. 15.15 skrev Michał Brzuchalski
michal.brzuchalski@gmail.com:
Hi Internals,
I'd like to start a discussion period for my RFC which proposes to change
the use of "blacklist" in Opcache configuration with better
self-descriptive terminology.
I disagree with this statement, and I do not believe that just because
you think it is a better terminology, it should be justifying the BC
break that comes with this change. Like I expressed in the PR when it
was originally posted and the other topic currently active on
internals that it seems much like a change for the sake of change.
This is clearly a political change and something we as a project
should refrain from doing. If this RFC comes to pass, are we going to
change the PHP.net logo to declare our political allegiance to the
cause in America? Attempting to change something which has no
correlation to racial remarks but using it as an argument that it can
be is an absurd argument to me.
The RFC is here https://wiki.php.net/rfc/change-terminology-to-excludelist
The pull request in the linked RFC does not seem to reflect all the
details of this RFC, the PR also changes the whitelist to allowlist,
something that is not noted in the RFC itself among other things, or
did I miss something?
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Hi Kalle,
wt., 16 cze 2020 o 14:35 Kalle Sommer Nielsen kalle@php.net napisał(a):
...
The RFC is here
https://wiki.php.net/rfc/change-terminology-to-excludelistThe pull request in the linked RFC does not seem to reflect all the
details of this RFC, the PR also changes the whitelist to allowlist,
something that is not noted in the RFC itself among other things, or
did I miss something?
I've updated the patch, the PR description and a title to reflect the RFC
proposal.
It's true that there were things not reflected in the RFC, now they're gone.
Also, I've accidentally pushed some files which shouldn't even get there
and they're also gone.
If we decide in the second vote on the right name, I'll update it
respectively again.
Cheers,
Michał Marcin Brzuchalski
+1 for this, exclude_list better explains code intent than blacklist.
--
Cheers,
Daniel Rodrigues.
geekcom@php.net
https://twitter.com/geekcom2
De: Michał Brzuchalski michal.brzuchalski@gmail.com
Enviado: terça-feira, 16 de junho de 2020 09:14
Para: PHP Internals List internals@lists.php.net
Assunto: [PHP-DEV] [RFC][Discussion] Change terminology to ExcludeList
Hi Internals,
I'd like to start a discussion period for my RFC which proposes to change
the use of "blacklist" in Opcache configuration with better
self-descriptive terminology.
The RFC is here https://wiki.php.net/rfc/change-terminology-to-excludelist
Discussions should remain on the list.
Any emails sent directly are likely to be replied to on the list.
Cheers,
Michał Marcin Brzuchalski
Le 16 juin 2020 à 14:14, Michał Brzuchalski michal.brzuchalski@gmail.com a écrit :
Hi Internals,
I'd like to start a discussion period for my RFC which proposes to change
the use of "blacklist" in Opcache configuration with better
self-descriptive terminology.The RFC is here https://wiki.php.net/rfc/change-terminology-to-excludelist https://wiki.php.net/rfc/change-terminology-to-excludelist
Hi,
I object that the proposed term is in any way clearer. “Blacklist” is an idiomatic term with a well-established meaning, so that it is immediately recognisable, and it couldn’t mean anything else that it intends to mean. On the other hand, “exclude_list” is less common, and since I am not accustomed to that terminology, I have to analyse the expression, or rather, since English has the unfortunate tendency to stack words without specifying neither their function nor the precise relation between them, I have to guess what it could mean, with good chance of getting wrong: “exclude the list”? whereas “blacklist” means in fact: “list of items to exclude”.
—Claude
I'd like to start a discussion period for my RFC which proposes to change
the use of "blacklist" in Opcache configuration with better
self-descriptive terminology.
Since there will be a higher level change to all these terms - in all
likelihood - trying to push yet another term that does not match the
current discussions elsewhere seems somewhat premature. The NEXT RFC
will be to bring this in line with the 'new' industrial standard, so is
there any point jumping the gun before the international debate has
finished? "blocklist", "banlist", and others all have appropriate
application but like "excludelist", they all imply a narrower usage area
while "blacklist" is accepted generally across all applications.
What ever alternative to "blacklist" is adopted elsewhere is going to
cause confusion and adding to that confusion with a different
'translation' just makes the situation worse?
--
Lester Caine - G8HFL
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk
I'd like to start a discussion period for my RFC which proposes to change
the use of "blacklist" in Opcache configuration with better
self-descriptive terminology.Since there will be a higher level change to all these terms - in all
likelihood - trying to push yet another term that does not match the
current discussions elsewhere seems somewhat premature. The NEXT RFC
will be to bring this in line with the 'new' industrial standard, so is
there any point jumping the gun before the international debate has
finished? "blocklist", "banlist", and others all have appropriate
application but like "excludelist", they all imply a narrower usage area
while "blacklist" is accepted generally across all applications.What ever alternative to "blacklist" is adopted elsewhere is going to
cause confusion and adding to that confusion with a different
'translation' just makes the situation worse?
I agree with this 100%. Without offering an opinion on whether or not we
should change it, I do think it makes sense that if we do change it, we at
least wait until a more standard term has been decided among other
developers and projects. It would also provide another justification for
the change, if the change was being made to align with industry standards.
I also want to point out my agreement with others that have posted about
the current climate not being conducive to an honest conversation on this
topic. The current climate in the US is such that often it's not enough to
agree on what the end goal should be. If someone doesn't agree with how we
reach that goal and why we should reach it, they are treated as if they are
against achieving the goal altogether. This topic is very susceptible to
those kinds of reactions.
--
Lester Caine - G8HFLContact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk--
--
Chase Peeler
chasepeeler@gmail.com
Hi Lester,
wt., 16 cze 2020 o 15:55 Lester Caine lester@lsces.uk napisał(a):
I'd like to start a discussion period for my RFC which proposes to change
the use of "blacklist" in Opcache configuration with better
self-descriptive terminology.Since there will be a higher level change to all these terms - in all
likelihood - trying to push yet another term that does not match the
current discussions elsewhere seems somewhat premature. The NEXT RFC
will be to bring this in line with the 'new' industrial standard, so is
there any point jumping the gun before the international debate has
finished? "blocklist", "banlist", and others all have appropriate
application but like "excludelist", they all imply a narrower usage area
while "blacklist" is accepted generally across all applications.What ever alternative to "blacklist" is adopted elsewhere is going to
cause confusion and adding to that confusion with a different
'translation' just makes the situation worse?
Isn't that the more narrow term is used it's easier to understand?
We can easily vote on the right name.
I chose the "exclude list" cause the INI setting which changes name in this
proposal
is a glob path to filenames.
These files are then parsed as a list of glob paths for later file
exclusion on opcache run.
Another term in my mind is "ignore list" which then suggest a list of files
ignored by opcache run.
Regarding the "blocklist" I have to admit that it was my first thought but
after thinking IMO it's inappropriate.
There is nothing in the opcache what blocks files from being cached and
optimised,
they by themselves are not trying to be cached, cause the flow is from
opcache extension.
For me to whom English is not a native language first association is with
blocking service access to the clients
which interacts with the service and try to get access to it.
That's why I think it's inappropriate here and I've changed it in the
original patch.
The same goes for the "banlist" for me my first association is with the
client who had access to the service
but due to some policy reasons (like fo reg. destructive intentions or
overuse), the client lost access rights and
get's banned with assignnment to the "banlist".
Therefore IMO we should choose a new name wisely so it can be
self-descriptive.
What I can propose is update of RFC with a note regarding the second vote
for the right name.
I'd like to put there an "exclude_list" and "ignore_list", but if my
reasoning about not debating
on the "banlist" and/or "blocklist" is not enough then please let me know
then I can add those two also.
Cheers,
Michał Marcin Brzuchalski
Therefore IMO we should choose a new name wisely so it can be
self-descriptive.
Also: important to choose words/names that are being adopted elsewhere; thus
people will recognise it as they have learned it elsewhere.
I cannot predict what new words will become the replacement for blacklist - if
it is indeed replaced. No one can.
I would suggest that this be put into the cooler until (and if) there is general
agreement elsewhere -- we would not want to change again in a couple of years
as we had chosen the 'wrong' term.
Regards
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 https://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h
On Wed, Jun 17, 2020 at 5:46 AM Michał Marcin Brzuchalski <
michal.brzuchalski@gmail.com> wrote:
Hi Lester,
wt., 16 cze 2020 o 15:55 Lester Caine lester@lsces.uk napisał(a):
I'd like to start a discussion period for my RFC which proposes to
change
the use of "blacklist" in Opcache configuration with better
self-descriptive terminology.Since there will be a higher level change to all these terms - in all
likelihood - trying to push yet another term that does not match the
current discussions elsewhere seems somewhat premature. The NEXT RFC
will be to bring this in line with the 'new' industrial standard, so is
there any point jumping the gun before the international debate has
finished? "blocklist", "banlist", and others all have appropriate
application but like "excludelist", they all imply a narrower usage area
while "blacklist" is accepted generally across all applications.What ever alternative to "blacklist" is adopted elsewhere is going to
cause confusion and adding to that confusion with a different
'translation' just makes the situation worse?Isn't that the more narrow term is used it's easier to understand?
We can easily vote on the right name.I chose the "exclude list" cause the INI setting which changes name in this
proposal
is a glob path to filenames.
Please stop using the term "glob." As a person that is above what many
would consider an ideal weight, I've been called a "useless glob" on
multiple occasions. This term is harmful to me as a result.
These files are then parsed as a list of glob paths for later file
exclusion on opcache run.
Another term in my mind is "ignore list" which then suggest a list of files
ignored by opcache run.
When I grew up, I was often ignored by other people, causing me to be
lonely and depressed. The term "ignore list" triggers those same feelings,
so please avoid using this in the future.
Regarding the "blocklist" I have to admit that it was my first thought but
after thinking IMO it's inappropriate.
My father often called me an "ignorant blockhead" so the term "blocklist"
triggers negative emotions as well.
There is nothing in the opcache what blocks files from being cached and
optimised,
they by themselves are not trying to be cached, cause the flow is from
opcache extension.For me to whom English is not a native language first association is with
blocking service access to the clients
which interacts with the service and try to get access to it.
That's why I think it's inappropriate here and I've changed it in the
original patch.The same goes for the "banlist" for me my first association is with the
client who had access to the service
but due to some policy reasons (like fo reg. destructive intentions or
overuse), the client lost access rights and
get's banned with assignnment to the "banlist".Therefore IMO we should choose a new name wisely so it can be
self-descriptive.
What I can propose is update of RFC with a note regarding the second vote
for the right name.
I'd like to put there an "exclude_list" and "ignore_list", but if my
reasoning about not debating
on the "banlist" and/or "blocklist" is not enough then please let me know
then I can add those two also.Cheers,
Michał Marcin Brzuchalski
None of the above are actually true (except for the fact that I'm
overweight). The point I'm trying to raise is that context matters, and
changing terms because some people refuse to understand the context is not
justified. Otherwise you open a pandora's box where you either have to
change everything that someone claims offends them, or, you have to pick
and choose which people or group are allowed to be offended and which are
not. If the term blacklist had racist origins, the discussion might be
different. However, it does not, just like glob does not have origin in
fat-shaming.
I have no problem changing these terms if they are changed industry wise
and the new terms are needed to keep up with industry standards. I might
not agree with why they were changed in other arenas, but, at the point new
terms become standard, the reason they became standard doesn't really
matter. So, as others have said, this and other discussions about renaming
terms because some might find them offensive is not something we should be
doing. Renaming terms in order to align with changes to industry standards,
while something we should do, is premature at this point as those standards
have yet to change.
--
Chase Peeler
chasepeeler@gmail.com
None of the above are actually true (except for the fact that I'm
overweight). The point I'm trying to raise is that context matters, and
changing terms because some people refuse to understand the context is not
justified. Otherwise you open a pandora's box where you either have to
change everything that someone claims offends them, or, you have to pick
and choose which people or group are allowed to be offended and which are
not. If the term blacklist had racist origins, the discussion might be
different. However, it does not, just like glob does not have origin in
fat-shaming.
There was a similar brouhaha a year or two back in the folk dancing world. Some
display dance groups paint their faces black as many of the dances were done
like that a century or so ago. There were cries about this offending people
with dark skins. In fact the origin was where some would dance around their
village, drink a lot, cause mischief - the purpose of blacking up was to make
it harder for them to be recognised.
Walking back (to shower off) after doing this I walked past a black family; they
looked curious, I explained, smiles all round.
Context is all.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 https://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h
Please stop using the term "glob." As a person that is above what many
would consider an ideal weight, I've been called a "useless glob" on
multiple occasions. This term is harmful to me as a result.
Though I know you're joking (and I laughed out loud!) I think you are
misunderstanding something:
Calling someone black is actually not offensive!
To repeat what has been said many times over now: It's when "black" is
associated with "bad" in a composite term like "blacklist" we should
consider being considerate of a group of people who actually have skin
of that color.
If we, hypothetically, happened to be using the term "obeselist" (for
whatever obscure historical reason) to mean "list of things to be
blocked", would you also think that was totally fine because context
is everything and nobody's saying you're worth less because you're
overweight?
Best,
Jakob
Am 18.06.2020 um 00:36 schrieb Jakob Givoni jakob@givoni.dk:
To repeat what has been said many times over now: It's when "black" is
associated with "bad" in a composite term like "blacklist" we should
consider being considerate of a group of people who actually have skin
of that color.Best,
Jakob
TL;DR: Can we please do terminology changes for the right reasons, just like the RFC itself is proposing. Thanks.
You can also define black as what pure black really is - void of everything - no light - nothing. Things we don't see.
And white being light. Things we see.
It does not necessarily need to have a connection with good and bad. You can also blacklist legitimate things, but you just don't want to process them right now.
The issue is rather that we are talking about "good" and "bad" inputs and then connect that to a white- or blacklist. (Because usually the things we do not want to see are bad things)
There however is no innate connection from something being black to it being bad, rather a coincidence via a couple hops. And only applying in most cases.
For example: "I want to whitelist undesired inputs for logging."
While I see that there is a case for a more unambiguous wording like opcache_file_exclude, this matter shall not be about the good-ness or bad-ness of the color black.
P.s. And to be honest, I've never heard from a dark-skinned person that they felt actually oppressed by words like blacklist.
And here my personal opinion, to be taken with a grain of salt: This whole white- and blacklist discussion is mostly "hey I want to make black people feel more welcome, let me call blacklist bad and condemn everyone not agreeing. Then I have done my good deed" - without having any actual impact on the well-being of dark-skinned people. - That's what it feels like for me, but I'm open to being corrected by those who are actually dark-skinned and impacted by it, in which case I'll immediately retract my last sentence.
Bob
P.s. And to be honest, I've never heard from a dark-skinned person that
they felt actually oppressed by words like blacklist.And here my personal opinion, to be taken with a grain of salt: This whole
white- and blacklist discussion is mostly "hey I want to make black people
feel more welcome, let me call blacklist bad and condemn everyone not
agreeing. Then I have done my good deed" - without having any actual impact
on the well-being of dark-skinned people. - That's what it feels like for
me, but I'm open to being corrected by those who are actually dark-skinned
and impacted by it, in which case I'll immediately retract my last sentence.
Hi Bob,
Nobody is talking about oppression when it comes to certain "technical"
terms. Please look my post from earlier and look at the tweets I link:
https://externals.io/message/110515#110574
I can recommend everyone to expand their bubble, as a lot of replies in
here show that the bubbles are homogeneous.
Regards,
Lynn
Am 18.06.2020 um 20:24 schrieb Lynn kjarli@gmail.com:
P.s. And to be honest, I've never heard from a dark-skinned person that they felt actually oppressed by words like blacklist.
And here my personal opinion, to be taken with a grain of salt: This whole white- and blacklist discussion is mostly "hey I want to make black people feel more welcome, let me call blacklist bad and condemn everyone not agreeing. Then I have done my good deed" - without having any actual impact on the well-being of dark-skinned people. - That's what it feels like for me, but I'm open to being corrected by those who are actually dark-skinned and impacted by it, in which case I'll immediately retract my last sentence.
Hi Bob,
Nobody is talking about oppression when it comes to certain "technical" terms. Please look my post from earlier and look at the tweets I link: https://externals.io/message/110515#110574 https://externals.io/message/110515#110574
I can recommend everyone to expand their bubble, as a lot of replies in here show that the bubbles are homogeneous.
Regards,
Lynn
Hey,
yes, you are making quite the same point than I did. Maybe I misused the word oppression here. But in any case, I fully agree with you.
Bob
Den 2020-06-16 kl. 14:14, skrev Michał Brzuchalski:
Hi Internals,
I'd like to start a discussion period for my RFC which proposes to change
the use of "blacklist" in Opcache configuration with better
self-descriptive terminology.The RFC is here https://wiki.php.net/rfc/change-terminology-to-excludelist
Discussions should remain on the list.
Any emails sent directly are likely to be replied to on the list.Cheers,
Michał Marcin Brzuchalski
Hi,
Some comments:
- I miss from this RFC how it affects documentation if any and with that
how it affects translation of the documentation. So even if it's a small
effort to change a few lines in the INI file, it might be bigger
doing it in
the documentation and also come up with good translations to other
languages. - I assume that there is a limited amount of people working with INI files,
primarily sysadmins and to some degree developers and they are not
doing it everyday. So is it fair to assume that it's a limited amount of
people working with INI files and they are not doing it every day? - In a hosting environment where this INI file lives it's fair to assume
that
multiple versions of PHP are hosted, e.g. today it can be both 5.6
and 7.x.
So for the sysadmin there will be different names for same functionality
in the INI file when 8.0 comes out. - As a side note, the default version shipped with the recent CentOS 7.8
version, it's PHP 5.4.
I also think it's a bit premature to jump on this wagon for several reasons.
r//Björn L
Hello everyone,
I would like everyone to slow down a bit and give a think about this:
English is not the primary language for the vast majority of people. are
a thing and a lot of people, actually, work with PHP that either does not
know English at all or, know the basics and rarely have the English skills
to a level that allows them to easily understand subtleties of things.
What you need to consider, that some alternatives that are being talked
about, may not have a translation. Like at all. Here's a case and point for
the Russian language - there is no alternative, as far as I can tell, for a
"blacklist" that has the meaning blacklist or exclude list can be
translated. The only Russian phrase that I know of (and I tried searching
for alternatives) is a literal translation of the phrase "black list".
Anything I could think of just didn't fit - there is just no other word
that describes an "exclude list" - it translates literally to "black list"
anyway.
Same goes for the Latvian language - the only word we have for it is a
literal translation and nothing else.
And I suspect, it might be the case for many other languages too for a
simple reason - the term came from English first and got adopted one way or
the other into the language because there was no counterpart for it in it.
On the other hand, Russian has a great translation for the "master/slave"
combo - ведущий/ведомый that has 0 association with anything slavery
related. But the literal translation to English is "master/slave", and it
does not translate correctly to "Primary/Secondary" or other alternatives
I've seen around, because it looses all meaning that Russian words describe
for the technical implications of how things work in mechanics, engines and
so on. it's also actually used in aviation too between Commander and Second
Officer. Closest I can translate it is "Leading / One who is led by the
leading".
Just my 0.02$ as food for thought, because PHP is not a regional project.
This is a global project and it's userbase overall, probably, is not
primarily English speakers. A lot of us just revolve around in English
speaking tech bubble, because it is the international language and it is
easiest for everyone who is involved in OSS projects and international
companies. But I'm not, personally, an English speaker - English is my 3rd
language.
I also live in Russian tech space and it is pretty common to have
developers who do not know English to a level of speaking and/or reading
and relly on documentation translations and those established
industry-standard terms that they know and/or use google translate.
P.S. I just run "exclude list" through google translate into Russian and
Latvian - let's just say that translations were confusing at best because I
can't judge how bad they would be for a person who does not know English
well or at all.
Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius