Re: Plan for discussions

[Graham Percival]

On Sat, May 12, 2012 at 02:14:27PM +0200, Janek Warchoł wrote:
> I think it's about the big picture stuff and general design.  At the
> moment, i don't see any vision that we - The LilyPond Development Team
> - have about how the future of the project should look like,

oh, I definitely have a vision for that.

> what changes in the LilyPond design should we make to make
> LilyPond a more efficient and easy to use tool.

LilyPond itself will remain as a command-line "compiler".  So this
question can be split into two separate ones:
- what capabilities should alternate programs (i.e. frescobaldi)
  have?
- what should the input syntax be?

The latter question will be covered by GLISS.

> >> i suggest to discuss some communication guidelines, for example "don't
> >> say <It's settled then> until there's more than 1 day of discussion
> >> and not all concerns have been addressed, even if you think that the
> >> decision is obvious".
> >
> > I think last year's GOP communications guidelines were sufficient.
> 
> Hmm?  I recall only one decison: "Potentially sensitive or private
> matters will be referred to Graham." (GOP 6)  It's only partially
> applicable to the problems we sometimes have in our discussions (in my
> opinion).

I meant the general method of me announcing a discussion, waiting
a week, summarizing the discussion, waiting a week, then moving
forward.  For other things, there's the countdown process.

It sounds like you want to have something in between a normal
countdown and a GOP item.

> > The first run of GLISS will probably not involve any tweaks or
> > overrides, but we'll see how it goes.
> 
> What do you mean by tweaks and overrides?  The syntax of these
> commands itself, i.e. whether we should require #s or not?

Anything involving a \tweak or \override or \set or \with or
similar commands.

> I have an idea about syntax that would affect bot "regular" and
> "tweak" syntax, and it doesn't make much sense to discuss it in two
> parts because the logical connection would be lost.

Well, I'm trying to find some way of focusing discussion.  So
imagine that you want to typeset the simplest possible music that
it still reasonable -- say, a solo cello Bach suite.
Single-staff, (mostly) monophonic, (mostly) diatonic, etc.  Can we
finalize on input syntax to represent such pieces?

Maybe that's *too* focused, so consider a slightly harder version.
A Beethoven violin suite?  Thats violin + piano, but still pretty
simple as far as a semantic description of the music.  Can we
devise an input syntax that we can confidently agree to support
with no changes?  Maybe bump up the complexity by one more level
-- maybe a voice+piano work?  Mid-romantic?  Schubert, perhaps?

I suspect that this alone will take 6 months at least, but it
would still be a solid step forward, especially with respect to
other projects creating lilypond notation.  Once those changes
have stabilized and we have a break of a few weeks, we'll look
back at how the process worked for that goal, and plan the next
phase accordingly.

- Graham