Add new names and alias *-*list rules

[diego-codes]

What is the problem you're trying to solve?

Short: Provide terminology to package users that does not perpetuate white supremacy and racism against Black people

Long: There has been a much-needed shift in the tech industry to transition our naming conventions away from problematic racist terminology. For example, Github is replacing the convention of having a master branch to remove any master/slave reference. 

Other terminology that has been pointed out as problematic are the terms blacklist and whitelist. They tell us that black is bad and white is good. Some of our teams at IBM have starting switch to terms like blocklist and allowlist.

This much-appreciated and foundational tool uses blacklist and whitelist terms significantly in its rule names and it would be good to change them.

What solution would you like to see?

Replace blacklist with blocklist and whitelist with allowlist in the rule names maintained in this repo. Additionally, provide supportive deprecation warnings so developers know about the change and why it is an important change.

[diego-codes]

To add, I am more than happy to contribute to this change if there is an agreed-upon direction.

[kevindew]

I've been planning to make a similar proposal (although had gone with allowlist and denylist) and I wanted to put together a PR to demonstrate a potential implementation route, given as this is quite a big change for this project. As timing would have it, I forked this project today to work on an implementation. It's not quite finished it but it's available here: kevindew#1. I will plan to raise it as an PR for this project tomorrow (PR open here: #4845)

Similar threads on other repos can descend into arguments around the etymology of the word, however what I find compelling is that terminology such as allowlist and denylist is more explicit in their meaning compared to whitelist and blacklist. They therefore offer an objective improvement in clarity regardless of opinions on their appropriateness in todays society.

[hudochenkov]

Other terminology that has been pointed out as problematic are the terms blacklist and whitelist.

Additionally, provide supportive deprecation warnings so developers know about the change and why it is an important change.

Could you recommend articles to read about problems with these terms, please? I want to educate myself.

[kevindew]

Other terminology that has been pointed out as problematic are the terms blacklist and whitelist.
Additionally, provide supportive deprecation warnings so developers know about the change and why it is an important change.

Could you recommend articles to read about problems with these terms, please? I want to educate myself.

https://www.ncsc.gov.uk/blog-post/terminology-its-not-black-and-white

Here are some approaches from other open source projects:

rails/rails#33677
https://bugs.chromium.org/p/chromium/issues/detail?id=842296
rubocop/ruby-style-guide#820

[jeddy3]

@diego-codes Thanks for raising the issue.

We widely use the terms "allow", "disallow" and "require" in our documentation, particularly for the descriptions of each rule. I suggest we use these terms in the rule names, rather than introduce new terms like denylist or blocklist. The description of each *-*list rule currently takes the form of "Specify a blacklist/requirelist/whitelist of disallowed/required/allowed x". For example:

• function-blacklist: Specify a blacklist of disallowed functions.
• unit-whitelist: Specify a whitelist of allowed units.
• at-rule-property-requirelist: Specify a requirelist of properties for an at-rule.

We can rename the rules and replace the instances of "blacklist", "requirelist", "whitelist" with "list" in the descriptions:

• function-disallowed-list: Specify a list of disallowed functions.
• unit-allowed-list: Specify a list of allowed units.
• at-rule-property-required-list: Specify a list of required properties for an at-rule.

I think these names and descriptions are clear, not problematic and aligned with our thing-check naming convention.

We can make this same shift to "list" in our source code too, e.g. for the primary option parameter in each of the *-*list rules.

I suggest we rename and alias the *-*list rules, like ESLint has done with their id-blacklist rule. RuboCop was able to make their change as a pre-1.0.0 breaking one, whereas we're in a similar position to ESLint. Since version 7.0.0, we've avoided using the deprecate-then-remove cycle for rule name changes, reserving it for when rules are removed from core completely or replaced by a broader rule. We shouldn't alias new *-list rules, and only use the new naming conventions for them.

We'll need to add something along the lines of "This rule was previously called, and is aliased as, x." to the first line of the expanded description in each of the READMEs of the renamed rules.

We'll also need a follow-up pull request in the stylelint.io repository to add redirects to the website for the renamed rules.

[hudochenkov]

And we would need to update readme's of our configs (we don't use any *list rules in the configs themselves):

https://github.com/stylelint/stylelint-config-standard
https://github.com/stylelint/stylelint-config-recommended

[tysongach]

This is great - thanks all for starting this conversation and moving forward with changes!

Apple is also replacing exclusionary language in its developer documentation and APIs: https://developer.apple.com/news/?id=1o9zxsxl