> 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
