launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Sun, Aug 28, 2011 at 9:29 PM, Jeroen Vermeulen <jtv@xxxxxxxxxxxxx> wrote:
> You may be interested in Kirit Sælensminde's work on bug classification,
> which I summarize (not too well, probably) here:
>
> http://pqxx.org/development/libpqxx/wiki/AllSoftwareIsBroken
>
> It's probably too radical to switch to, but I did find it insightful.
> Personally I liked it so much, even if Kirit admits it needs more work, that
> I implemented it in my own bug trackers and converted all outstanding bugs.
>  It's not a complete classification, but I noticed some very real
> advantages:

I've seen that before I think, perhaps you mentioned it on IRC? I
think thats a good categorisation for user impact. It would be
interesting to have an (optional) field for that for user problem
reports. I don't know if the complexity is worth it : will most users
know enough to categorise it well? If many or most won't, perhaps
we're better offer assessing this ourselves?

>  * Report the problem, not the task.
>
> This is a classification from the user's perspective.  It minimizes
> implications for or assumptions about how the problem should be fixed.

I think a user that 'gets' the model will file reports like that, but
if they are still called bugs/tasks, many users would still tend to
include imperatives :) A challenge for us is to set things up such
that a new problem reporter is guided to tell us the right stuff.

>  * The top priority is built in.
>
> One classification is "fails to communicate failure."  This isn't the same
> as the failure itself; it's something that probably needs urgent fixing in
> itself even if the failure per se is not a priority.

I don't know if that top priority is a universal; certainly for LP it
is true that failure to communicate a problem (to us) is of the utmost
importance, but I can imagine situations where getting good failure
communication is extremely hard and of diminishing returns vs fixing
some set of known issues.

I'm glad we seem to be thinking in similar broad terms, I'm sure there
is room for a tonne of experimentation in this area. I wonder if we
can find some way to experiment without messing up folk's experience
of LP while we learn more about this.

-Rob