Switch to more inclusive language
Issue #169
closed
It would be great if this package could adopt more inclusive language terms for:
- Whitelist/blacklist: Switch to Allowed List and Blocked List (or Approve List/Deny List - some software uses this instead) respectively. Google and many developers are formalizing allowlist and blocklist. You might want to lobby for those terms to be used in the UI. This follows guidance from the IETF.
Obviously this would cause breaking changes in this package and should not be entered into lightly but we are looking at all our dependencies using outdated language.
Comments (6)
-
-
repo owner
I think it’s worth pointing out that, while I personally tend to agree with its sentiment and content, the document referenced is not official guidance from the IETF. There’s also a newer revision of it FWIW: https://tools.ietf.org/html/draft-knodel-terminology-02. But it’s somewhat common misunderstanding to think that documents formatted that way and on the ietf.org servers are official IETF documents or have some status therein. This document here https://tools.ietf.org/html/draft-abr-twitter-reply-00 is a good example of why that’s not the case.
I’m not pushing back on the request or even the reasoning behind it. But the IETF nerd in me needs to say that it is inaccurate to cite that document as “guidance from the IETF.” It’s guidance from a couple of individuals, which you and I can agree with. But it’s not more or more authoritative than that.
-
repo owner
b512eaf transition to using more inclusive language for the ConstraintType names in AlgorithmConstraints by added two new enum values (
BLOCK&PERMIT) while marking the old whitelist/blacklist ones as deprecated. -
repo owner
also updated the examples
-
repo owner
- changed status to resolved
thanks for raising this. Probably should have been done a long time ago. But better now than never. And this ticket was a catalyst to do something.
-
repo owner
- changed status to closed
released in v0.7.2
- Log in to comment
Breaking changes certainly do have wide implications that need to be considered. I think transitioning via deprecation and the introduction of new names is a reasonable path forward for this.