Docs: Add clarification link to rule policy blog post (#825)

Refs eslint/tsc-meetings#237 and depends on eslint/eslint#14052.

_posts/2020-05-22-changes-to-rules-policies.md

@@ -17,7 +17,7 @@ Going forward, we're making the following changes to how we deal with rule issue
 
 * **New rules are limited** - we will only accept new rules when they relate to new ECMAScript features that reached stage 4 in the preceding 12 months. The community relies on ESLint to help teach them the correct way to use new language features, and we want to continue doing that. We won't be accepting new rules that are suggestions or preferences unrelated to new ECMAScript features.
 * **No new rules that only disallow syntax** - we already have [`no-restricted-syntax`](https://eslint.org/docs/rules/no-restricted-syntax), which should work for most cases. Otherwise, people can create their own rules. We do have some legacy rules that just disallow syntax (like [`no-undefined`](https://eslint.org/docs/rules/no-undefined)) that we will keep, but we won't be adding any more.
-* **Stylistic rules are frozen** - we won't be adding any more options to stylistic rules. We've learned that there's no way to satisfy everyone's personal preferences, and most of the rules already have a lot of difficult-to-understand options. Stylistic rules are those related to spacing, conventions, and generally anything that does not highlight an error or a better way to do something.
+* **Stylistic rules are frozen** - we won't be adding any more options to stylistic rules. We've learned that there's no way to satisfy everyone's personal preferences, and most of the rules already have a lot of difficult-to-understand options. Stylistic rules are those related to spacing, conventions, and generally anything that does not highlight an error or a better way to do something. _Update 2021-01-29: We clarified in [the README](https://github.com/eslint/eslint#stylistic-rule-updates) that we will still support newly-added ECMAScript features._
 * **New rule options must be implemented by community members** - People can still propose new options for existing core non-stylistic rules, and we will still evaluate them as usual. However, these approved options will need to be implemented by the community and won't be part of core team's development roadmap. 
 
 ## What about bugs?