Re: Plan for discussions

[Janek Warchoł]

On Fri, May 11, 2012 at 7:44 PM, Graham Percival
<address@hidden> wrote:
> However, I am opposed to any "official" (GOP or GLISS) proposals
> being decided at such a venue.

Decided, absolutely not.
Discussed, definitely.

> Similarly, we could have informal discussions about GOP or GLISS
> issues, to find out what the main concerns and options are.
> However, the result of that discussion would merely be a better
> introduction to the debate [...]

Not at all, in my opinion.
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, what
changes in the LilyPond design should we make to make LilyPond a more
efficient and easy to use tool.  Having 681 open issues in the tracker
doesn't mean virtually anything in this regard, at least in my
opinion.  These issues are mostly about specific bugs and/or specific
feature requests - but how everything should work together?
When i typeset music with Lily, i see some difficulties and/or
defficiencies all the time.  I don't even try to add feature requests
to the tracker, because it would result in a complete disorganized
mess.  I also know that i don't have enough experience to design
optimal and sound solutions for all the problems that i'm aware of -
e.g. syntax for special hairpins (the ones that have to be entered
with spacer rests now): i have an idea (it's a big idea, it would
affect general Lily syntax), but i don't know if it's a good idea and
whether it would work well with other Lily stuff and my other ideas.
I could start an e-mail thread (or perhaps a dozen of threads about
different related problems) about this, but it would get extremely
complicated.  On the other hand, face-to-face communication is way
faster: I suppose that if i talked for two days with several senior
developers, we could design a roadmap for Lily development that would
introduce new concepts in the right order and coherent manner.
So, a "conference" like this would enable us to ask good questions in
the first place :)  When we have a good set of questions with
reasonable solution proposals, mailing list discussion and decisions
would be more dramatically more efficient.

> I agree that email discussions can lead to additional
> misunderstandings, long latency, and can be frustrating, but they
> are the fairest way to conduct such business with our
> international team.  Even a simple IRC or skype chat is difficult
> to coordinate; it is virtually impossible schedule one for a dozen
> people, and we have more than a dozen people who will be
> interested in GOP and GLISS questions.

i know.

On Fri, May 11, 2012 at 8:17 PM, Graham Percival
<address@hidden> wrote:
> On Fri, May 11, 2012 at 01:57:08AM +0200, Janek Warchoł wrote:
>> 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).

> How exactly do you suggest to change them, and why?

I don't want to change GOP 6 decision.  I'm wondering whether there
are other communication guidelines we could have - to avoid troubles
in our communication.

> What were the problems with GOP?

there were no problems.  It just didn't tackle this.

>> Can we discuss bigger changes in syntax, too?  I mean, not just the
>> naming of commands (of course that's needed), but also the stuff that
>> is related to how things work inside Lily.  For example syntax for
>> overriding broken spanners, context-id-specific overrides, etc.
>
> 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?
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.

cheers,
Janek