Recommendation: Define the page hierarchy & standards

[DylanGTech]

On the old DokuWiki, I had suggested and did some work to define a structure we could build off of. Most wikis will use a page naming sheme. However, this works very poorly for a wiki that doubles as a manual. Instead, making full use of the flexibility a website provides to instead define a full directory (each page preferably having unique names as a constraint).

For the sake of creating a "waterfall", which will make finding things easy AND encouraging experienced readers to contribute, I suggest making this hierarchy in advance, with "todo" pages appear as default in each directory.

If it were me doing this alone, I would strive for the following principles:

• Make it as extendible as possible
• Decentralize it from any one architecture, firmware standard, or even language
• Have platform-specific things covered, but decoupled.

Here is the hierarchy I have devised implements all of these:

+ OSDev Wiki
├── Index [intro, about, featured]
├── + Tutorials
│   ├── + Setup
│   │   ├── Index [intro, overview]
│   │   ├── Host OS
│   │   ├── Language [comparing, contrasting language]
│   │   ├── Toolchain [includes IDE]
│   ├── + Booting
│   │   ├── Index [intro, overview]
│   │   ├── Uboot
│   │   ├── Stivale
│   │   ├── ...
│   │   └── + Bootloaderdev [not comprehensive]
│   │       ├── UEFI
│   │       ├── BIOS
│   │       └── ...
│   ├── + Memory
│   │   ├── Index [intro, overview]
│   │   ├── Paging
│   │   ├── Physical Memory Allocation
│   │   ├── Virtual Memory Allocation
│   │   └── ...
│   ├── + Graphics
│   │   ├── Framebuffer Rendering
│   │   ├── Rendering Text
│   │   └── ...
│   └── ...
└── + Reference
    ├── + x86
    │   ├── Operations (x86)
    │   ├── Exceptions (x86)
    │   └── Paging (x86)
    ├── + ARM
    │   ├── Operations (ARM)
    │   ├── Exceptions (ARM)
    │   └── Paging (ARM)
    └── ...

You'll there are tutorials which cover specific high-level concepts, but also a reference below. Each operation and exception could simply be a table with a brief description. Although the page could get very long if you wished to include ways to diagnose problems FAQ-style, so making that a subdirectory with the table in the index could be preferable. That may be too outside the scope however.

Meanwhile, a sample page in the tutorial section could look something like this:

+ thing
├── What "thing" is and why we have it (think paging)
├── How "thing" works and best practices (think memory management)
└── Implementing "thing"
    ├── Method A
    │   ├── In x86 (32-bit & 64-bit)
    │   └── In ARM (32-bit & 64-bit)
    ├── Method B
    │   ├── In x86 (32-bit & 64-bit)
    │   └── In ARM (32-bit & 64-bit)
    └── ...

In this layout, the topic is covered verbally, then a brief explanation for each major architecture is done below. We need not worry about writing the OS for them, but if there are code samples, we should do pick a single language (probably C++) that we default to, and just tell them if they use a different language, learn how to do that same thing in that other language.

Note my suggestion is just the base structure: Where we put each page and how we go about writing these as we go. It's good to know that early on so we can give people who want to help a place to start. I'd create each subdirectory and page, and just leave it completely blank for the time being.