Just to close the loop on this:
* $FG_ROOT/Docs is still a good source for definitive information. Certainly I try to keep it up to date with the areas I work on. It has the big advantage of being versioned and (usually) in sync with the specific code changes. For example for scenery work it forms the "contract" as Rick likes to put it, between OSM2city and the FG core.
* Somewhat to my surprise, for the Hackathon no-one needed any help building FG or using git. download_and_compile script helped a lot here. So there was no need to write/collate additional wiki articles. During the event itself we didn't find a lack of documentation a problem.
Finally, to address the way in which this has gone off-topic somewhat: Documentation doesn't fix bugs or somehow provide the keys to creating new features. Outside of trivial cases, better documentation would not address the vast majority of cases raised on the bug tracker, and as Thorsten has pointed out above, the effort in writing that documentation is out of proportion to the benefit.
In most bugs I investigate I have to grep the codebase and do exactly the same analysis that someone with no knowledge of FlightGear has to do. I have the advantage of having the codebase already downloaded and in some cases memory of what the code looks like, and the confidence that I'll be able to work it out. None of this is rocket science or some magic that only James or myself possess, and is faster to pick up than people think.
A good example of this was in the Hackathon where one of the participants went from zero knowledge to creating trees in WS3.0 over the course of the weekend. That particular piece of rendering code is pretty complex, touches a whole host of different areas and required them to ramp up not only on how the existing scenery works but also the new WS3.0 scenery.
So don't wait for better core code documentation on the wiki: it isn't going to happen and isn't going to help. Get stuck in.
-Stuart