← Back to team overview

launchpad-dev team mailing list archive

Re: ruminations on bug modelling

 

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


References