I will be very late today if I can even make it. But concerning the major topic of today, I would like to add one suggestion you can discuss if you want:
When people end up at a Fedora release Docs that is no longer supported, they will get the following warning on the top of the page:
E.g., here at F32 Docs
Complementary, I saw yesterday that pbokoc added the line include::{partialsdir}/unreviewed-message.adoc[] to several Quick Docs to indicate that they need review (he explained it in the readme).
Why do we not combine both?
Add an information to each page file that stores the last review (+revision if necessary) time/date (e.g., release-focused: reviewed(+revision) during F36). Commits don’t indicate much as they are often just formatting.
As soon as a page has no longer a review(+revision) at the current release, add a warning to the top of the page (like that above) to the reader: something like “warning, the last review of this page has happened at F34”. Then, the readers have the information and can indicate themselves if this is sufficient up to date or not. If contributors made a review/revision, they can then change the review/revision-release number in the respective adoc.
One major issue is that readers do not know what they are up against. Even if they are on a page that is still up to date, they cannot know, so they do not trust any page and stop to link/distribute it. The Docs have no value for them. All obsolete Docs contribute to the reputation of and trust in Docs.
With this approach, we can keep all our Docs, but the readers would be in a position where they know what they are up against. And this can be a foundation on which trust can rise. Trust + some valuable content might increase readership, and increased readership might bring authors+maintainers.
→ Authors come when they trust and use Docs. If they don’t do both, why should they come to author? Or why should they expect others to use/trust?
I had the idea when I was discussing with @pboy yesterday and after the use of a very old Quick Docs page in Ask.FP.
Something else what we have to overcome: mini-contributions → single sections are updated but nothing more, and updates don’t get aligned to the remaining. The outcome: the install guide jumps between many different releases and editions (as an example, this is why the Install Guide wants to create user accounts twice).
Hope that makes sense.