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
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils@xxxxxxxxxx nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
