Fedora support etiquette, need suggestions
fedora at cryptosystem.us
Tue Mar 9 20:32:01 UTC 2004
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
> >>>there needs to be a manifesto of sorts to show people where and how
> >>>look for desired information. I would not mind undertaking this task
> >>>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
> The question needs to include much needed information about the users
> configuration. Release, kernel, details on what has been done so far,
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
More information about the users