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@xxxxxxxx > >> > >>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
