RE: GOP-PROP 8: issue priorities

[James Lowe]

Hello,

)-----Original Message-----
)From: address@hidden
)[mailto:address@hidden On
)Behalf Of Phil Holmes
)Sent: 02 August 2011 09:29
)To: Graham Percival; address@hidden
)Subject: Re: GOP-PROP 8: issue priorities
)
)----- Original Message -----
)From: "Graham Percival" <address@hidden>
)To: <address@hidden>
)Cc: "Phil Holmes" <address@hidden>
)Sent: Tuesday, August 02, 2011 6:22 AM
)Subject: GOP-PROP 8: issue priorities
)
)
)
)> We have over 600 open bugs or patches to review. At one point,
)> this number was in the low 60s. The task of maintaining lilypond –
)> let alone adding large new features – cannot be handled by the
)> current development team alone. We need to be more efficient in
)> how current developers work, and we need to make it easier and
)> more fun for new contributors. Something which makes it impossible
)> for somebody to contribute is therefore more important than any
)> graphical output problem (with the possible exception of
)> regressions).
)
)I wasn't around in the days of 60 bugs, but my guess for why there are so
)many more now is that it's partly due to putting almost every reported
)problem into the tracker, 

+1

) and partly due to increasing user base as well.

+0.25

I'd say that it was more because people like Mr O. Redchuk (and others) have 
been much more 'on the case' than has ever been before to spot tracker-fodder 
or add a tracker for Reitveld items that would in the past not have had any.

)>
)> Priority-high:
)>
)>    * any failure to build make or make doc which does not fall
)>      under the priority-critical definition.
)>    * anything which makes it difficult for serious contributors
)>      to help out (e.g. difficult to find the relevant source
)>      tree(s), confusing policies, problems with automatic
)>      indentation tools, etc).
)
)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.

I don't want to get all 'mission statementy' but isn't that the point that we 
all use LP, Good/beautiful output?

)I don't like
)that.  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.

+1

)>
)> Priority-postponed:
)>
)>    * No fix expected for at least two years.
)
)I don't actually see the point of this, given that I can find open high
)priority issues almost 5 years old.  Think we might as well drop it.
)

-1

No. I think it's good to keep issues 'postponed' than closed, even if they are 
old. Someone someday will come and look at this, as tastes change and 
developers have specific requirements or just a plain old challenge.

In the Bugzilla-driven world I sometimes work in we have a 'WONTFIX' statement 
which we use for enhancements that we never intend to implement or for issues 
that are not going to be fixed in the current release of our code but no longer 
exist as an issue in the newer code base (i.e. the feature is deprecated for 
good). That are the only two cases we ever drop issues (or if the issue 
suddenly goes away when someone revisits it after a number of iterations of the 
software).

If we just close/drop the tracker issue I assume it goes off the radar and so 
we lose it altogether which I don't think is a good idea.

The point of the tracker is not necessarily to get it to 0 (after all if we all 
sat down and thought hard we could come up with dozens if not hundreds of 
enhancements that are not bugs) but that doesn't detract from the project at 
all.

Maybe some people get despondent when they see a rise of 200% in 'open' tracker 
issues, not me I'd say a rising and falling (and rising again) tracker rate 
shows a *healthy* interest in a software project and a healthy development base.

James