I haven't checked all rules .... but it seems that after merging this, we couldn't use words like backend (.vale/Microsoft/Avoid.yml) and expressions like e.g. or i.e. (.vale/Microsoft/Foreign.yml) which are very common in our docs.

My opinion is that, even if linting is always nice, if we add this to CI checks it could be too much linting, which creates friction for contributors and demoralizes maintainers. If it's used as a command run from time to time to fix some of the issues and ignore all the false positives, then it could be a useful tool.

I haven't checked all rules .... but it seems that after merging this, we couldn't use words like backend (.vale/Microsoft/Avoid.yml) and expressions like e.g. or i.e. (.vale/Microsoft/Foreign.yml) which are very common in our docs.

My opinion is that, even if linting is always nice, if we add this to CI checks it could be too much linting, which creates friction for contributors and demoralizes maintainers. If it's used as a command run from time to time to fix some of the issues and ignore all the false positives, then it could be a useful tool.

It's all configurable.

Never heard of Vale. I think this is very interesting!

As a start, we can include it for usage as a local linter (like we also did with the .alexrc config). It seems to have some false-positives and errors that are more "are you sure this is what you want", so enforcing it in CI might be a step to far as of now.

Some of the rules can replace rules that exists in DOCtor-RST. Some of the rule sets also give a nice insight in some "best practices" of writing English sentences that we didn't use in the docs yet.

I've adopted the config a bit to match our style (e.g. using "e.g." and our Chicago-like title case) and linted all guides in the "quick tour", "create your own framework" and "getting started" section of the docs: ac3b26b In general, I feel like this can be a useful tool.