launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxx>]

On Fri, Aug 26, 2011 at 4:25 AM, Robert Collins
<robertc@xxxxxxxxxxxxxxxxx> wrote:
...
> 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*
...

Agreed. We had similar discussions about Branch lifecycle status.

>
> 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).
>

See merge proposal statuses as an example.

> 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.
>

What precisely do you mean by "bug" at this point?

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

I'm not quite sure what that means. Can you give a concrete example?

> 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.
>

I think this is a sensible approach.

Under this, are you thinking that we should preserve the "only one
bugtask per bug target" model?

> 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 :)
>

Obviously, it would be quite a big change. Very much agree with the last.

Have you thought much about how this interacts with
https://dev.launchpad.net/IssueTracker?

jml