On Tue, Jun 23, 2020, 5:23 PM Eric Gustavsson <egustavs(a)redhat.com> wrote:
Raising my opinion as well. As a Swedish person, I've always
associated whitelists as a list of things you can see, since white is
bright.
Likewise for blacklists as something in the darkness that you cannot see.
I'm sure you can understand, though, why our associations in this case are
less relevant.
I personally would use the same connotation as the project I'm writing
about.
If I'm writing about Redis I will write about master-replica.
Likewise if I'm writing about something that uses whitelist/blacklist
wording, I will use that as well.
Using a different connotation than is documented is just confusing.
While I agree upstream references may make this difficult there are still
actions we can take, such as a note to the effect of the objectionable
language, and (if it exists) a link to upstream discussion. We can also
work around with a clear note at the top of an article explaining the
language we will use.
I wouldn't edit the Fedora Magazine article either, even though
allowlist/denylist 100% makes more sense in firewalld the article
talks about it as a problem and proposes a solution - their
firewalld-blacklist package.
If it was to be edited across the article to mention denylist instead,
and in the end link to a firewalld-blacklist package they created, one
would be confused as to why it was coded with one word and released
with a different one.
This seems a weak problem. After all we have many -devel packages that
contain mainly headers.
I would vote for discouraging master/slave, and blacklist/whitelist as
long as it makes sense and doesn't take away any meaning that
needs to
be explained.
Having a style guide sounds great, I'm presuming something like
codespell can correct custom words as well like RedHat,
NetworkManager, fedora, etc.
I do agree we avoid creating confusion, but this can be done in many ways
that avoid simply falling back to status quo.
--
Paul