[232] in Athena User Interface
Re: Helix Code Bug Buddy
daemon@ATHENA.MIT.EDU (Richard Tibbetts)
Fri Jun 23 14:03:08 2000
Message-Id: <200006231803.OAA21427@hikari-no-ken.mit.edu>
To: "Christopher D. Beland" <beland@MIT.EDU>
cc: tb@MIT.EDU (Thomas Bushnell, BSG), aui@MIT.EDU, tibbetts@MIT.EDU
In-reply-to: Your message of "Fri, 23 Jun 2000 06:07:44 EDT."
<200006231007.GAA08099@No-Whammies.mit.edu>
Date: Fri, 23 Jun 2000 14:03:03 -0400
From: Richard Tibbetts <tibbetts@MIT.EDU>
Why do we need a new GUI replacement to sendbug. I can think of a
couple possible reasons:
1) GUI's are cool.
2) Athena has a lot of bugs that we don't hear about because sendbug
scares people.
3) The current bug reports that we get about Athena are less useful
than they might be if we had a good bug reporting tool.
4) When we deploy GNOME we are going to have a lot more bugs. More
clueless users are going to find bugs, and they won't report them
unless we use something like Bug Buddy.
Is there another reason I missed?
I think 1 is dumb. I think that Greg and Thomas are better able to
judge 3, but I expect that it is not a problem. I don't believe that 2
is the case, but I would be willing to listen if you had arguments to
the contrary.
As for 4, I think that might be a valid reason to use Bug Buddy,
especially if it was not very difficult to use.
tibbetts
On 6/23 beland wrote:
>
> 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-properti
> es-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
> ===============================================================
-*- http://www.mit.edu/~tibbetts -*- finger tibbetts@monk.mit.edu -*-
