Bug-buddy feature requests (was Re: Does the bug tracker actually work?)
- From: Martin Baulig <martin home-of-linux org>
- To: Owen Taylor <otaylor redhat com>
- Cc: Telsa Gwynne <hobbit aloss ukuu org uk>,gnome-devel-list gnome org
- Cc: jacob helixcode com
- Subject: Bug-buddy feature requests (was Re: Does the bug tracker actually work?)
- Date: 06 Aug 2000 15:53:31 +0200
Owen Taylor <email@example.com> writes:
> The real problem is not "stupid user" - but "stupid bug buddy
> author allowed people to submit bug reports without entering
> a description of the problem." (Sorry Jacob - I know you've fixed
> this, but most of these bug reports are coming from older versions
> of bug-buddy.)
I'd like to add some more "feature requests" for bug-buddy here.
First of all, I think bug-buddy already helped a lot in getting better
bug reports. For instance, before the bug-buddy time most of the bugs
had no useful backtraces at all, they contained no information about the
However, there are several things which IMHO need to be added to it:
There should be some way to check whether the backtrace is usable or
a) When the user has a stripped binary, bug-buddy should just reject
the bug report
b) When the user has a non-stripped binary, but compiled without
debugging, then bug-buddy should print a warning message but let
the user submit the bug report if he provides enough additional
2.) Per-Package information and policies
There should be a way to let package maintainers tell bug-buddy to
include additional information or to enforce some policies for bug
reports to their package.
* For instance, 99.9995% of all GTop bug reports require the version
numbers of LibGTop and gtk-engines
* Package maintainers may want to point people to a "Frequently Reported
Bugs" page with bugs which are frequently reported, already fixed etc.
Such a page could for instance contain information about several bugs,
tell people "if you get this bug, please include information about foo"
3.) Enforcement of valid email addresses.
Bug-buddy should enforce a bit more that people provide a valid email
address for a bug report, for instance it should reject everything which
looks like `firstname.lastname@example.org'.
It's ok to let people report bugs anonymously if their bug reports contain
enough useful information, but bug-buddy must print a prominent warning
dialog in this case and ask people whether they really want to proceed.
4.) Bug database
We have two sorts of users. Some of them just want to report bugs since
they're pissed that their application crashes.
However, I think the large majority of people _want_ to provide useful
bug reports and they also want to help with their bug reports; they may
just not know how.
For most people, bug-buddy is their first contact with the bug tracking
system. This means that it must provide more information about the bug
a) It should provide some general introduction; tell people how to report
a bug, which information is needed etc.
b) It should point people to things like the bug database, FAQs etc.
Ideally, bug-buddy should let the user browse a list of current bugs
before you file a bug report yourself.
This way, people could try to find out whether their problem has already
There should also be a way for package maintainers to add some information
to this list, for instance "if you get this bug, I need your help to fix
it, please tell me ...." etc.
] [Thread Prev