Handling non-technical users

[Dave Glowacki <dglo SSEC WISC EDU>]

> > I predict that this list will be hit with much higher percentage of this
> > type of problem reports the next few weeks. The wider GNOME gets known
> > the more we'll see.
> 
> That may be the case, but the user should be at least somewhat
> accomodating to the developers. I believe that if the Gnome culture
> evolves to such a point that every user knows (because they have to
> know) how to get and copy a backtrace from gdb to Netscape Mail, we'll
> all be better off.

In my immediate family, there are 4 medical doctors, a marketing manager
for an international corporation and one geek (me :-)  All of them are
highly educated people (except maybe me :-) but I guarantee that none of
them are technically clued in enough to do something like this (except
me:-)

You're devoted to the Gnome project, and that's a *good* thing.

You can't, however, lose sight of the goal of the Gnome project, which
is to make Linux palatable to non-technical users, who don't know
about gdb and, more importantly, shouldn't need to know about gdb.

That's the whole point of a project for non-technical users ... that
they not need to know any technical details in order to use the
software.  Expecting them to learn how to use gdb means expecting them
to use a commandline interface, which basically changes the goal of
the Gnome project to something like "teaching non-technical users how
to debug software".

As an example of a better approach toward software bugs, check out the
Wine project (www.winehq.com.)  When Wine fails, you can easily rerun
it with some debugging flags and have it automatically generate a trace
of the program execution and a final dump of the pertinent registers.
(Wine is emulating a Windows machine so all this information is easily
obtained.)  The trace/dump info can then be mailed in to the developers.
People don't need to learn how to use yet another tool, they just add
a flag to the commandline.

Even the simplicity of Wine's debugging mechanisms are too complicated
for non-technical users.  These people aren't going to be running things
from the commandline, they'll be clicking on an icon.

Perhaps an option could be added to the (still beta) file manager so
that users could hold down the Alt while clicking, and the file manager
would invoke the program with a standard debugging flag to turn on a
debugging mode in glib.  This could cause glib to fork off a subprocess
which would monitor the main process (which would be sending an execution
trace) and would automatically send email to a debugging address when
the main process died.

This still isn't a workable proposal, since many non-technical users
probably haven't set up they machines to deliver email to the outside
world, but it's much better than expecting that people learn to use
gdb.

The basic point is that you can't expect users to know how to provide
gdb stack traces, and you can't tell them that you "[don't] give a crap"
or that they're "bitching".  Users don't have the skills to provide
much more than the level of information the originator of this thread
provided.

Since an automated mechanism doesn't exist, you'll need to tell
users how to report bugs, but even your later "run 'gdb -file /path/to/crashing/program', type 'exec' at the prompt, use the
program, type 'backtrace' at the prompt, copy the resulting output
into a mailer with descriptions" isn't explicit enough.  Ignoring
the fact that none of my copies of 'gdb' understand the '-file'
argument ... I guarantee that somebody will try to debug
'/path/to/crashing/program' and be confused when they type 'exec'
and see "No exec file now."  There's not even a guarantee that a
user will have 'gdb' installed on their machine!

If you're going to respond to users, you should have a standard reply
which provides a recipe for getting a stack trace.  I don't run Gnome
*or* Linux here, so I'm murky on some of the details.  I'm also not
proposing this as the ideal solution, only as a stopgap measure until
an automated problem-reporting mechanism is in place.

Here's a first draft of a canned response:

  Sorry you're having problems with Gnome.  If you'd like to help us
  find your problem, we'll need more detail.  In order to supply this,
  you can do the following:

  * Bring up a window with a commandline interface [I'm not sure how
    one does this within the Gnome environment, but there should be
    specific instructions on how to do this]

  * The last thing you'll see in the commandline window is a prompt
    string.  This is the computer's way of telling you that it's
    ready for you to tell it what to do.  This prompt is often the name
    of your machine followed by a percent sign, but it might also be
    something like the name followed by a dollar sign or even something
    as simple as a pound sign ('#').  For these notes, we'll use a single
    percent sign ('%') as our prompt.  You don't need to type this in.    
    
  * You'll need to save everything that's displayed in your commandline
    window from this point.  To do this, you can use the 'script' command.
    To start it, just type "script program-dump".  The program will tell
    you that it's saving everything to the file named 'program-dump',
    and you'll see another commandline prompt.  It will look something
    like this:

	% script program-dump
	Script started, file is program-dump
	% 

    The script program actually starts a subshell.  This means that
    you'll have to type "exit" or enter a control-D to tell the
    'script' program to stop saving everything that happens in your
    commandline window.

  * Now that 'script' is running, you're ready to get the necessary
    information.  The program that does this is called 'gdb'.  You'll
    need to tell gdb to look at the program which is having problems.
    If you wanted to inspect the program named 'gmc', you'd type
    "gdb gmc".  'gdb' will print out some information, ending with
    its own prompt, which usually is "(gdb)".  Afer starting 'gdb',
    you should see something like this:

	% gdb gmc
	GNU gdb 4.11
	Copyright 1998 Free Software Foundation, Inc...
	GDB is free software, covered by the GNU General Public License,
	and you are welcome to change it and/or distribute copies of it
	under certain conditions.
	Type "show copying" to see the conditions.
	There is absolutely no warranty for GDB.  Type "show warranty"
	for details.
	This GDB was configured as "sparc-sun-solaris2.5".
	(gdb) 

  * Once you see the "(gdb)" prompt, type "run" to start the program
    running.  Do whatever it was that causes the program to die.
    When the program crashes, you should see something like this:

	This GDB was configured as "sparc-sun-solaris2.5".
	(gdb) run
	Program received signal SIGSEGV, Segmentation fault.
	0x1005fa20 in somefunc (arg=0x2fe1174) at file.c:123
	(gdb)

    Of course, most of the details will be different, but they
    should be roughly in this form.

  * After the second "(gdb)" prompt appears, type "backtrace" so
    there is some indication of what the program was doing when
    it failed:

	Program received signal SIGSEGV, Segmentation fault.
	0x1000065c in somefunc (arg=0x2fe1174) at file.c:123
	(gdb) backtrace
	#0  0x1005fa20 in somefunc (arg=0x2fe1174) at file.c:123
	#1  0x100837f0 in loop () at main.c:850
	#2  0x1000065c in main (argc=1, argv=0x2ff22714) at main.c:117
	#3  0x100001dc in __start ()
	(gdb) 

  * Now that you've got the necessary information, you can quit using
    'gdb' and 'script'.  Type "quit" to stop 'gdb' (it may ask you if
    you are sure; answer 'y') and type "exit" or
    control-D to end 'script':

	#3  0x100001dc in __start ()
	(gdb) quit
	The program is running.  Exit anyway? (y or n) y
	% exit
	Script done, file is program-dump
	%

  * Finally, you'll need to mail this to the appropriate address.
    If you can send mail from your machine, just create a mail
    message which describes (as exactly as possible) how you caused
    the program to fail, attach the "program-dump" file, and mail
    it to [whatever the appropriate address is]

  Thank you for helping the Gnome project!