[230] in Athena User Interface
Re: Helix Code Bug Buddy
daemon@ATHENA.MIT.EDU (Christopher D. Beland)
Fri Jun 23 06:07:48 2000
Message-Id: <200006231007.GAA08099@No-Whammies.mit.edu>
To: tb@MIT.EDU (Thomas Bushnell, BSG)
Cc: aui@MIT.EDU
In-Reply-To: The events that comprise the history of the universe.
Date: Fri, 23 Jun 2000 06:07:44 -0400
From: "Christopher D. Beland" <beland@MIT.EDU>
So Thomas raises a good point - what would the impact of a Bug Buddy
replacement be on support load?
Personally, I see a more user-friendly bug reporting system as a way
to "help" people write *better* bug reports, not more of them. I
don't think there's any reason to change the exposure level of the
bug reporting mechanism. Right now, it's on the Dash menu; we could
find some appropriate place on the Gnome-Athena menu.
The current interface gives little guidance as to what's expected, and
what will happen to the information once it's sent. For example, when
sendbug wants to know what program the report is about, it asks,
"Please enter the name of the program or locker with which you are
having problems." Well, which should I type "sipb" or "exmh"?
Helix Code does have a list to chose from. We could implement
something like this, just by allowing the user to chose from current
Gnome menu items, and perhaps the core I/S supported stuff.
The Emacs buffer that gets started up with sendbug is not so much
confusing as it is not very much incentive to write a well-structured
report. Personally, I'm lazy, and am much more likely to supply
certain bits of information if there's a little box I have to type it
in and then hit OK. Forcing users to choose from a list (one option
must be "other" of course) makes it a lot easier to route the report
to the proper maintainer. We might retrieve "which menu or locker did
you run this program from" in addition to the actual program name.
Gnome has this wonderful dialog box that pops up whenever something
crashes, and tells you the exact name of the program, the exact error,
and the process number. It also gives you the option of loading a web
page with a bug report form. Take a look:
http://www.gnome.org:65348/application_crashed.shtml?app=gnome-panel-properties-capplet&version=1.2.0&libsver=1.2.0
It has some very useful information, like that the developers need to
be able to have a reproducable set of steps to try in order to fix
this sort of error. In both this system and Bug Buddy, relevant system
information is captured automagically, so the user never has to bother
with such technical details.
Bug Buddy supports explicit routing (e.g. Gnome vs KDE vs Debian -
think Athena-I/S vs. SIPB vs TPSW), support for multiple types of
things (bugs, doc changes, RFEs, support requests) and support for
adding information to an existing bug report. It explicitly asks for
reproducability information, and allows the user to include a text or
core file, or even attach to a crashed application. When you are
finished, you can either send to the maintainers, send to yourself,
or save to file.
It would be nice if you got a confirmation screen that actually told
you who the report would go to, and what it would say. (Though
perhaps not give the e-mail address, lest you be tempted to e-mail it
directly?) With the Gnome crash web page, you also always get a nice
confirmation e-mail back, with a ticket-numbered e-mail address you
can send to if you have additional information.
Certainly we could include a "launch OLC" option at the appropriate
place for support requests.
Thomas also mentions that such a GUI system would annoy him; he
probably speaks for a number of people who are the most likely to be
submitting salient bug reports. It would be easy enough to keep
sendbug around for these folks, maybe with slightly more informative
dialogs?
I guess we have some fair representation of developers who get bug
reports here; we should probably also ask more user support-oriented
what they think. (We'll need to talk about the gOLC client anyway.)
Not that I'm proposing doing this anytime soon, but who would be the
person/people/lists to get in touch with? Oliver Thomas?
-B.
===============================================================
Christopher Beland - http://web.mit.edu/beland/www/contact.html
Got spam? Stop it at the source. http://spamcop.net
===============================================================
