← Back to team overview

launchpad-dev team mailing list archive

Re: RFC: UI for +filebug while waiting-for-blob-to-be-processed

 

On 16 February 2010 12:30, James Westby <jw+debian@xxxxxxxxxxxxxxx> wrote:
> On Tue, 16 Feb 2010 11:56:12 +0000, Graham Binns <graham@xxxxxxxxxxxxx> wrote:
>> I like this idea, but we rejected it early on because there's some
>> data in Apport blobs that can be used to populate the +filebug form.
>>
>> Of course,  we could add it after the fact, for example updating the
>> bug description to be apport description + user description and so on.
>> I'm ambivalent about doing that though.
>>
>> That said, it wouldn't be hard to have the job class tied to the bug
>> once it's been filed and then, once the job's complete, updating the
>> bug with the data from the blob.
>>
>> I'll look into how the data from the blob is used again (I can't
>> remember why we rejected this approach before; I'm assuming there's a
>> good reason that I've forgotten). If it's possible to do it this way
>> then maybe that's how we should proceeed.
>
> A surprising number of people delete the apport info from the bug
> description, so appending that afterwards would reduce the incidence of
> that (at the cost of an extra bugmail I assume).
>
> However, the title of the bug is what worries me. We have a tough enough
> time with people deleting the apport-suggested title and putting in
> "Crash!!!" or similar, and that is all we would have if apport didn't
> suggest a title at all (I'm not sure how you would join the apport and
> user set titles).
>
> Also, usually people have no clue as to what caused the bug, so asking
> them to fill in blank boxes will stop some people filing. At least
> having them prepopulated allows people to write "I don't know what
> happened, I was just asked to submit this" without feeling like they
> aren't conveying any information whatsoever.
>

Right. Having looked at the code, there are also practical
considerations. For example, apport data can be used to decide whether
or not the bug should be private (which is interesting because you
can't actually make a bug private using the +filebug UI at the
moment).

So, I think it's safe to say that we need to have the apport data in
the +filebug process and not after.


-- 
Graham Binns | PGP Key: EC66FA7D



References