Re: issue classification debate

[Ian Hulin]

Hi Graham,
Graham Percival wrote:
> I wanted to wait until GOP started, but it seems there's a lot of
> interest in this now.  Here's my proposed new classifications for
> issues.
>
> There are four hopefully-not-really-contradictory goals, listed in order:
> 1.  easy for core developers to find the type of bug they want to work on
> 2.  easy for new developers to find the type of bug they want to work on.
> 3.  easy for non-technical, non-musically-literate, inexperienced Bug
> Meisters to add+classify items[*].
> 4.  understandable by normal users who haven't read the issue tag
> descriptions in the CG.
>
> [*] This isn't an insult directed at our current Bug Meisters; it's
> just my observation that we cannot afford to require that the bug
> meister know anything about lilypond programming, or even be an expert
> lilypond user.  We don't have enough volunteers to be that picky.  But
> that's ok; remember, I did a great job (if I may say so myself)
> despite not having a clue how vocal music worked, either in printed
> music or in lilypond.
>
>
> %% for Type, we match the first relevant item on the list.
> Type-collision: keep
> Type-defect: keep.  However, this will now include all defects, not
> just "minor code changes".  (see below)
> Type-documentation: keep
> Type-build: new type, but I think it's worth it.  Used for GUB,
> makefiles, stepmake, and python scripts which are used in the build
> system.
Just a thought, use two new types:
Type-kit-generation: for GUB and other things that generate the build
Type-build: for the build files themselves that actually compile and 
install Lily on a particular platform.  E.g. you could classify a bug 
using this type to get an emergency patch out so Lily will build on a 
specific platform, and then handle any GUB changes under a 
kit-generation issue so you and Jan could spend a bit more time getting 
GUB to produce the right thing.
> Type-scripts: convert-ly, lilypond-book, etc.
> Type-enhancement: keep.  However, this will now only be for "new
> features", not "large code fixes".  (see below)
> Type-other: keep
>
> Defect vs. Enhancement: historically, the idea was that a fix which
> required a large amount of new code would be an enhancement.  For
> example, if two grobs were colliding but it would require a new piece
> of architecture to detect the collision, this would be classified as
> an enhancement.
>
> I've had any number of debates / clarifications about this over the
> years, and I'm sick of it.  I'd like to say that an enhancement would
> be a new user-visible feature (such as the baroque tablature stuff),
> while anything that fixed the expected behaviour would be a collision
> or defect.
>
> This proposal might violate goal #1 (be convenient for core
> developers).  I'm willing to drop this proposal if they speak out
> against it, but I'd really like this to go through, since nobody else
> understands the current distinction.
Which side of the line does *user-perceived* missing functionality go? 
In the sense of it's something Lilypond hasn't done yet, but users 
coming to Lilypond with experience of other music-setting software feel 
is really lacking.  E.g. former Igor user reporting midi-playback not 
observing dynamic and tempo changes and repeats. The user may feel this 
is a defect, developers may take the view it's an enhancement request.
We need a decision here, not a debate.  My feeling would be log it as an 
enhancement request, but make sure you record that the original reporter 
considers it a defect.
> %% for now, only Critical will block a stable release.  In the future,
> it would be nice
> %% to consider High as also release-blocking, but that's not on the cards yet.
> Priority-Critical: segfaults, or a regression within the last two
> stable versions (right now, against 2.10.33)    anything currently
> ranked as High would become Critical.
> Priority-High: this is Werner's "really annoying" idea.
> Priority-Medium: keep.  Also, any regression later against a version
> less than 2.10.33 will become a medium item (unless the output is
> sufficiently bad to qualify it as High).
> Priority-Low: keep
> Priority-Postponed: keep
>
> At the moment I have no ideas as to how to assign any priority below
> High.  If anybody could propose guidelines that inexperienced,
> non-musically-literate Bug Meisters could follow, that would be great.
>  The best I can think of is to say "try to have 20% postponed, 40%
> low, 30% medium, and 10% high" and let them try to do relative
> rankings.
>
>
> %% Opsys: no change
>
> %% Tags
> Regression: new tag, taking over the old Priority-Regression.  As stated above,
>    very old regressions no longer get release-blocking priority.
> bounty, maintability, patch, frog, performance, security: keep
> Warning: renamed from "warning-nitpick" due to the way google deals with tags.
>     I'm going to add a link to "label:warning" from the CG, since these are
>     AFAIK easy things for Frogs to work on.
Does this cover things like the compilation squawks we see currently in 
the C++ files: warning converting int64 -> int may change a value, and 
suchlike?
> Remove engraving and usability: these now get wrapped into the normal
> issue type and priorities.
>
>
> Cheers,
> - Graham