To summarize the before-mentioned article,
How To Ask Questions The Smart Way, by Eric Steven Raymond
Before You Ask
Before asking a technical question by e-mail, or in a newsgroup, or on a website chat board, do the following:
- Try to find an answer by searching the archives of the forum you plan to post to.
- Try to find an answer by searching the Web.
- Try to find an answer by reading the manual.
- Try to find an answer by reading a FAQ.
- Try to find an answer by inspection or experimentation.
- Try to find an answer by asking a skilled friend.
- If you're a programmer, try to find an answer by reading the source code
When You Ask:
Choose your forum carefully
Be sensitive in choosing where you ask your question. You are likely to be ignored, or written off as a loser, if you:
- post your question to a forum where it's off topic
- post a very elementary question to a forum where advanced technical questions are expected, or vice-versa
- cross-post to too many different newsgroups
- post a personal e-mail to somebody who is neither an acquaintance of yours nor personally responsible for solving your problem
Use meaningful, specific subject headers
On mailing lists, newsgroups or Web forums, the subject header is your golden opportunity to attract qualified experts' attention in around 50 characters or fewer. Don't waste it on babble like “Please help me” (let alone “PLEASE HELP ME!!!!”; messages with subjects like that get discarded by reflex). Don't try to impress us with the depth of your anguish; use the space for a super-concise problem description instead.
One good convention for subject headers, used by many tech support organizations, is “object - deviation”. The “object” part specifies what thing or group of things is having a problem, and the “deviation” part describes the deviation from expected behavior.
Stupid: HELP! Program doesn't work properly on my laptop!
Smart: RSLogix does not run on my laptop
Smarter: Rockwell RSLogix version 5.5 will not run on my Dell Inspirion Windows 2000 laptop.
Write in clear, grammatical, correctly-spelled language.
More generally, if you write like a semi-literate boob you will very likely be ignored. Writing like a l33t script kiddie hax0r is the absolute kiss of death and guarantees you will receive nothing but stony silence (or, at best, a heaping helping of scorn and sarcasm) in return.
If you are asking questions in a forum that does not use your native language, you will get a limited amount of slack for spelling and grammar errors — but no extra slack at all for laziness (and yes, we can usually spot that difference). Also, unless you know what your respondent's languages are, write in English. Busy hackers tend to simply flush questions in languages they don't understand, and English is the working language of the Internet. By writing in English you minimize your chances that your question will be discarded unread.
Be precise and informative about your problem
- Describe the symptoms of your problem or bug carefully and clearly.
- Describe the environment in which it occurs (machine, OS, application, whatever). Provide your vendor's distribution and release level (e.g.: “Fedora Core 4”, “Slackware 9.1”, etc.).
- Describe the research you did to try and understand the problem before you asked the question.
- Describe the diagnostic steps you took to try and pin down the problem yourself before you asked the question.
- Describe any possibly relevant recent changes in your computer or software configuration.
Do the best you can to anticipate the questions a hacker will ask, and answer them in advance in your request for help.
Courtesy never hurts, and sometimes helps
Follow up with a brief note on the solution
If You Can't Get An Answer:
If you can't get an answer, please don't take it personally that we don't feel we can help you. Sometimes the members of the asked group may simply not know the answer. No response is not the same as being ignored, though admittedly it's hard to spot the difference from outside.
In general, simply re-posting your question is a bad idea. This will be seen as pointlessly annoying. Have patience: the person with your answer may be in a different time-zone and asleep. Or it may be that your question wasn't well-formed to begin with.
There are other sources of help you can go to, often sources better adapted to a novice's needs.
How To Answer Questions in a Helpful Way:
Be gentle. Problem-related stress can make people seem rude or stupid even when they're not.
Reply to a first offender off-line. There is no need of public humiliation for someone who may have made an honest mistake. A real newbie may not know how to search archives or where the FAQ is stored or posted.
If you don't know for sure, say so! A wrong but authoritative-sounding answer is worse than none at all. Don't point anyone down a wrong path simply because it's fun to sound like an expert. Be humble and honest; set a good example for both the querent and your peers.
If you can't help, don't hinder. Don't make jokes about procedures that could trash the user's setup — the poor sap might interpret these as instructions.
Ask probing questions to elicit more details. If you're good at this, the querent will learn something — and so might you. Try to turn the bad question into a good one; remember we were all newbies once.
While just muttering RTFM is sometimes justified when replying to someone who is just a lazy slob, a pointer to documentation (even if it's just a suggestion to google for a key phrase) is better.
If you're going to answer the question at all, give good value. Don't suggest kludgy workarounds when somebody is using the wrong tool or approach. Suggest good tools. Reframe the question.
Help your community learn from the question. When you field a good question, ask yourself “How would the relevant documentation or FAQ have to change so that nobody has to answer this again?” Then send a patch to the document maintainer.
If you did research to answer the question,
demonstrate your skills rather than writing as though you pulled the answer out of your butt. Answering one good question is like feeding a hungry person one meal, but teaching them research skills by example is teaching them to grow food for a lifetime.