I have a few comments on documentation in general, including some commentary on the Herculean job Ryan has been doing so far.
1: Consistency. There needs to be a format and guidelines for documentation. As a counter-example, look at the MPCNC and MP3DP project pages. I realize that they are in slightly different stages of development, but one is well formatted and laid out, the other is almost stream of consciousness by comparison. Again, not trying to knock Ryan, he’s doing a massive amount of work on his own, and I’m sure it gets overwhelming at times.
2: Duplication of Data. Don’t be afraid of it! But make sure you’re aware of when it happens, so you can change it consistently when needed. Nothing annoyed me more than dealing with IBM AS/400 manuals back in The Day™. They absolutely refused to print any useful piece of data more than once in a bookshelf-sized set of manuals. So it boiled down to at least two-thirds of the printed content was references to somewhere else (which was sometimes another reference). It’s not so bad with hypertext, since those references can be links, but if it makes sense to present the same information in different ways, do it.
3: Validity of Data. Link hygiene. Making sure that all your references are still valid. Absolutely sucky job, and one that I’m sure nobody likes. But I also know that nothing screams “abandoned project” like a page full of links to dead or missing sites, or references to out-of-date tools or techniques (e.g., a web design page that has a section devoted to the blink tag).
I’m sure these are reasonably obvious things, but they are also ripe for “everyone assumed someone would do it, so nobody did it”.
Also, this is not a offer to volunteer. Trust me, you don’t want me actually writing documentation, or in any sort of position of responsibility. To paraphrase the Dread Pirate Roberts: “Well done, good job, I’ll most likely ghost you in the morning.”