launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

I should probably blog this, but time is short and I wanted to get it
out there. I'm also going to be a little brief and not dig up all the
citations needed :) - if this survives and we want wider exposure then
a blog post with citations etc can happen.

We've had some requests (recently and historically) for more metadata in bugs:
 - how to reproduce
 - how to workaround
 - stuff around the lifecycle ('needs testing', different closing status etc)

The last point I want to mostly ignore today ;) - but I think one very
important aspect of that point is that there is a -huge- difference
between manually controllable workflow and inferrable status. For
instance 'triaged' as a status *really* means 'the importance is set',
and becomes invalid if *something happens to mean the importance
should be reevaluated*. As a medical analogy, in an emergency room a
minor bleed would be put in the waiting-room-and-wait, but if the
person suddenly starts pouring blood out, then that would be
reevaluated.

Manually managing 'this bug is triaged' makes it hard for the system
to automatically identify and respond to such changes in status (e.g.
in our current model toggling status to incomplete 'there is not
enough data' might imply 'importance becomes unknown'). And I think
this actually drives usability complexity: the more manual a process
is, the more knobs and whistles folk need to tweak it into shape. (Yes
yes, !cite).

Related to bug metadata there is a related effort in the Ubuntu
community to get truely massive numbers of failure reports (*not*
bugs) aggregate-and-sorted and use that to drive analysis of the
failures affecting users.

Anyhow, in thinking about all of this, I'm starting to wonder if our
current system: bugs have a title (for search / summaries), a
description, conversation + process-control-metadata is generating
friction.

Perhaps we need to rethink how folk start their bugs and go from there...

Something like:

Users seek help: need something like 'answers'.
Some of these requests for assistance uncover symptoms of a problem in
the software (e.g. a crash, or user confusion from the UI). Call this
a problem statement.
A single *bug* could link or incorporate *many* problem statements.

Fixing a bug might not address all the problem statements, so we'd
want to be able to work with that list pretty easily.

What about bug tasks you ask? I think they fit this model pretty well
- if each problem statement is about a particular source package, for
instance, then bug search for duplicates (or equally crash analysis in
the future) can be hauling up the problem reports (not bugs) to match
on those; and once it matches follow the link from there to the real
bug. Consider for instance a bug in metacity which causes windows to
be show badly: users might report that on X, or on their X driver, so
having a bug with no links in X or the X driver they are using would
make triage a pain. But there is -nothing- for X to do - its an
innocent bystander in the problem. Having *symptoms* reported in X
without a bugtask there would allow separation of 'where the issue is
observed' and 'where it needs to be fixed'. It may also reduce the
number of multi-task bugs where one task just says 'invalid' : this
effectively lets the dup finder work today but is pretty ugly.

This also suggests the documented workarounds angle could link to the
bug / task / problem statement - I'd be inclined to have them as FAQ's
linked to prior support requests in the support facet of this.

tl;dr:
 - have users seek support.
 - migrate some support requests through to *symptom* or *problem* statements
 - aggregate those against bug tasks.

Anyhow, as I titled this, this is just me ruminating, but I'd sure
like us to find a core model that will address the friction we're
seeing today rather than tacking on more and more bits on the side :)

-Rob