On Fri, Aug 26, 2011 at 4:25 AM, Robert Collins <robe...@robertcollins.net> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
