Try restructuring the documentation content hierarchy

[StevenMaude]

As suggested by @CLStables.

[StevenMaude]

A constraint: the ehrQL documentation is currently a self-contained part of the documentation. This is due to the way it is integrated here as a separate repository (from the ehrQL repository) and included in this documentation's build. We can change the structure of the ehrQL documentation under that, but it currently gets included as one "block".

A consideration: if we move things around, we should avoid irritating existing users of the documentation where possible (and perhaps get feedback from current users, before rolling out those changes).

[StevenMaude]

An idea I had was trying to break out the documentation into the different components that have roles in OpenSAFELY. These are ordered roughly in an order that an OpenSAFELY user might reasonably encounter them:

• user support, including co-piloting
• GitHub
• data sources
• OpenSAFELY CLI
• project.yaml pipeline
• cohort-extractor
• ehrQL
• codelists/OpenCodelists
• reusable actions
• OpenSAFELY Jobs
• data output release and information governance
• OpenSAFELY Reports

One approach might be to separating out based on that, perhaps something like the current ehrQL structure. I'm not sure how good a fit this would be. It would have an advantage of making it possible, in principle, to pull out sections of documentation and move them to where the appropriate code is, should that be desirable. (It may not though! This is just what we did for ehrQL, whose documentation is particularly tightly integrated with the source code.)

Another approach would be to trying to follow more of a user journey through particular tasks, I think.

In any case, the current structure certainly feels like a bit too much of a mix of different concerns under single top-level parent headings.