> > > Need it always be so? Or can we get a little organized and greatly > > > improve the situation? My own opinion is that the community can do > this > > > with a little organization and motivation. Someone well-repsected and > > > experienced in documenting (e.g. Dave) could head the organization, > and > > > the publishing carrot would provide just enough motivation for many > > > people. Without the publishing carrot I think we would still benefit > > > from a little organization. > > > > Before anyone starts writing new documentation, what is most desperately > > needed is for someone to remove all the bad documentation out there (for > > example most of the ALSA wiki dealing with .asoundrc files and dmix) > > Yes, absolutely. Seems to me that what could solve both the issue of consolidation and of duplicate, mostly outdated documentation is generating a central website that provides one Wiki page for every pertinent topic, whether that be a specific software, system setup topic (i.e. ALSA), and/or distribution-specific how-to. The end-users and/or project devs/contributors could help generate the material, while Dave would assist in its shaping, so that it is translated into a well-structured learning resource and subsequently book-friendly format. Eventually, Dave could sum all this up into a book and everyone's happy ;-). If this proves to be something the LA community wishes to pursue, Linuxaudio.org could help foot the space. Just like the new home for LAD (lad.linuxaudio.org), we could have the aforementioned Wikis populated within the same domain (i.e. documentation.linuxaudio.org/pd, doc.linuxaudio.org/muse, doc.ardour.linuxaudio.org, or something along those lines), utilizing similar formatting, and therefore generating a kind of a reliable, uniform, and familiar interface for users, regardless of the topic they wish to pursue. FWIW, I am looking to do exactly this with one of my ongoing projects, simply because the scope of the project I am engaged in encourages feedback from as many artists as possible. Considering that anything associated with technology is an elusive target, books covering such topics are practically outdated as soon as they hit the shelves. Hence, the aforementioned approach IMHO may soon become the only reliable option if the author(s) wishes to generate content that is more time-resistant. This kind of an approach could also help speed-up publishing of subsequent editions--Dave could simply recompile project summaries from the aforementioned Wikis once per year and, publisher willing, release a new edition of the book for those who prefer to have documentation in a paper form (i.e. for teaching and/or reference purposes). Best wishes, Ico
