On 02/12/2010 03:15 AM, Nils Philippsen wrote:
> On Wed, 2010-02-10 at 15:48 +0100, Denys Vlasenko wrote:
>> On Sat, 2010-02-06 at 10:53 +0000, Leigh Scott wrote:
>>> IMO ABRT isn't that useful as a lot of the reports don't include steps
>>> to reproduce (I just close the bugs after a month if they don't respond
>>> to the "needinfo" request).
>>
>> You can do it even sooner. If backtrace is unusable and there is no
>> description whatsoever, then *this* user is not likely to bother
>> to do anything to help you.
>>
>>> I believe ABRT shouldn't file a bug report unless it is filled in
>>> properly.
>>
>> Sadly, this is impossible to achieve. Sure, we can
>>
>> if (description == "") yell("Fill the description dammit!");
>>
>> but then user might well enter description consisting of
>> "I dont care" (or worse).
>
> You're contradicting yourself here. First you say we should close bugs
> without a description even sooner (like, immediately?), then you don't
> want abrt to not file a report without a description. I don't see why we
> should manually do the work abrt fails to do automatically -- while it
> is automatable.
>
> What strikes me as very puzzling is why abrt has this humongous dialog
> instead of leading the user step-by-step through this... I know you just
> changed the UI in a stable release. But doing it twice is twice fun ;-),
> so why not use a wizard (taking the user by the hand, doing it step by
> step...) and do it like this:
>
> 1. Check if the bug has been reported yet (via that abrt BZ id thingy).
> If yes, ask user to review the description (in their browser?) and
> eventually add any additional details (see below in step 3a. for hints
> abrt could provide for that), then stop here. Otherwise continue.
>
> 2. Check that all debuginfos can be installed etc, then continue. If
> not, tell the user that "important debugging data" can't be assembled
> right now and a) if they would like to postpone the bug report, if you
> assume that it's a temporary problem or b) "there's an update for
> package(s) ... which are used by your application, would you like to
> install them?", as this seems to be the most common case of debuginfos
> not being available.
>
> 3a. Display wizard window. Ask users (politely!) for a description of
> what they did before the crash happened:
>
> "Please describe what you did before the application crashed. Provide as
> much detail as you can, this is important for the person getting the bug
> report to help you. If this is too much work for you right now, you can
> make some notes about details that are hard to remember in this field,
> click on "Postpone report" below
>
> _Hints for filling out this form_
>
> ...
>
> [Cancel report] [Postpone report] [Back] [Forward]"
>
> The buttons would be visible on any page in the wizard, [Back] would be
> insensitive here because it's the first step. "_Hints for filling out
> this form_" would be a link which would open a help page going into much
> more detail, e.g.:
>
> "... If you didn't use the app for a long while, state that, but try to
> remember what you did when you last used it. Please also describe what
> else you did immediately before the crash. ..."
>
> Also provide examples of good and bad descriptions in this.
>
> 3b. While the user fills out the description, abrt loads debuginfo
> packages in the background. If the user is ready before all are
> downloaded, display the usual progress bar.
>
> 4. Next wizard page. Display backtrace, ask for review and removal of
> sensitive data like passwords. "You don't need to understand most of
> this, but if you see data )like passwords) you would not like to be put
> into the bug report (which may be seen by anybody), please replace it
> with a placeholder (like '<password>')."
>
> 5. Last wizard page. Get confirmation for filing the bug report. "You
> can review what will be submitted by using the Back and Forward buttons
> at the bottom of this dialog." Fields for Bugzilla username and
> password, pre-filled if we have that information already. "[ ] Remember
> this information" checkbox.
>
> If the user postponed this, they must have a means of continuing this,
> so the applet may not be hidden in this case. While I'm at it, the
> applet shouldn't flash forever, this breaks energy-saving measures (if
> the user ignored it for a minute, they'll ignore it for an hour -- maybe
> wake up it screensaver gets active, then inactive/unlocked).
>
> In my opinion this would be much less intimidating to users and give us
> bug reports where we can actually help instead of having to tell most of
> them "sorry, too few info, can't help" right away.
>
> Those who don't care enough to fill out the description probably won't
> care enough to create a BZ account in the first place. If there are
> trolls who would put nonsense into the description or worse, well those
> could do that via web-based BZ as well. And they can be dealt with.
>
> Nils
Hi,
Thanks for good hints, I'm already working on a wizard style gui for
ABRT, to walk the user thru the reporting proccess, so I'll definitely
implement some of you ideas into it.
Thanks,
Jirka
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
