launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

On 26 August 2011 13:25, Robert Collins <robertc@xxxxxxxxxxxxxxxxx> 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