Implement alternative organisation

[s-makin]

This PR is an experimental alternative to the original organisation of the content. It is a working demo/proof of concept of a principle we could organise around.

Why is this needed?

• With only the MIR docs fully moved, the current split already feels unsatisfactory. There are disagreements over whether it should be in the Archive Admin vs. Development sub-section, and the content could feasibly belong in either. I have the same problem with the AA content. You are three navigation levels deep before you can find the specific section or topic you're looking for, and you have to already know where it is.

• In addition, there is no tutorial content, and hardly any reference material to be moved. The vast majority of content is either explanation or how-to, and having a Diataxis split for two categories feels like a missed opportunity in the navigation bar.

• In addition, MIR content for both reviewers and reporters sits side-by-side in the how-to section, which is a more confusing experience for our audience (this will become only more apparent as more docsets are added).

Proposed solution: Diatax-ish

The majority of the instructional content falls into two categories: those for the person reporting or submitting something (which I'm calling "contributor"), and those for the person with elevated privileges reviewing it (which I'm calling "maintainer).

These people are not set categories - you might be a contributor on one day, and a maintainer the next, depending on the task you're doing and which privileged group(s) you're a member of.

In addition, all of our users can be considered "developers at work", so the conceptual split of material should be more like "doing" and "understanding", where reference material can be either "doing" or "understanding":

• Doing = how-to + reference needed to do a task (e.g. templates and checklists)
• Understanding = explanation + reference needed to expand understanding (e.g. glossaries, process exceptions, list of error messages, etc)

In Diataxis terms, making these our axes gives us a more intuitive split of content:

Advantages

• In this paradigm, users can self-identify and find content that is just for them, according to whether they want to get something done, or understand how something works.

• It's now easier to find what you're looking for. Topics can be split on the second level instead of third or fourth.

• We don't face a pressure to "fill in the gaps" in the Diataxis split. The material is already largely written and equally distributed, and this system would make it easier to categorise the existing content in ways that will make sense to our end users.

• We can still use Diataxis! It is a powerful tool for conceptualising the docs you're writing. Splitting content by the Diataxis type makes sense to do - we just wouldn't be manifesting that explicitly to the user.

• The organisation makes intuitive sense: If the people building Ubuntu can work easily with the documentation, they can more easily keep it up to date and well maintained.

• We can now have both guides and explanations that are aimed at different audiences.

Weaknesses and future work

• The biggest weakness is that it's not "beginner friendly" as it has no specific tutorial space. However, this is a general weakness of the content we're bringing together as a whole. Solving that problem is out of scope for this cycle: but at least with this system, we can make the content more streamlined, navigable and discoverable.

  • Creating a proper "beginner's path" takes a lot of effort and careful thought
  • This must be done, but needs to be future work -- it should tie in strongly with both the Community Portal and the New Wiki.

[s-makin]

I have added the staging area back in and trimmed down the number of empty pages (the ones left are just indicators) to make adding the incoming content from the Packaging Guide and Archive Admin docs easier.