Structure of Trails Project Site
We have three larger sections: User's Guide, Development notes and Community. All user-visible pages should be organized under these pages. In addition, we also have the Unity layout snippets that are combined together to form the Codehaus project site. Please don't make major edits to those without discussing it upfront. Finally, we have Archived section containing pages we don't necessarily want to get rid of (such as the logo contest) but that are not relevant for typical users anymore. Also note the Trails site that users see at http://trails.codehaus.org/ is a mix of Maven site content and Wiki content. The general rule is that first, avoid duplication, and second, all automatically generated reports or slowly changing, more generic project metadata (such as mailing lists should come from from the Maven site, everything else in the Wiki (guides, instructions, how-to's etc).
Editing Trails Wiki
A wiki, even more than any on-going publication system, needs continuous maintenance to make the information coherent, high-quality and easily available. In the information age, the problem isn't really that there isn't information, but that it is scattered, old, low-quality and/or hard to find. Therefore, while anybody is more than welcome to contribute to the documentation, I (currently Kalle) will reserve the right to to modify and re-organize the content as I see fit. Earlier, we used to have more of a "article" type of Wiki where people posted longer write-ups, signing them using their own names. The problem with it is that people tend to avoid changing it to honor their copyright. The principle is nice and often even desired, but in a Wiki it hinders collaborative efforts leading to continuous improvement, just the same way as when writing code. Open source projects have often decided not to @Author tags in the code for this reason and following the same logic I (Kalle again) have removed most of these early articles and references to their authors.
However, some times an article format is better suited to subjective opionions that reflect the current state of things. The Community section is partially for this purpse. It's less maintained and as the name suggests, meant as community-driven part of the wiki.