Folder-level front matter attributes

[florent-leborgne]

Opening a discussion regarding the possible use of folder-level attributes for front matter defaults.

What it solves:

• Eases contributions, especially when creating new docs pages. Contributors can focus on the content.
• Strengthens consistency. Let's take the example of Product Availability. We have doc sets where the vast majority of pages will have the exact same set of values for this attribute. Having a default that is centrally managed at a higher level (for example for all pages under /explore-and-analyze/) will prevent discrepancies, misses, overflowing attributes.
• Saves maintenance time. If something changes, there's one place to update, or many less places, at least.

How it'd work:

• A small conf file at the folder level OR a mechanism to make subpages inherit some attributes of their parent .md page by default.
• Specifying the attribute on a page would override the inherited default. Any subpage would inherit the value specified in its closest parent page.

This has been a very handy feature for me in the past on other SSGs. Sure, much like partials/includes/transclusion/call-it-how-you-like, it can make the system slightly more complex by moving some content outside of the .md file itself, but the more files one manages, the more convenient such feature becomes.

Some examples for reference:

• https://jekyllrb.com/docs/configuration/front-matter-defaults/
• https://gohugo.io/content-management/front-matter/#cascade

[lcawl]

Per chats with @jmikell821 this might be useful for large reference sets like the security prebuilt rules (https://github.com/elastic/security-docs/tree/main/docs/reference/prebuilt-rules).

As shown in https://www.elastic.co/guide/en/security/current/prebuilt-rules-downloadable-updates.html, the number of rules that are updated in association with a particular release can vary from 6 to 1000+. So being able to update the frontmatter just for that specific group (defined at docset-, toc-, or folder-level) might be quite handy.

On the other hand, the prebuilt rules also seem to have their own versioning scheme (e.g.
https://github.com/elastic/security-docs/blob/main/docs/reference/prebuilt-rules/a-scheduled-task-was-created.md is version 110, https://github.com/elastic/security-docs/blob/main/docs/reference/prebuilt-rules/adminsdholder-sdprop-exclusion-added.md is version 213). So if we end up publishing the rules and their updates similar to logstash versioned plugins (e.g. https://www.elastic.co/guide/en/logstash-versioned-plugins/current/input-eventlog-index.html) and in particular if we end up putting that version detail in the product facet of the applies_to metadata (though that's not currently supported since it doesn't follow the V.R.M pattern), then I think we have to rely on having the exact right info in each page. #211 is likely also relevant, though I don't know the exact strategy that will be used for versioning those plugins.