Technical forums (such as web-based forums or Usenet newsgroups) are among the very best places to get specific technical questions answered because many of the people answering questions in technical forums are very knowledgeable about the specific topic and like sharing that knowledge.
Of course, without forum participants, there is no forum, so new forum participants are welcome. That said, there are a group of reasons why some forum participants do not get their questions answered (or not answered quickly or meaningfully). My purpose here is to educate technical forum participants on the best way to ask questions so that their questions will have a higher probability of being answered in a meaningful and timely way.
Acknowledgements: Raymond Chen (The Old New Thing), Eric Raymond (How to Ask Questions the Smart Way), Eric Lippert (Fabulous Adventures in Coding), and Mike Pope.
For no particular reason, I’m calling the forum question-answerers Ted. (Ted might be a forum moderator or someone who is knowledgeable about a particular topic.)
1. Search before you ask
Don’t be helpless. For example, if you need to know how to list services in PowerShell, use a search engine. If you post a question that is easily answered by a quick search, Ted may give a response that is designed to help you help yourself. (Ted may also simply ignore the question because he might feel like you’re asking him to do your work for you. See #6.)
2. Ask in the appropriate forum
You should only ask questions that are relevant to the forum. For example, don’t ask a SQL server question in a scripting forum. If you’re not sure where you should post your question, try to find out (see #1). If you don’t do this, your question might be ignored, or you’ll probably be told you’re asking in the wrong place. This wastes both your time (because you’re not getting your question answered) and Ted’s time (either because he has to read your question before deciding to ignore it or because he has to type a “you’re not asking in the right place” response).
If you can’t find the relevant forum, give some indication that you’re not helpless. For example: “I’m looking for information about how to use the Get-Foo cmdlet’s -Bar parameter in PowerShell. I searched for ‘powershell get-foo bar’, but the results lack detail about the blob the parameter is expecting. Does anyone have any details about the -Bar parameter’s blob format?” In other words, try to illustrate that you’re not just asking Ted to do your work for you.
3. Use a meaningful subject line
Your subject line should be as specific as possible and summarize the question. Subject lines such as “please help” or “newbie question” are not helpful because you’re forcing Ted to open the question in order to read it. Ted will probably prioritize questions with meaningful subject lines ahead of questions with meaningless subject lines simply because they’re more interesting.
Subject lines such as “HELP REQUIRED QUICKLY” or “NEED URGENT HELP ASAP” contribute nothing of substance to your question and probably won’t get you a faster answer. Ted may even find this rude, because you’re implying that your question should have priority over everyone else’s.
4. Don’t make Ted guess
Remember that Ted can’t read your mind. If you don’t provide enough information, Ted ends up 1) guessing (if you’re lucky, he guesses right), 2) ignoring your question, or 3) asking for more information. Where applicable and when possible, make sure to include the exact error message.
Here’s an example of a “guessing game” question:
Subject: IE
Question: IE is hanging from my script. Is there any solution for it.
Here’s an example of how you should ask instead:
Subject: Internet Explorer hangs when I quim or flob in my script
Question: When I use the following code, Internet Explorer seems to become unresponsive. I tried both quimming and flobbing, but both of these approaches caused the error message ‘800a4005: The object has farbled’. I searched for that error code and error message but I didn’t find anything that relates to this specific situation. What am I doing wrong? [SHORT Code sample follows]
Corollary to the “guessing game” question: Don’t forget to ask your question.
5. If something didn’t work, you have to say how it didn’t work
There is not much to say here other than what Raymond Chen already said. Just saying “it didn’t work” conveys almost no useful information. Remember: We can’t see your screen.
Regarding error messages: The last sentence of the previous paragraph says it all. Please copy and paste the text of the error message. (Avoid screen shots unless Ted asks for one.)
6. Ted is not your personal consultant
Ted is often a volunteer and answers questions in his free time; he is not your personal consultant. Ted likes to help and appreciates thoughtful questions, but remember that he’s not obligated to do your work for you.
For example, consider the following request: “I need a script that quims the flobs.” Possible response: “OK; go ahead and write it, then.” Why should you avoid this kind of request? First, the request is not a question (see #4). Second, you’re explicitly asking Ted to do your work for you. Third, we all understand the importance of quick solutions, but if Ted is feeling generous and gives you a script that quims the flobs, you’re not really learning anything. Numerous times I’ve seen Ted post a generous response such as this, only to have the original poster continue to request ongoing technical support for the script and/or ongoing requests to add features to it. After experiencing this a few times, Ted will probably start to feel less generous.
7. Describe the goal, not the attempted solution
Sometimes, when all you’ve got is a hammer, everything starts to look like a nail. For example: “We have a script to add a domain group to the local Administrators groups on our computers but it doesn’t work on Windows Vista and later. How can we get this script to work?” The underlying question is how to manage the members of the local Administrators groups on domain computers. (One answer: Use the Restricted Groups feature in Group Policy.) Here’s another example of this principle.
8. Have appropriate expectations
Remember that there’s no guarantee that 1) you will get an answer to your question, 2) you will like the answer you get, and 3) what you want to do is even possible. A technical forum does not come with a service-level agreement. (Preemptive response: Yes, I know Raymond is talking about e-mail, but the principle applies.)
9. If your question is answered, don’t forgot to follow up
If your question has been answered (or you have at least been pointed in the right direction), don’t forget to post a follow-up message that your question has been answered. Thanking Ted for his time and expertise is also appropriate.