* Where should the documentation go? The most obvious solution is to put documentation here and migrate it to the Wiki when it's available. However, the Wiki collapses all leading and trailing spaces, which could make formatting a pain.
* What information should the documentation cover?
* How should the documentation be formatted?
* How do we handle subjects where we don't know what the documentation should be? Functions like CE_updateEndFrame are self-explanatory, but the rowmaps system has be mystified even after playing around with the debugger, and I don't think running to Unas for every enigma can practically work.
Going question by question...
I'd favor putting this as a section in the Wiki, circumventing the space stripping by making heavy use of bullet points.
I want the documentation to cover the purpose of each function and method, at a minimum. I'd also like the meaning of all function arguments, return values, and a brief overview of procedure, except for short functions.
If formatting does use the bullet points, I envision something like this:
Generic Module
Purpose: To do generic things.
Init: None.
First Function
- Purpose: Purpose of the function.
- Arguments
- Arg1: Gives generic information.
- Arg2: Gives other generic information.
- Procedure: Does generic stuff.
First Object
- Methods
- First Method
- Purpose: To be even more generic.
- Arguments: There's only one, but if there were two, they'd go onto the below line.
- First Method
And etcetera.
How to handle the more complicated subjects to document, I have no idea.
Any other thoughts?