Re: battle-plan for 2.5 development

[Graham Percival]

On 5-Nov-04, at 4:49 AM, Han-Wen Nienhuys wrote:
> WEBSITE
>
> 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
> community.

> For this reason, I think that lilypond.org 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 lilypond.org 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.

> COMMUNICATION
>
> 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.

> CLEANUPS
>
>     * 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.

> POST-3.0
>
> * 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 to-xml.ly 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)



DOCUMENTATION

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.


Cheers,
- Graham