Re: GOP-PROP 8: issue priorities

[Jan Warchoł]

2011/8/2 Graham Percival <address@hidden>:
> There is a long history of "good programs never crash".  I think
> we should take part in that.

+1

> Improvements to our development process won't be finished until
> the end 2011; I think it's irresponsible to actively recruit
> people until then.

Do you mean that we should wait until GLISS ends?

2011/8/2 Graham Percival <address@hidden>:
> Something which makes it impossible
> for somebody to contribute is therefore more important than any
> graphical output problem (with the possible exception of
> regressions).
> [...]
> Priority-medium:
>    * highest level for graphical output problems

I don't agree.
I agree that issues making contributions impossible should be critical
and are perhaps the most important things.  But I cannot agree that
"maintainability" issues are more important then graphical output
problems, to the extent of restricting graphical output problems to
medium and low priority!


2011/8/2 Phil Holmes <address@hidden>:
> So any bug in Lily that produces bad output can never be High?  Or - to put
> it another way, we, the developers ,only regard bugs as high when they
> hinder us, not when they make you, the user's life difficult.  I don't like
> that.

+1

> I remain of the view that the words "An issue which produces output
> which does not accurately reflect the input (e.g. where the user would
> expect an accidental, but none is shown) or which produces aesthetically
> poor output in a situation which could be expected to crop up frequently in
> real-world music. It should not be used where the problem can be avoided
> with a simple workaround." make a good definition of high.

I think it's too vague.  I'd rather say "a noticeable problem with
basic notation, except very weird or rare examples with easy
workarounds", where basic notation is defined as follows:
single-staff, single-voice music consisting of:
- notes ( = noteheads, stems, flags, beams)
- rests
- accidentals
- ties
- augmentation dots

We may wish to add dynamics, slurs and tuplets to this list, but i'm
not sure about that.

http://code.google.com/p/lilypond/issues/detail?id=1301 is an example
of an issue that in my opinion doesn't meet above criteria (clef
change is not basic notation, an it doesn't look frequently-appearing)
and therefore shouldn't be high.


2011/8/2 Keith OHara <address@hidden>:
> I suggest that "Postponed" can mean "we're not quite sure what a proper fix
> would look like, yet".  Then we know to give this issue a different kind of
> attention, like looking in the textbooks, before we start coding.  Issues 39
> and 621 had some dead-end programming that might have been avoided (although
> dead-end programming as part of a hobby is not the end of the world).

No, i'd give a label for that.  We shouldn't mix different types of
information in priority field imo.


2011/8/2 Phil Holmes <address@hidden>:
> Another issue to tackle is how we use the priorities. We know that critical
> will focus developer's minds.  But there's no drive to use the other
> priorities.  I know that many devs work partly to make lilypond more to
> their taste, but also for general good.  Perhaps we could agree that, say, a
> list of 10 high priorities is the current target list, and that anyone who
> wnats to contribute should/can look at fixing them as part of their
> contribution?

I don't think so.  Take my example: i do mostly mid-low priority
issues, often ones that i found myself.  That's because i don't have
skills to attack important issues with a reasonable change of success
without wasting too much time.  I don't want to spend 5 hours banging
my head on the wall trying to fix a critical issue that can be solved
by Mike/Carl/HanWen/someone else in 30 minutes; i prefer to spend
these 5 hours working on something that i understand and it interests
me.  Finally i'll learn enough to attack criticals on my own.
However, i may be wrong.


2011/8/2 James Lowe <address@hidden>:
> )So any bug in Lily that produces bad output can never be High?  Or - to put
> )it another way, we, the developers ,only regard bugs as high when they
> )hinder us, not when they make you, the user's life difficult.
>
> and here is the rub (for me anyway) - a good example is slurs
> over line breaks. It's a hard problem (so it seems) to solve,
> but it produces (in some cases - all in my own personal
> experience) dreadful looking output. While not obviously critical,
> it should be High. Even if it is hard to solve.

There was a time i thought they should be critical, but that's perhaps too much.


2011/8/4 Graham Percival <address@hidden>:
> Another thought: we could look at filling the patch countdown in
> order of priority (plus some amount of discretionary judgement if
> a patch has been waiting for a long time).

I'm not sure if i like it.  I usually work on issues that have low
priority (as explained above) and every patch takes me quite a long
time (i don't remember having any non-trivial patch pushed in less
than a week, and usually it's longer).  I noticed that when i have too
many issues open (including Frog's issues which i 'supervise' and
upload to Rietveld), i'm getting confused; i cannot remember what's
going on where (because discussions last for a long time) and so on.
Therefore i have to wait until some issues are closed - currently i'm
not doing anything because i don't want more mess in my mind :)

cheers,
Janek