The style of responses you receive to technical questions depends as much on the way you ask them as on their complexity. This guide will teach you how to ask questions in a way that increases the likelihood of receiving a satisfactory answer.
Before you ask…
Before asking a technical question via email, discussion group, chat, or forum, please do the following:
1. Try to find the answer using a search engine.
2. Try to find the answer by searching the forum.
3. Try to find the answer in the manual.
4. Try to find the answer in the list of frequently asked questions (FAQ).
5. Try to find the answer through testing or experimentation.
6. Ask an experienced friend.
7. If you are a programmer, try to find the answer by analyzing the source code.
When asking a question, indicate from the start that you've already done all this; this will help them understand that you're not some lazy person wasting other people's time. Even better, show what you've learned from your research. Everyone likes to answer people who have demonstrated their ability to understand answers.
Use techniques like searching Google for the text of the error message you receive (also search discussion groups—Google groups, not just web pages). This may lead either directly to documentation on how to fix the error or to a mailing list discussion where the answer may be found. Even if you don't find an answer, saying “I Googled the following query, but didn't find anything helpful” can be helpful when asking for help via email or discussion group.
Prepare your question. Think it through. Superficial questions will likely yield superficial answers, or no answers at all. The more you demonstrate your thought and effort to solve the problem before asking for help, the more likely you are to receive it.
Don't ask the wrong questions. If your question is based on faulty assumptions, you'll likely be given a useless, literal answer, thinking, “What a stupid question…” and hoping that getting what you asked for, rather than what you really need, will teach you something.
Don't feel obligated to answer. No one owes you anything; after all, you didn't pay for these services. You'll get a response if you earn it by asking a substantive, interesting, and thought-provoking question—a question that implicitly provides new insights to the community, rather than simply passively soliciting knowledge from others.
On the other hand, it's a good idea to make it clear from the start that you can and are willing to assist in the solution-development process. Questions like “Can anyone offer any advice?”, “What's missing from my example?”, and “Is there a website worth checking out on this topic?” are more likely to be answered than requests for a precise solution, since you've clearly demonstrated that you'll solve the problem yourself if someone points you in the right direction.
When you ask…
Choose the forum wisely.
Think carefully about where exactly you ask your question. You're more likely to be ignored or written off as a loser if you:
1. Post a question to an off-topic forum
2. Send the most basic question to a forum where complex technical issues are discussed, or vice versa.
3. Cross-post your question to multiple different discussion groups.
4. Send a private email to a stranger who is not personally responsible for resolving your problems.
First, find the appropriate forum. Google and other web search engines will help you with this. Use them to find the project page most closely related to the hardware or software you're having trouble with. This page will typically contain links to frequently asked questions (FAQs), the project's mailing lists, and their archives. This is where you should seek help if your own efforts (including reading these FAQs you've found) are unsuccessful. The project page may also describe or provide a link to a bug reporting procedure. In this case, follow the recommended procedure.
Sending a message to a person or forum you're unfamiliar with is risky, to say the least. For example, don't assume the author of an informative website wants to be your free consultant. Don't make optimistic assumptions that your question will be welcomed—if you're unsure, send it to a different address or refuse to send it at all.
When choosing a forum, discussion group, or mailing list, don't base your decision solely on the name; read the frequently asked questions (FAQ) or rules to ensure your question is on-topic. Read through the posts for a while before posting to get a feel for how things are done there. In fact, before posting your question, it's a good idea to search the discussion group or mailing list archives for keywords related to your problem. This may yield an answer, and if not, it may help you formulate your question better.
In general, the likelihood of getting answers to your questions is higher in a well-chosen public forum than in a private one. There are several reasons for this. One is the number of potential respondents. Another is the size of the audience that will receive the answer. For example, asking a question about a Jeep is more effective on the Jeep forum than on the School of Life forum.
It's clear that experienced programmers and creators of popular software already receive far more irrelevant questions than they'd like. Increasing this influx can sometimes be the last straw—occasionally, contributors to popular projects stop supporting them because they can't bear the accompanying influx of useless emails to their personal addresses.
Keep your message subjects meaningful and specific.
When posting to a mailing list or discussion group, the subject line is a great opportunity to grab the attention of qualified experts with up to 50 characters. Don't waste them on babble like “Please help me!” (not to mention “PLEASE HELP ME!!!!” subjects; messages with such subjects are discarded reflexively). Don't try to impress us with the depth of your suffering; instead, use the allotted space to describe the problem as briefly as possible.
A good message subject convention used by many technical support services is the “object – deviation” pattern. The “object” part specifies what exactly is causing the problem, and the “deviation” part describes the deviation from expected behavior.
For example:
It's stupid to write: Help, I can't see Russian letters.
Better: Cyrillic Font Issue in Windows XP SP2
Even better: Fonts in Windows XP SP2 – incorrect display
Writing a subject line using the “object – deviation” template will help you understand the problem in more detail. When a user receives a message with such a subject line, they'll be able to understand, in general, what exactly you were experiencing and what kind of problem it is.
In general, imagine browsing a list of questions in an archive that only contains subject lines. Make the subject line sufficiently reflect the question so that the next person browsing the archive looking for an answer to a similar question can find the thread that led to the answer, rather than having to resubmit the question.
Keep quoting previous messages to a minimum, just enough for new users to understand what was said.
Simplify sending the response.
Ending a question with the phrase ''Please send your answer to…'' makes it very unlikely that you will get a response.
Requesting email replies on forums is extremely impolite unless you're certain the information might be sensitive (and someone, for some unknown reason, might want to share it with you personally rather than the entire forum). If you want to receive email notification when someone replies to a forum topic, request notification in the forum interface; this feature is supported almost everywhere, through options like “follow thread,” “notify by email,” and so on.
Write in clear language, observing the rules of grammar and vocabulary.
Experiments have shown that people who write carelessly and sloppily are usually just as careless and sloppy in their thoughts and in the code they create (at least, often enough). Answering questions from careless and sloppy thinkers is a thankless task; we'd be better off spending our time doing something else.
Therefore, the clarity and correctness of your question's formulation are crucial. If you don't want to bother yourself with it, we don't want to bother ourselves by paying attention to such questions. Try to formulate your question correctly. It shouldn't be ponderous or formal—in fact, most forums value informal language, rich in slang and humor, used correctly. But your thoughts must be clearly expressed; you must demonstrate at least some signs of thoughtfulness and attention.
Please follow the rules of syntax, punctuation, and capitalization.
Don't write everything in all caps—it's perceived as shouting and considered rude. Writing everything in lowercase isn't much better, as it's difficult to read.
Generally speaking, if you write in a childishly babble-like manner or the ramblings of a madman, your question will likely be ignored. Writing in the style of juvenile “hackers” is utterly hopeless and guarantees silence (or, at best, a dose of disdain and sarcasm).
If you're sending a question not to the forum, but to the support service's email address or to a “guru” you know, please send your questions in a format that everyone understands.
If you make a question artificially difficult to read, you increase the likelihood that someone will answer an easier-to-read question instead. Therefore:
1. Send your message in plain text, not HTML.
2. MIME attachments are usually perfectly acceptable, but only if they contain actual content (e.g., source code or a patch file is attached), and are not simply automatically generated by the email client (e.g., being another copy of the email, but in HTML format).
3. Try to avoid sending documents in closed, proprietary formats like Microsoft Word or Excel. Many people resent having to deal with them.
If you use a GUI email client (such as Netscape Messenger, MS Outlook, and similar programs), be aware that it may violate these rules when using default settings. Most such clients have a menu command like “View Source.” Use it to verify that the message being sent is plain text, without any unnecessary spam.
This isn't the end of it. Stay tuned for the next part of this guide, which will explain how to write the message itself.
Describe the problem accurately and in detail.
1. Carefully and clearly describe the symptoms of the problem or error you have discovered.
2. Describe the environment in which it occurs (machine, OS, application, etc.) Specify the distribution and release.
3. Describe the research you did to try to understand the problem before asking the question.
4. Describe the steps you took to diagnose and isolate the problem before asking the question.
5. Describe any recent changes to your computer configuration or software that may be relevant to the case.
Do your best to anticipate potential questions from respondents and answer them in advance in your request for help.
Volume does not mean accuracy.
Be precise and informative. Simply pasting a large amount of code or data into a query isn't enough. If you have a large, complex test case that causes a program error, try to reduce it as much as possible.
This is useful for at least three reasons. First, demonstrating effort to simplify the question increases the likelihood of receiving an answer. Second, simplifying the question increases the likelihood of receiving a useful answer. Third, by refining the error message, you may discover a solution or workaround yourself.
When you encounter problems with software, don't claim to have found a bug unless you're absolutely certain. Tip: If you can't provide a source code patch that solves the problem or a test case for a previous version demonstrating the incorrect behavior, you're likely not confident enough in your claim.
Keep in mind that many other users haven't encountered this problem. Otherwise, you would have already discovered it while reading the documentation or searching the web (you did that before making such claims, right?). This means it's likely you're doing something wrong, not the software.
Software creators put a lot of effort into making sure their software works as well as possible. If you claim to have found a bug, you're implying they've done something wrong, and they're almost certainly not going to like that—even if you're right. Putting “bug” or “Error” in the subject line of a message is especially undiplomatic.
When asking a question, it's best to describe the problem assuming you're doing something wrong, even if you're absolutely certain you've found a bug. If it really is a bug, you'll see it in the answer. Try to behave in a way that will make the people supporting the program want to apologize to you if they find a real bug, rather than making you feel the need to apologize for your own stupidity.
Public self-humiliation is no substitute for doing homework.
Some, having realized that they shouldn't be rude or arrogant when demanding an answer, opt for the opposite extreme—self-deprecation. “I know I'm a beginner, a loser, and a complete noob, but…” This distracts from the essence and serves no purpose, especially when combined with vagueness in the description of the actual problem.
Don't waste your time, or ours, relying on pity. Present the facts and your question as clearly as possible. This will make a much better statement than through self-deprecation.
Sometimes web forums have special areas for beginner questions. If you feel like the question is only for a beginner, ask it there. But don't humiliate yourself there either.
Describe the symptoms of the problem in chronological order.
The most important information for determining the cause of an issue often relates to the events immediately preceding it. Therefore, it's essential to accurately describe what you were doing and what the car was doing right before the problem occurred.
If the post is quite long (more than a page), it makes sense to state the problem upfront and then provide a chronological sequence of actions leading up to it. This way, readers will know what to look for when reviewing the message.
Describe the goal precisely and in detail, not a separate step.
If you're trying to figure out how to do something (rather than reporting a bug), start by describing the goal. Only then describe the specific step you couldn't complete.
Often, people seeking technical assistance have a high-level goal in mind and become fixated on one of what they believe are possible paths to achieving it. They ask for help completing one step, not realizing they've chosen the wrong path. Figuring this out can take a lot of effort.
Silly: How do I make the color picker dialog in FooDraw accept a hexadecimal RGB value?
Reasonable: I'm trying to replace the color table in an image with the values I need. Currently, the only way I can see to do this is by editing each table slot, but I can't specify a hexadecimal RGB value in the FooDraw color picker dialog.
The second version of the question is reasonable. It allows for an answer that suggests a more appropriate solution.
Don't ask to reply to a personal email address.
Problem solving should be a participatory, transparent process, whereby an initial attempt at an answer can and should be corrected if someone more knowledgeable notices that it is incomplete or incorrect. Furthermore, those who respond are partly rewarded by having their expertise and knowledge recognized by their peers.
When you ask for a personal answer, you interfere with both the decision-making process and the reward. Don't do this. Responding personally is the responder's choice—and if they do, it's usually because they consider the question too poorly worded or obvious to be of interest to others.
There is one minor exception to this rule. If you anticipate receiving many similar responses to your question, remember the magic words: “Send your answer to me, and I'll summarize the responses in a discussion group post.” It's very kind of you to try to protect the discussion group or mailing list from essentially identical messages, but you must keep your promise and send a summary.
Ask clear and precise questions.
Open-ended questions usually require unlimited time to answer. The people most likely to give you a useful answer are also the busiest (particularly because they do most of their own work). Such people are jealous of their time and therefore often don't respond well to open-ended questions.
The likelihood of receiving a helpful response increases if you clearly state what you want from your responders (provide links, send code, verify your solution, etc.). This will focus the responders' efforts and implicitly set a limit on the time and effort they will have to expend to help you. This is a good thing.
To understand the world experts live in, you need to treat their knowledge as an abundant resource and their time as a very limited one. The less time you implicitly demand, the more likely you are to get an answer from a truly competent and engaged expert.
Therefore, it makes sense to narrow your question to minimize the time it takes the expert to resolve it. But this is often not the same as simplifying the question. For example, asking, “Can you point me to a good description of X?” is usually much more reasonable than asking, “Please explain X to me.” If you have a problem with broken code, it's more reasonable to ask for an explanation of what's wrong rather than asking for bug fixes.
To be continued…
