No one is suggesting anything of the sort. This is about expending almost
no effort to be more inclusive. Costs us nothing and avoids contributing to
the daily "paper cuts" inflicted on others.
On Tue, Jun 23, 2020, 7:11 PM John Paul Wohlschied <wohlschied(a)gmail.com>
At this rate, we will be burning older technical books because the
terminology is no longer "acceptable".
On Tue, Jun 23, 2020 at 6:09 PM Gregory Bartholomew <
> I have no objection other than maybe the work it puts on the writer to
> learn the new terminology. Personally I don't typically think along those
> lines and I can see where it might be easy for someone to accidentally use
> a word out of habit and not even realize that it is one that has been
> flagged by the community as an offensive word.
> My only request is that the writers/editors not be expected to learn a
> list of words to constantly be thinking about and watching out for. I
> rather the list be loaded into the spelling autocorrect system somehow.
> My two cents,
> On Tue, Jun 23, 2020 at 4:55 PM Paul Frields <stickster(a)gmail.com> wrote:
> > On Tue, Jun 23, 2020, 5:23 PM Eric Gustavsson <egustavs(a)redhat.com>
> > > 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
> > >
> > I'm sure you can understand, though, why our associations in this case
> > 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
> > 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
> > that avoid simply falling back to status quo.
> > --
> > Paul
> > _______________________________________________
> > Fedora Magazine mailing list -- magazine(a)lists.fedoraproject.org
> > To unsubscribe send an email to magazine-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> Fedora Magazine mailing list -- magazine(a)lists.fedoraproject.org
> To unsubscribe send an email to magazine-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: