Obviously existing printed material cannot be changed. But newer
editions of books can most certainly address these things if they so
Paul, Ben - there was an OSPO talk about inclusive terminology that
was put up a couple of weeks ago that might be of some interest
Eric Gustavsson, RHCSA
IM: Telegram: @SpyTec
E1FE 044A E0DE 127D CBCA E7C7 BD1B 8DF2 C5A1 5384
On Wed, 24 Jun 2020 at 01:11, John Paul Wohlschied <wohlschied(a)gmail.com> wrote:
At this rate, we will be burning older technical books because the terminology is no
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 long
> list of words to constantly be thinking about and watching out for. I would
> 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 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
> > _______________________________________________
> > 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:
> > https://firstname.lastname@example.org...
> 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: