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
