I've always thought that what seperates a wise man from everyone else is the ability to ask pertinent questions.
I'm sure this problem exists on other forums of a technical nature but SC2 mapping sites are the only ones I frequent so it is where I encounter it. People are often seeking help for something but seem to not know how to ask good questions or how to convey information in their questions.
With that in mind I present an abridged version of this http://www.cplusplus.com/forum/articles/1295/ which is itself an abridged verion of "How to ask questions the smart way" by Eric Steven Raymond.
In the world of programming, the kind of answers you get to your technical questions depends as much on the way you ask the questions as on the difficulty of developing the answer.
The first thing to understand is that programmers actually like hard problems and good, thought-provoking questions about them. If we didn't, we wouldn't be here
Programmers have a reputation for meeting simple questions with what looks like hostility or arrogance. It sometimes looks like we're reflexively rude to newbies and the ignorant. But this isn't really true.
Before You Ask
Before asking a question a, do the following:
1.Try to find an answer by searching the archives of the forum you plan to post to.
2.Try to find an answer by searching the Web.
Prepare your question. Think it through. Hasty-sounding questions get hasty answers or none at all.
Use meaningful, specific subject headers
The subject header is your golden opportunity to attract qualified experts' attention. Don't waste it on babble like 'Please help me' Don't try to impress us with the depth of your anguish; use the space for a super-concise problem description instead.
Be precise and informative about your problem
•Describe the symptoms of your problem carefully and clearly.
•Describe the environment in which it occurs (machine, OS, application, 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.
Do the best you can to anticipate the questions a respondent will ask, and answer them in advance in your request for help.
Volume is not precision
You need to be precise and informative. This end is not served by simply dumping huge volumes of code or data into a help request. If you have a large, complicated test case that is breaking a program, try to trim it and make it as small as possible.
This is useful for at least three reasons. One: being seen to invest effort in simplifying the question makes it more likely you'll get an answer, Two: simplifying the question makes it more likely you'll get a useful answer. Three: In the process of refining your bug report, you may develop a fix or workaround yourself.
Describe the problem's symptoms, not your guesses
It's not useful to tell programmers what you think is causing your problem. So, make sure you're telling them the raw symptoms of what goes wrong, rather than your interpretations and theories. Let them do the interpretation and diagnosis. If you feel it's important to state your guess, clearly label it as such and describe why that answer isn't working for you.
Describe the goal, not the step
If you are trying to find out how to do something, begin by describing the goal. Only then describe the particular step towards it that you are blocked on.
Often, people who need technical help have a high-level goal in mind and get stuck on what they think is one particular path towards the goal. They come for help with the step, but don't realize that the path is wrong. It can take substantial effort to get past this.
Be explicit about your question
Open-ended questions tend to be perceived as open-ended time sinks. Those people most likely to be able to give you a useful answer are also the busiest people (if only because they take on the most work themselves). People like that are allergic to open-ended time sinks, thus they tend to be allergic to open-ended questions.
You are more likely to get a useful response if you are explicit about what you want respondents to do (provide pointers, send code,..). This will focus their effort and implicitly put an upper bound on the time and energy a respondent must allocate to helping you.
When asking about code
Don't ask others to debug your broken code without giving a hint what sort of problem they should be searching for. Posting a few hundred lines of code, saying "it doesn't work", will get you ignored. Posting a dozen lines of code, saying "after line 7 I was expecting to see <x>, but <y> occurred instead" is much more likely to get you a response.
If you simply want a code review, say as much up front, and be sure to mention what areas you think might particularly need review and why.
Follow up with a brief note on the solution
Send a note after the problem has been solved to all who helped you; 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.
Besides being courteous and informative, this sort of followup will help others searching the archive of the mailing-list/newsgroup/forum to know exactly which solution helped you and thus may also help them.