Bug-buddy feature requests (was Re: Does the bug tracker actually work?)

[Martin Baulig <martin home-of-linux org>]

Owen Taylor <otaylor@redhat.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
system etc.

However, there are several things which IMHO need to be added to it:

1.) Backtraces

    There should be some way to check whether the backtrace is usable or
    not.

    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
       information.

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"
      etc.

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 `root@localhost.localdomain'.

    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
    reporting procedure:

    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
    been reported.

    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.

-- 
Martin Baulig
martin@gnome.org (private)
baulig@suse.de (work)