I've been looking at the wiki and am hampered by my ignorance of how to do things on a wiki. As a technical writer, I would like to suggest that you need to start with a menu, which is effectively your plan, and then fill in the information under the headings later. You can always change it on the fly but it is best to have an overall agreement of your starting position and an overall plan.
I have suggested to Mitchell that you need three tiers in the wiki:
* Simple summary information
* Simple detailed information
* Theoretical or philosophical information.
Structure and pitch are critical to accessibility so need to be determined up front.
In the structure I am suggesting above, the detailed and intimidating information is kept hidden one or two steps back from the main page but should be easily found by those who want it. These are three different levels of user materials designed to help the user come to grips with the system according to their own level of interest. We need to determine what goes at each level and provide the TOC headings.
As far as pitch is concerned you have to define your readership. I would suggest that the first two could be pitched to a general readership so kept simple, concise, practical and friendly. The voice for the first two is active voice so that it talks directly to the reader, eg, "You can vote by...". and not "voting can be achieved by,,,". The third can be more academic.
Note that these are different from both marketing materials and technical documentation.
Let me know - do you want my involvement?
I initially volunteered to write case studies, but I cannot do that until I know much much more about the system, and the best way to get to know it is to write or edit the documentation on it.