Surely there must be something that is more important than this childish nonsense.
On 6/23/2020 6:16 PM, Eric Gustavsson wrote:
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 writingabout. 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 thoughallowlist/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 aslong 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
_______________________________________________ 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
