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
_______________________________________________ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel