-
Notifications
You must be signed in to change notification settings - Fork 27
Open
Description
Context
In #1614 we added a bunch of new guidance for writing cumulative documentation including applies_to
usage and placement. These guidelines are quite complicated. I think there are opportunities to build some automation and/or linting rules that could help us provide guidance in context at build time and reduce the amount of content docs contributors need to read and internalize.
Opportunities for automation / assertions
- Sort
applies_to
badges. This is already in progress:- Within a single key in
applies_to
, always order versions from newest to oldest (docs-builder#1726) - Across all keys in
applies_to
, always use the same order for keys (docs-builderUpdateapplies_to
Stack/Serverless/Deploy/Product render order #1727)
- Within a single key in
- Sort tabs with
applies_to
. This is dependent on Supportapplies_to
in additional directives/components #1436. - Render
applies_to
badge at the beginning of a list item regardless of where it is added in the source.- Note: I'm not sure if we actually want to do this or if we should just lint for badges that are not at the beginning of a list item and prompt the contributor to move the badge via a hint or warning.
- Render
applies_to
badge at the beginning of a paragraph regardless of where it is added in the source- Note: I'm not sure if we actually want to do this or if we should just lint for badges that are not at the beginning of a paragraph and prompt the contributor to move the badge via a hint or warning.
- Throw a warning on section applies_to in h1 (title)
- Use
applies_to
in the frontmatter instead
- Use
- Throw a warning on inline applies_to in h1 (title)
- Use
applies_to
in the frontmatter instead
- Use
- Throw a warning on inline applies_to in any h2+
- Use section
applies_to
instead
- Use section
I'll keep adding more as needed.
cc @theletterf (since we talked about this a bit)
Metadata
Metadata
Assignees
Labels
No labels