The plan is the (preliminary) result of a discussion by the Fedora docs team.
Analysis of the current state
The current Fedora documentation is generally viewed with some unease. An analysis comes to the following theses:
Looking through our existing documentation, the shortcoming is not so much in the individual texts, but the shortcoming is the curation of the documentation. We have good content (although in parts not up to date), but it’s not necessarily arranged in a way where it’s easy to find.
The basic problem is that the layout of the documentation pretends there is a unified Fedora, organized by releases. But in fact, Fedora is primarily structured by editions, even if they are built on a common base.
This is particularly evident in the Installation Guide and the Administrator's Guide. The editions differ in such a way that neither an across-the-board installation guide nor such an administrator's guide is possible. As an example, both Workstation and Server use Anaconda but in such a different way that doesn't fit into one guide.
Particularly the two aforementioned guides are very comprehensive and monolithic. Such a structure is difficult and time-consuming to maintain.
Apart from those issues, very many articles or parts of articles are well suited and meaningful. Some need to be updated, but very rarely discarded completely. However, there are a lot of gaps that are waiting to be filled.
Basic principles of an adapted composition
Abandon structuring by releases and replace it by Editions / spins (or variants).
The central entry point continues to be a particularly emphazised Fedora Linux "box" (without release identifier) that explains the structure, refers to edition-specific documentation for installation and administration, includes the current and previous release notes, and provides an overview of where to find what.
The largest part of the site is taken up by direct access to the documentation of the editions and spins.
In addition to their specific documentation, there is a documentation of common issues and topics or generic tools with a clear structure:
a. Tools cross-reference (focus explanation of principles, .e.g. dnf, rpm, Anaconda )
b. Quick Docs (focus how-to resolve specific common tasks and issues, e.g. network conection)
Comprehensive documentation (Tools reference) is created in such a way that parts can be included by edition documentation (to avoid duplications, but to facilitate the reading flow) or can be selectivly linked to.
Implementation of the plan
Most editions already have documentation on installation and administration and can take over this function immediately without much extra work. Some minor refinements and adjustments may be desirable to achieve a coordinated approach, vocabulary, and typographic style.
Problematic are Workstation and Cloud, which, to the best of our current knowledge, have not created their own documentation. A temporary solution could be found for Workstation. In the case of Cloud, provisional reference could be made to old documentation (ca. 2016). Alternatively, the edition / spin would have to be dropped, at least initially.
Keep with the current design as much as possible or minor adjustments.
(re)use as much of the existing text body as possible to keep the workload within limits.
Break monolithic text into smaller, self-contained articles.
Break down the changes into small enough steps to allow rapid publication of changes and avoid long “latency” periods.
Proof of Concept
A PoC implementation (mockup) is using the example of the introductory "Fedora Linux" tile and a tile „Fedora Administration Tools Reference“ with Anaconda.
It is available at:
Publication of further smaller individual parts at approximately every two months
Hi @pboy !
As you must already know, I'm working on the docs website redesign during my Outreachy Internship with Fedora.
I'm really excited about your pans for improving the user documentation content. I guess this would be helpful for me too, since I have to understand and for an Information Architecture for the site that would work well for anyone using the Docs website.
I think over time, Quick Docs grew organically as well, and lost the purpose it was made for?
To understand better from our users pov, I wanted to conduct a research as well- basically to understand how they interact with the website, what do they think it is, and whether the content is digestable.
If you could help me with any questions/suggestions with the survey, that'd be super useful!
Also, I was working on creating an information architecture for Quick Docs. Right now, I just want to categorize all the articles in certain groups so that I could make some sense of them and get started. I hope to extend the same for other parts of the Docs website!
Here's a link to the sheet I've maintained so far- https://docs.google.com/spreadsheets/d/1fqpzoPRC2ID0JuaeO05fiyj5i9ljzyOJQkOB5L0gdeA/edit#gid=1612736749
to comment on this ticket.