launchpad-dev team mailing list archive

[Jeroen Vermeulen <jtv@xxxxxxxxxxxxx>]

On 2011-09-20 12:02, Robert Collins wrote:

> I think the key difference isn't that its more data, its that its
> -workflow- - the process by which things enter the system, move
> through it, and get reported on and massaged - which needs to change.
Absolutely.  The reason why I brought up this alternative bug 
classification as food for thought is that the list of problems it 
solves makes it abundantly clear that we're forcing different parts of 
bug workflow into the same chair.  This is a pathology that tends not to 
become obvious in a pure workflow view, but all the more so in a 
separation-of-responsibilities view.
That's where the medical metaphor (symptom, diagnosis, treatment) can be 
useful, partly because it represents a well-evolved work breakdown for 
very similar problems to ours and partly because it is so widely 
understood.  We already borrow the term “triage” from this domain, I 
believe.
I believe many of the problems with bugs can be expressed better in the 
medical metaphor than in conventional bug-tracking terms, and surely 
that's an important step towards solving them.  It's immediately obvious 
that a symptom is something the user reports, for example.  Most people 
would think twice before contradicting a symptom; all you normally do is 
standardize the terminology and find out what is and isn't relevant. 
But software engineers routinely contradict bug reports because changing 
the report is conflated with diagnosis.
Other typical problems with bug reports are associating multiple sets of 
symptoms with one diagnosis (basically what we have both bugtasks and 
duplicates for, I think); premature diagnoses and solutions that 
developers have to reject, mixed in with perfectly valid symptom 
reports; rejecting diagnoses without rejecting symptoms; divergent 
notions of urgency between user (based on symptom) and engineer (based 
on symptom, user, and diagnosis); tracking treatment steps for a single 
diagnosis (where we often file “task” bugs); having a separate question 
tracker because the process for reporting a symptom is designed as a 
path towards a code fix; loaded terms like "invalid" and "won't fix" 
when diagnosis does not come up with a code problem or treatment isn't 
cost-effective; and changes in the choice of treatment for a given bug 
over time.

Jeroen