[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: battle-plan for 2.5 development

From: Graham Percival
Subject: Re: battle-plan for 2.5 development
Date: Mon, 08 Nov 2004 19:04:25 -0800

On 5-Nov-04, at 4:49 AM, Han-Wen Nienhuys wrote:

The current website is a lot better than we had; I'm glad it has some
interesting articles, and that it refreshes a lot (basically, for
every Lilypond release), but it could be much more the center of a

For this reason, I think that should become a database
driven website, where users can log-in, post comments, contribute
articles and give the development team instant feedback on releases,
documentation, etc.

What's wrong with the mailing lists?  They provide instant feedback
on releases, documentation, comments, etc.  If somebody wants to
commit and article but doesn't want to code the HTML himself (and
doesn't want to use an editor -> HTML creator like OpenOffice), then
I'll volunteer to edit their plaintext article into HTML.

Changing into a more dynamic format seems like it
would involve a lot of work with small payback.  Now, if somebody
_wants_ to do all that work, of course I'm not going to disagree
with it.  But I'm not certain if it's actually worth it.


The development team should be present at the 2005 Linux Audio
Developers Meeting (april 2005) in Karlsruhe. This requires writing a
paper, which I plan to do myself. Nevertheless, interested writers are
welcome to contact me, should they wish to attend as well. For
example, it would be interesting to have a case-study of "advanced"
LilyPond use.

I can't attend, but I'm available for any writing / editing if you want.


    * Cleaning out input/test/

Doing what with them?  Integrating the interesting tweaks into
the manual, or a separate page of interesting tweaks?  Or simply
getting rid of uninteresting tweaks in input/test ?

I could have a look at this part.


* Right now, there are a bunch of programs that try to export (and
  even: import) .ly files. This is rather impractical for a number of
  reasons. It would be much better if we could read and write .ly
  files in XML (or similar format). This should be thought of along
  the lines of the example file.

* Interoperation can take other forms. Most notably, there is
  MusicXML. We have received multiple requests to support MusicXML,
  both as import and export format. Personally, I am a bit skeptical
  of this feature, as I haven't heard many actual LilyPond users ask
  for them. Until further notice, I classify this feature as a "will
  gladly implement this in exchange for money."

IMHO, if we're going to implement import/export in some kind of XML
format, we might as well do it in MusicXML, rather than inventing
our own XML format.  (note that I have no knowledge of the details
of MusicXML)


I propose that we make a distinction between reference documentation
(for skilled users who want to look up something they've forgotten) and
new users documentation.  If other people agree to this, then I'll focus
on improving / adding to the new users documentation.  The new users
documentation would be written in a chattier, less formal style.

I'm planning on the following steps:

1)  Make sure everything in the new users section is included in the
reference docs
2) Separate the current tutorial into a "basic tutorial", "instrument-specific
tutorial", and "advanced tutorial".  Add sections as appropriate.
3) Check the overall organization of the reference manual / lilypond-book
manual / etc.
4)  Respond to questions / complaints / comments about the docs; mainly
being a user-friendly interface to contributing to the docs. (ie user says "shouldn't section foo contain a warning about bar"; I'll add the warning. Or a different user says "I don't understand how to foo", and Mats replies with a great explanation of foo-ing; I'll take that explanation, add whatever texinfo
tags it needs, and include it in the relevant section)

Any new material and reorganizations would occur in Dec and Jan.

- Graham

reply via email to

[Prev in Thread] Current Thread [Next in Thread]