Fedora support etiquette, need suggestions

[Aaron Matteson]

Jeff Vian became daring and sent these 4.4K bytes,
> 
> 
> Aaron Matteson wrote:
> 
> >Andrew Robinson became daring and sent these 0.7K bytes,
> > 
> >
> >>Aaron Matteson wrote:
> >>   
> >>
> >>>Second, i would like to use my previous post to point out that
> >>>perhaps 
> >>>there needs to be a manifesto of sorts to show people where and how
> >>>to 
> >>>look for desired information. I would not mind undertaking this task
> >>>with 
> >>>the help of oen or two others using the standard fedora/redhat 
> >>>documentation methods.
> >>>
> >>>Anyone up for this task besides me?
> >>>     
> >>>
> >>Aaron, since I swung the stick that stirred up this hornet's nest, I 
> >>would be happy to help out. Since I'm not a developer, I may require 
> >>some, uh, hand holding. Please contact me at awrobinson at cox.net.
> >>
> >>Andrew Robinson
> >>
> >>   
> >>
> >Started new thread for this.
> >
> >Ok, i have begun to draw up a list of things i feel should be included
> >in this document in terms of where to look for information, how to look
> >for it and proper etiquete for asking for help or pointers. Most people
> >do not seem to have the problem of asking for information, but i feel
> >there should at least be some examples of how this shouldideally take
> >place. This seems kind of odd to me, so i am trying to put all this in a
> >way that will not riffle some feathers.
> >
> >So far what i have had time to think of is this:
> >
> >Information to include in a query:
> >*The problem
> >*What is the exact text of the error
> >*What you expect in terms of a solution
> >       **Pointers, nudge in the right direction etc.
> >
> >How such a query should be handled:
> >*Nudge in the right direction
> >*At the very least a link to bugzilla
> >*If it is simple enouph just tell how to fix it
> >*There is much to be said for researching a problem for ones self, so i
> >do not think every situation demands a solution as to an explaination of
> >the given issue.
> >
> >This will no doubt go through a dozen or more revisions before it see's
> >the light of day for the sake of tact.
> >
> >What i guess i am trying to write here is more of a manifesto-handbook
> >for asking for help and giving help in a way that would be most productive.
> >
> >What i am asking this list is for people to list how they think they
> >best like questions and likewise how to make an answer more appealing.
> >You all see what i am trying to get at, any input and suggestions would
> >be very helpful and appriciated. Also, what where some of the most
> >positive experiences dealing with community support everyone has had?
> >What methods have you found best for dealing with people needing help,
> >but at the same time not doing everything for them?
> >
> The guidelines need to be sent to every new user registering on this 
> list, and periodically after that as a reminder.

I agree with this completly.

> Tell people to make at least a minimal effort to find their own answer 
> before they ask, and include common sources for information, such as 
> www.tldp.org.  This will let them know they are responsible for their 
> own  system and guide them so those answering their questions do not 
> have to start with a total zero of information.

This is one of the main points i want conveyed more then anything, very
well put.

> The question needs to include much needed information about the users 
> configuration.  Release, kernel, details on what has been done so far, 
> etc.  

Right, i am with you, an email should be sent to new subscribers
explaining all this or at least pointing toward a well written guide
explaining all this and more. Not too sure how the list software works
in this regard, so (?).

>    A perfect example is one that was answered today.  The user is on 
> FC1 but has installed the 2.6.3 kernel and that changes the answer for 
> his question completely.  He did not provide that information and 4 
> answers were posted before it became obvious that he had a different 
> than espected kernel so the effort to help was wasted.
> 
> Then add on the detailed problem with error messages if appropriate and 
> a detailed, specific question.
> 
> For those helping, provide pointers to the location of the answer (or if 
> simple the actual answer).  URLs are nice if available.   Also provide a 
> reason why you used your solution. There are many ways to get the same 
> result, and your reasoning for making your choice will help educate.

Explainations are an excellent idea, gives a vantage point on the
situation and can put the person asking the question in a position to
understand better why he needs to do things a certain way and gives
insight into future potential non-issues :)

> >This has started out as a simple guide for finding information but i
> >think it demands more then that. Because i think some area's of support
> >can definatly use a makeover, sometimes it is that first question that
> >makes all the difference to someone adopting linux or trying it out for
> >the first time. First impressions are the lasting ones, this is one
> >thing the debian community does pretty well (If a newbie can get past
> >the installer) :)
> > 

-- 
  . 0 .  Aaron M Matteson - http://cryptosystem.us
  . . 0  Real programmers don't document. If it was hard to write,
  0 0 0  it should be hard to understand!
--------------------------------------------------------------------------
   /~\   The ASCII Ribbon Campaign Against HTML Email!
   \ /	 
    X    All that is gold does not glitter, not all those who wander
   / \   are lost --jrr tolkien