[EMAIL PROTECTED] writes:
> I'd like information on volunteering for LilyPond as:
>
> Writer (Documentation of LilyPond)
[continuing private mail over the list]
I never have to consult the documentation, so I am probably not
qualified to write this. Therefore
Please help me, dear list
LilyPond is developed for the most part by Jan Nieuwenhuizen (now on
vacation), and me. We have 2 branches, the even-numbered `stable' ones
(1.0, 1.2), and the uneven numbered `unstable' ones (1.1, and
currently 1.3). This scheme was taken from the Linux kernel. However,
by stable we mean that the release is mostly bugfree, and that don't
do development on 1.2 , only on 1.3 (we're at version 1.3.73, with
new patchlevels coming out every week)
The documentation of Lily is available online as
http://www.cs.uu.nl/~hanwen/lilypond/Documentation/out-www/index.html.
Most of the files that are available are small (and relatively
unimportant, IMO).
The source of the documentation is written in TeXinfo, extended with
some constructs to mingle music notation with text. The documentation
is included with the LilyPond package, and all precompiled binaries
come with a copy of the complete documentation in postscript and HTML.
The big, important documentation files are
1 the glossary
2 the lilypond manual.
3 the mudela-book manual
the 1st is maintained (by Christian Mondrup), the 3rd is slightly out
of date, but I guess only the examples should be fixed (volunteers,
anyone?), and maybe it should be proofread by an outsider.
The reference manual is a large and documents how to write lilypond
input files. The organisation of the document is not very intuitive.
It is structured like the implementation of lily is (not very
helpful), but it starts with a short tutorial, which I think is
reasonably OK.
The reference manual should be organised differently (perhaps
task-oriented, eg. with chapters like "how to typeset polyphonic
music", "how to typeset orchestral scores and parts") and definitely
proofread by a non-developer.
Furthermore, I think that a section on the implementation of lily
should be added towards end, for advanced users, but I think that
writing that part is a job for Jan and me.
As I said before, lily is a moving target. That does make the advanced
aspects hard to document, because the advanced aspects change often,
but the newbie parts need revision most desparately.
Finally, I like working incrementally, so ideally, I'd like to see the
current manual slowly being changed into or moved to a new manual, in
such a way that everyone can witness the intermediate results, and
give feedback.
--
Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.cs.uu/~hanwen/
