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 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.
When you ask your question, display the fact that you have done these things first; this will help establish that you're not being a lazy sponge and wasting people's time. Better yet, display what you have learned from doing these things. We like answering questions for people who have demonstrated they can learn from the answers.
Use tactics like doing a Google search on the text of whatever error message you get (searching Google groups as well as Web pages). This might well take you straight to fix documentation or a mailing list thread answering your question. Even if it doesn't, saying “I googled on the following phrase but didn't get anything that looked promising” is a good thing to include in e-mail or news postings requesting help.
Prepare your question. Think it through. Hasty-sounding questions get hasty answers, or none at all. The more you do to demonstrate that having put thought and effort into solving your problem before seeking help, the more likely you are to actually get help.
Make it clear that you are able and willing to help in the process of developing the solution is very good. “Would someone provide a pointer?”, “What is my example missing?”, and “What site should I have checked?” are more likely to get answered than “Please post the exact procedure I should use.” because you're making it clear that you're truly willing to complete the process if someone can just point you in the right direction.
Use meaningful, specific subject headers
The thread title 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.
HELP! Screen flickers!
WinXP, Windows Media Player 10, some videos cause the screen to flicker
The process of writing an “object-deviation” description will help you organize your thinking about the problem in more detail. What is affected? Just the video window or other graphics too? Is this specific to Windows Media Player? To version 10? What kind of videos to cause the flicker? So helping people who see the result can immediately understand what it is that you are having a problem with and the problem you are having, at a glance.
More generally, imagine looking at the index of an archive of questions, with just the thread titles showing. Make your thread titles reflect your question well enough that the next guy searching the archive with a question similar to yours will be able to follow the thread to an answer rather than posting the question again.
Don't ask new questions in reply to a thread about another problem, because it will only be seen by those who are watching this thread. So, unless you are sure you want to ask only the people currently active in the thread, start a new one.
Make it easy to reply
In Web forums, asking for a reply by e-mail is outright rude, unless you believe the information may be sensitive (and somebody will, for some unknown reason, let you but not the whole forum know it). If you want an e-mail copy when somebody replies in the thread, request that the forum sends it by subscribing to the thread, and select instant e-mail notification.
Write in clear, grammatical, correctly-spelled language
This especially goes out to native speakers using "youth speech" or other slangs that differ from "standard english". Many people from different parts of the world, or sometimes even older (and older here can mean just 10 years or so) people might have problems with that kind of language.
Expressing your question clearly and well is important. If you can't be bothered to do that, we can't be bothered to pay attention. Spend the extra effort to polish your language. It doesn't have to be stiff or formal — but it has to be precise, refrain from slang speech or too much abbreviations ("u" instead of "you" and similar).
Don't TYPE IN ALL CAPS; this is read as shouting and considered rude.
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, version, whatever)
- 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 others will ask, and answer them in advance in your request for help.
Grovelling is not a substitute for doing your homework
Some people who get that they shouldn't behave rudely or arrogantly, demanding an answer, retreat to the opposite extreme of grovelling. “I know I'm just a pathetic newbie loser, but...”. This is distracting and unhelpful. It's especially annoying when it's coupled with vagueness about the actual problem.
Describe your problem's symptoms in chronological order
The clues most useful in figuring out something that went wrong often lie in the events immediately prior. So, your account should describe precisely what you did, and what the machine did, leading up to the blowup.
Courtesy never hurts, and sometimes helps
Be courteous. Use “Please” and “Thanks for your attention” or “Thanks for your consideration”. Make it clear you appreciate the time people spend helping you for free.
Follow up with a brief note on the solution
Post a note after the problem has been solved in the thread; let them know how it came out and thank them again for their help.
Your followup doesn't have to be long and involved; a simple “Howdy — it was a failed network cable! Thanks, everyone. - Bill” would be better than nothing. In fact, a short and sweet summary is better than a long dissertation unless the solution has real technical depth. Say what action solved the problem, but you need not replay the whole troubleshooting sequence.
For problems with some depth, it is appropriate to post a summary of the troubleshooting history. Describe your final problem statement. Describe what worked as a solution, and indicate avoidable blind alleys after that. The blind alleys should come after the correct solution and other summary material, rather than turning the follow-up into a detective story. Name the names of people who helped you; you'll make friends that way.
Besides being courteous and informative, this sort of followup will help others searching the archive of the forum to know exactly which solution helped you and thus may also help them.
Last, and not least, this sort of followup helps everybody who assisted feel a satisfying sense of closure about the problem. If you are not a techie yourself, trust us that this feeling is very important to the gurus and experts you tapped for help. Problem narratives that trail off into unresolved nothingness are frustrating things; techies itch to see them resolved. The goodwill that scratching that itch earns you will be very, very helpful to you next time you need to pose a question.
Among techies, this sort of good followup behavior is actually more important than conventional politeness. It's how you get a reputation for playing well with others, which can be a very valuable asset.
(taken from: http://www.catb.org/~esr/faqs/smart-questions.html and edited to be more suitable for JUB)