Yeah, we've had the same discussion before - so we're all aware of this, i.e. your point is well taken, and you made the exact same point previously in another topic...
In general, it would be good to have more, and especially better, documentation - in practice however, you are already stating why nobody is volunteering their time and expertise to help improve/create the corresponding documentation: because people want to get their own projects done.
Thus, without meaning to offend you, may I suggest that you simply take one step back and look at the situation as it really is ?
Really, nobody around here disagrees with your key message - but just like you, we're also just people interested in certain aspects of FlightGear, which usually means that we are not even the slightest bit interest in somebody's pet project - especially not if that doesn't translate into tangible results that flow back into the main project.
It goes without saying that unfinished and outdated wiki articles and unfortunate, and that also applies to articles consisting primarily of quotes.
Then again, I don't see anything suggesting that you are actually in a position to tell what entails good documentation and what should be "removed" - like I said earlier, I had the same discussion with Thorsten, and it was frustrating for both of us, for different reasons. I knew for a fact that I was providing exactly the answers to the question he posed, but it took him quite some time to follow up with some of the feedback I provided - it was only later on that he admitted that his priorities were very different, too - and that he also wasn't interested in helping clean up the wiki or re-write certain documentation.
Once you look up Thorsten's recent posting history, you will see that there is a handful of postings where he's specifically following up on advice that was previously provided here.
In addition, the wiki is maintained in a fashion not unlike to open source code: it evolves over time - e.g. some of the most useful articles mentioned by various contributors are the "Canvas Snippets" and "Canvas Reference" sections - yet, I ended up creating those specifically in response to certain discussions on the forum, and after tinkering with different forms of articles long before that.
Personally, I consider myself fairly familiar with the Nasal side of the Canvas system, and looking at your recent postings, I could have certainly posted answers to most of them (if not even all) - however, it's also a matter of spare time. And quite frankly, I also don't see anything suggesting that you actually looked at the underlying files - which is however something that Thorsten obviously started doing recently.
Please don't get me wrong, I am really not complaining at all - we all have real lives, day jobs and our own little pet projects - but even if you never look at the wiki, there is tons of good material in $FG_ROOT/Nasal. But you always need to keep in mind that it is unreasonable to just work through a few tutorials and understand all these concepts - people with a certain programming background will find it much easier to use Nasal and Canvas than people just starting out, which ironically is why the "Canvas Snippets" article is so appealing to folks who have no clue about programming or who are not that familiar with FG internals.
However, overall, the situation isn't that bad compared to other Nasal-space APIs and especially other subsystems in FlightGear.
Obviously, what is there can, and should be, improved - I would however appreciate it if you could start new articles (or new navbars) instead of outright deleting stuff that you may not yet fully understand - this is something that I also politely asked Thorsten to take into consideration before going crazy to delete everything that looks like gibberish to people less familiar with the whole thing.
Again, people with a strong background in JavaScript (functional programming, closures, OOP) don't seem to have much of a problem using the Canvas system, even just by referring to $FG_ROOT/Nasal/canvas/*.nas
However, if you are entirely new to some of the more advanced programming concepts the Canvas/Nasal bindings are using, it is certainly a bit far-fetched to directly use the whole shebang.
Besides, I have personally come to the conclusion that the way we're using the Canvas system, and especially its Nasal bindings, is hugely problematic, and that has little to do with the existing documentation - as a matter of fact, we would not be facing this dilemma if the documentation would be much worse or non-existing.
Nasal and Canvas are far too accessible at this point, and everybody and their dog is creating rendering related stuff that runs in the FlightGear main loop without people understanding the ramifications of coding that way, which is one of the reasons why I have stopped adding much to the docs, because I am firmly convinced that we need to fix/address some core level issues first; lest, the Canvas system is sooner or later going to become at least as problematic as the Nasal subsystem in FlightGear - which is not due to its inherent design, but due to the enormous flexibility it provides.
I've been trying to summarize the main issues in the wiki, feel free to take a look:
http://wiki.flightgear.org/Canvas_Devel ... FlightGearFinally, I really haven't been following the project much recently - but my general advice in these kinds of threads is usually that people should strive to be, and to embody, the change the want to see. In other words, feel free to fork whatever articles/templates you deem appropriate to compete with the status quo - if you manage to come up with something better, it will certainly be adopted sooner or later, that's the way open source works after all.
If however you end up arriving at the conclusion that your own little projects are more important than fixing the status quo WRT the wiki or the Canvas docs there, you can officially consider yourself to be part of the problem, and not part of the solution - which is to say, welcome to the club of people who are more interested in their own little pet projects than helping the project as a whole (in other words, things are certainly not as bad as some people make them sound).