Some Thoughts on Support

[Egbert Eich]

On the release telecon we have talked about adding
pointers to places where users may get help or
can report problems when their X doesn't work the
way they expect.
XFree86 has a mailing list for that. Whenever the
server crashes it tells people to write to XFree86@
and send the log file.
This mailing list receives a lot of traffic. At times
when somewhere in this world a system update is released
which produces problems this list gets swamped with 
the same question over and over again.
Therefore I don't think it is wise to point people 
to a place where they can get personal assistance
before they have spend a minimum amount of time
to look for the answer themselves.

What I would therefore propose is a 2 or 3 step
process. 

1. If X is supplied by some OS vendor, the
   user should be directed at a vendor support site
   first. Chances are good that if there is a vendor
   related problem the user can find the information 
   he needs there and can be given detailed instructions
   on fixing the problem on this particular system.
   If the answer cannot be found there the user can be
   guided to step 2 from there.
2. If the user obtains the system from Xorg directly
   either as sources or precompiled binaries it should
   point to an FAQ.
   A Wiki is a perfect base for that. People can add
   or correct the information there - in fact it can
   be made a community efford. It would have to be
   moderated, though.
   I had spent some time to set up a Wiki for XFree86
   with a user and developers FAQ. The basic structures
   are there and I have been filling it with content.
   The FAQ was structured such that the user can quickly
   locate the information based on the problem he observes.
   (Wikis force people to create short pages as navigation
   in browser editors is no fun).
   Please have a look at http://xfree86.linuxwiki.org.
   If the user cannot find the answer in this FAQ he can
   be guided to 
   a. a bug tracking system - if he assumes it's really
      a bug.
   b. a support mailing list.
   He should be given instructions on how to properly
   deal with these facilities.
3.
   a. Bug tracking system: After the user has read thru the
      instruction how to use the bug tracking system he should
      be able to get to the bugzilla thru a link.
      Some projects let people search thru the bug tracker
      if a similar bug had been reported already before
      they allow them to enter a new report.
      We may consider doing that also, however we don't
      need to do set this up immediately.
   b. Support mailing list: People should be educated
      about the etiquette of this mailing list to make 
      the life of those who are doing this support less
      miserable:
      Here are my favorites:
      1. No HTML or funny attachments.
      2. Use the enter key from time to time when composing
         the email. Don't assume that reader's mailer will
	 do that.
      3. No long biographies: give a brief description of
         the problem, then describe any observations made.
      4. On server problems: Unless completely certain that 
	 this will be irrelevant attach the log file (as text 
	 - not compressed!).
         Don't just send the log file without explanation - this
	 is rude!
 
Egbert.