On Fri, May 11, 2012 at 7:44 PM, Graham Percival <gra...@percival-music.ca> 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 <gra...@percival-music.ca> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel