On 26 August 2011 13:25, Robert Collins <robe...@robertcollins.net> wrote: > 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 :)
I think splitting "users experienced a problem" from "code needs changing" is well worth while. Answers is a good start for users who come in that way (though not yet perfect); crashes/oopses/etc also somehow fit in here and either may or may be connected to the user needing help. (If some random gnome daemon crashes I'm happy for you to know about it but I don't necessarily need an ongoing conversation.) Distinguishing machine-set from user-set data seems like a really good principle. For me a totemic case is that 'fix released' really seems very close to "targeted to a milestone which is now released", and updating it from a script is not just a hassle (and makes mail noise) but in a sense wrong. m _______________________________________________ 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
