Obviously existing printed material cannot be changed. But newer editions of books can most certainly address these things if they so desire. 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 https://www.youtube.com/watch?v=hZuFeFuazwo Eric Gustavsson, RHCSA He/Him/His Software Engineer Red Hat 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@xxxxxxxxx> wrote: > > 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 <gregory.lee.bartholomew@xxxxxxxxx> wrote: >> >> 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, >> gb >> >> On Tue, Jun 23, 2020 at 4:55 PM Paul Frields <stickster@xxxxxxxxx> wrote: >> >> > On Tue, Jun 23, 2020, 5:23 PM Eric Gustavsson <egustavs@xxxxxxxxxx> 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 >> > _______________________________________________ >> > Fedora Magazine mailing list -- magazine@xxxxxxxxxxxxxxxxxxxxxxx >> > To unsubscribe send an email to magazine-leave@xxxxxxxxxxxxxxxxxxxxxxx >> > 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://lists.fedoraproject.org/archives/list/magazine@xxxxxxxxxxxxxxxxxxxxxxx >> > >> _______________________________________________ >> Fedora Magazine mailing list -- magazine@xxxxxxxxxxxxxxxxxxxxxxx >> To unsubscribe send an email to magazine-leave@xxxxxxxxxxxxxxxxxxxxxxx >> 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://lists.fedoraproject.org/archives/list/magazine@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ Fedora Magazine mailing list -- magazine@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to magazine-leave@xxxxxxxxxxxxxxxxxxxxxxx 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://lists.fedoraproject.org/archives/list/magazine@xxxxxxxxxxxxxxxxxxxxxxx
