Re: Subject: Re: Stock response addition

[Elijah Newren <newren gmail com>]

Sorry for my slow response...

On Wed, 17 Nov 2004 13:49:03 +1100 (EST), hala cse unsw edu au
<hala cse unsw edu au> wrote:

> Caleb, Elijah,
> Some semi-random n00b thoughts for you :)
> Is it wortwhile filing a usability bug against "bug buddy" for the volume
> of these bug reports that exist and seem only to take up bugsquad time? Or
> is the fact that many of us can't seem to get bug buddy working usefully
> for the relevant developers when it autolaunches after a crash something
> that really can't be improved upon?

It's possible that something could be done to improve things, but
there's not really any point in filing a bug saying "bug buddy reports
should be more informative" unless you have a concrete suggestion on
how to make them so.  So, effectively, I'm saying that the latter of
the two options you present is the case we are stuck with...

Since bug-buddy can now find executables in $PREFIX/libexec, the only
thing that I can think of that could really be done to improve what
bug-buddy could find would be to make sure distros ship with debuginfo
packages installed by default, or compiled with debugging information
left in.  Or at very least not strip them.  But that isn't going to
happen.  Doing that makes binaries bigger and slower (slower mainly
because they're bigger and memory requirements are already large
enough...)

Of course, that's only looking at things from the viewpoint of getting
useful stack traces.  There's lots more too--like getting useful
duplication steps.  But that's something bug-buddy couldn't possibly
do.  We have to rely on humans for that, and the fact of the matter is
that most people won't know how to do that.

It'd be great if we could automate this away, but the bugsquad exists
for a pretty good reason.  ;-)  But, of course, I'm sure people will
still discover ways to make things better despite all this and when we
have any concrete ideas on how to do that, we'll do our best to
implement them.

> I realise usability bugs have issues, such as being ver difficult to
> demonstrate a solution. But I guess there's a metric here in how many
> non-useful bug-buddy generated reports are bein recieved vs useful
> bug-buddy generated reports.
> 
> Speaking of which, is there a nice, succinct guide on how to generate
> useful stuff using bug-buddy that could be linked in the response and
> potentially on bug-buddy itself?

That's basically what the stock responses
(http://developer.gnome.org/projects/bugsquad/triage/stock-responses.html)
are for.  In particular, the links to the guide to getting a stack
trace and the guide on how to report a bug well.  We probably can't
make users read both of those before reporting a bug, or no one will
report anything.  Granted there's always a trade-off, but it's not too
hard for us bugsquadders to recognize what specifically the reporter
is missing and to paste a stock response for them.  (Whereas it is
considerably harder for them, not being as familiar with Gnome).


Hope that helps,
Elijah