feat(vale): add rule for upper lower case titles

[Langleu]

Description

Just a proposal, we don't have to follow through with it, something I noticed that could be helpful to automate.

We are not following vale supported AP or Chicago styles for titles but rather uppercase followed by lowercase.

The following introduces a simple regex rule to filter out unsupported titles.

There are of course, a lot of proper nouns, I excluded some but stopped to hear whether this idea has any value for DevEx before putting work into it.

Additionally, there are maybe cases that we don't want to exclude that could simply be wrapped in the following to not trigger.

<!-- vale all.titleUpperLowerCase = NO -->
# Some Random Title We Want Hower We Want
<!-- vale all.titleUpperLowerCase = YES -->

Let me know what you think.

When should this change go live?

• This change is not yet live and should not be merged until {ADD_DATE} (apply hold label or convert to draft PR)?
• There is no urgency with this change.
• This change or page is part of a marketing blog, conference talk, or something else on a schedule.
• This functionality is already available but undocumented.
• This is a bug fix or security concern.

PR Checklist

• I have added changes to the relevant /versioned_docs directory, or they are not for an already released version.
• I have added changes to the main /docs directory (aka /next/), or they are not for future versions.
• My changes require an Engineering review, and I've assigned an engineering manager or tech lead as a reviewer, or my changes do not require an Engineering review.
• My changes require a technical writer review, and I've assigned @christinaausley as a reviewer, or my changes do not require a technical writer review.

[pepopowitz]

I like the idea! Some thoughts I have:

1. I'm concerned that the check-format workflow running on this PR is currently approaching 4 hours of run time. I'm not certain it's related to this change, but it's worth investigating.
2. I am interested to hear from @christinaausley about this rule. (a) is it helpful from her perspective, and (b) is the maintenance of proper nouns helpful in that it provides a single source of truth, painful in that it requires a lot of maintenance, or some combination of helpful & painful?

Just an FYI, from our perspective (DX team), we're unlikely to think about this PR much until after the upcoming minor release.

[Langleu]

Makes sense concerning the priority of the release!

Agree, not sure what the long runtime is about since it's already just scoped to headings. If it's deemed useful, I would have another look over the regex and see what can be optimized.

[christinaausley]

I am interested to hear from @christinaausley about this rule. (a) is it helpful from her perspective, and (b) is the maintenance of proper nouns helpful in that it provides a single source of truth, painful in that it requires a lot of maintenance, or some combination of helpful & painful?

Thanks for proposing this @Langleu! A few things:

• Will doc authors receive a GH ping/message if they don't fit these confines? If so, I'd rather hold on this so we don't overflow PRs with requested fixes/errors.
• I think this is cool all in all, and could be a fun test. Like you said, there are so many different proper nouns that this could get overwhelming, but I don't mind adding nouns to the list as I catch them, just depends if it gets annoying or remains pretty calm.

All in all, I don't mind fixing these headers as I review them. If this will create any noise in the PRs with errors or messages, I'd rather hold off, but if it will remain pretty quiet and I can add proper nouns to the list as I go, it might work. Makes me think I should start building out a custom "clippy" extension in my free time 😉

[Langleu]

Hey 👋,
atm it would only be run as part of the check-format pipeline and yes, I guess it would add PR messages / pings.
One could add it as a pre-commit hook, similar to husky to have it run on the changed files for every commit.
If I have time next week I could have a look into optimizing the regex to have it run quicker.

I like the Clippy idea 😁. Maybe, that actually is an option to have it only for you for now as a tool to quickly check that kind of stuff and build a list along and introduce it globally at a later stage.

[christinaausley]

I like the Clippy idea 😁. Maybe, that actually is an option to have it only for you for now as a tool to quickly check that kind of stuff and build a list along and introduce it globally at a later stage.

This actually isn't a bad idea if I want to build it out before we use it more broadly. Could see how often it flags me as well to help determine the use we might get out of it!

[Langleu]

@christinaausley , I'll close the PR for now.
I'll approach you directly if I have something more speedy that makes sense to use as the current regex just isn't feasible.