How To Ask Questions The Smart Way

Introduction

In the world of hackers, when you pose a technical question, whether you ultimately get a useful answer often depends on how you ask and follow up. This guide will teach you how to ask questions correctly to get satisfactory answers.

Not just hackers, now that open source software is quite prevalent, you can often get good answers from other experienced users, which is a good thing; users are often more tolerant of problems that beginners encounter than hackers are. However, treating experienced users as hackers and using the methods mentioned in this guide to communicate with them is also the most effective way to get satisfactory answers from them.

First, you should understand that hackers love challenging problems, or good questions that stimulate their thinking. If we weren’t like this, we wouldn’t be the people you want to ask. If you give us a good question worth chewing over, we’ll be grateful. Good questions are stimulation, are gifts. Good questions can improve our understanding and often expose problems we never realized or thought about before. For hackers, “Good question!” is a sincere compliment.

Nevertheless, hackers have a bad reputation for despising or arrogantly facing simple questions, which sometimes makes us seem hostile to newbies and the ignorant, but that’s not really the case.

We don’t hide our contempt for those who are unwilling to think or don’t do what they should before asking. Those people are time killers—they just want to take, never give, consuming time we could use on more interesting problems or people more worthy of answers. We call such people losers (for historical reasons, we sometimes spell it lusers).

We realize many people just want to use the software we write, they have no interest in learning technical details. For most people, computers are just tools, a means to an end. They have their own lives and more important things to do. We understand this and never expect everyone to be interested in these technical problems that fascinate us. Nevertheless, our style of answering questions is directed at those who are genuinely interested and willing to actively participate in solving problems, this won’t change, and shouldn’t change. If even this changed, we would be reducing our efficiency at what we do best.

We are (largely) volunteers, taking time from busy lives to answer questions, and are often flooded with questions. So we ruthlessly filter out some topics, especially discarding those who look like losers, to use time more efficiently to answer winners' questions.

If you resent our attitude, high-handedness, or excessive arrogance, try putting yourself in our shoes. We’re not asking you to yield to us—in fact, most of us are very happy to communicate with you as equals, as long as you make a small effort to meet basic requirements, we’ll welcome you into our culture. But helping those who won’t help themselves is inefficient. Ignorance is fine, but playing the fool is not.

So, you don’t need to be technically proficient to get our attention, but you must show traits that can lead you to become proficient—alertness, thoughtfulness, observation, willingness to actively participate in solving problems. If you can’t do these things that make you stand out, we suggest you spend some money to sign a technical support service contract with a commercial company, rather than asking hackers to help you for free.

If you decide to ask us for help, of course you don’t want to be seen as a loser, or become one. The best way to get fast and effective answers immediately is to ask questions like a winner—smart, confident, with problem-solving ideas, just occasionally needing a little help on specific issues.

(Improvements to this guide are welcome. You can email your suggestions to esr@thyrsus.com or respond-auto@linuxmafia.com. However, please note that this article is not a general guide to netiquette, and we usually reject suggestions that don’t help get useful answers in technical forums.)

Before You Ask

Before you prepare to ask a technical question via email, newsgroup, or chat room, please do the following first:

1. Try searching for answers in old posts on the forum where you’re preparing to ask.
2. Try searching online to find answers.
3. Try reading the manual to find answers.
4. Try reading the FAQ (Frequently Asked Questions) file to find answers.
5. Try checking or testing yourself to find answers.
6. Ask strong friends around you to find answers.
7. If you’re a program developer, try reading the source code to find answers.

When you ask your question, please indicate first that you’ve done the above efforts; this will help establish that you’re not a freeloader wasting others’ time. It would be even better if you can also express what you learned during these efforts, because we’re more willing to answer questions from those who show they can learn from answers.

Using certain strategies, like first Googling various error messages you encounter (searching both Google Groups and web pages), this will likely directly find documents or mailing list threads that can solve the problem. Even without results, adding a sentence like I searched the following phrases in Google but didn't find anything useful when seeking help in mailing lists or newsgroups is a good thing, even if it just shows what help search engines can’t provide. Doing this (adding the searched strings) also allows others with similar problems to be guided to your question by search engines.

Don’t rush, don’t expect a few seconds of Google searching to solve a complex problem. Before asking experts for help, read the FAQ again, relax, sit comfortably, and spend some time thinking about the problem. Trust us, they can see from your question how much reading and thinking you’ve done, and if you come prepared, you’re more likely to get an answer. Don’t throw out all questions at once just because your first search didn’t find an answer (or found too many answers).

Prepare your question, then think it through carefully, because hasty questions only get hasty answers, or no answers at all. The more you can show the efforts you made to solve the problem before seeking help, the more likely you are to get substantive help.

Be careful not to ask the wrong question. If your question is based on wrong assumptions, some random hacker (J. Random Hacker) will probably think stupid question... while giving you a meaningless literal answer, hoping you’ll learn from the answer to the question (not the answer you wanted to get).

Never assume you’re entitled to an answer, you’re not; you haven’t. After all, you haven’t paid anything for this service. You will earn an answer, by asking substantive, interesting, thought-provoking questions—a question with potential to contribute to community experience, not just passively索取 knowledge from others.

On the other hand, showing you’re willing to do something in the process of finding an answer is a very good start. Can anyone give a hint?, What's missing in my example? and Where should I check are more likely to get responses than Please post the exact process I need. Because you show that as long as someone can point in the right direction, you have the ability and determination to complete it.

When You Ask

Choose the Right Forum Carefully

Be careful about where you ask your question. If you do the following, you’re likely to be ignored or seen as a loser:

• Posting your question on a forum that’s off-topic.
• Posting very elementary questions on forums discussing advanced technical issues; or vice versa.
• Cross-posting the same question on too many different newsgroups.
• Sending private email to people who are neither acquaintances nor obligated to solve your problem.

Hackers will filter out questions posted in wrong places to protect their communication channels from being flooded with irrelevant things. You don’t want this to happen to you.

Therefore, the first step is to find the right forum. Again, Google and other search engines are your friends, use them to find the websites most relevant to the hardware or software problems you’re encountering. Usually there are links to FAQs, mailing lists, and related documentation. If your efforts (including reading the FAQ) don’t yield results, there may be bug-reporting processes or links on the website, if so, go check them out.

Sending email to strangers or forums is likely the riskiest thing. For example, don’t assume that an author of a content-rich webpage would want to act as your free consultant. Don’t be too optimistic about whether your question will be welcome—if you’re not sure, send elsewhere, or don’t send at all.

When choosing forums, newsgroups, or mailing lists, don’t trust names too much, first check the FAQ or license to figure out if your question is relevant. Before posting, browse through existing topics, this can give you a feel for the culture there. In fact, searching for keywords related to your question in the history of newsgroups or mailing lists beforehand is an excellent idea, maybe you’ll find the answer. Even if not, it can help you formulate better questions.

Don’t spray all help channels like a machine gun, this is as unpleasant as shouting. Go one by one.

Figure out your topic! One of the most typical mistakes is asking questions about Unix or Windows operating system program interfaces in a forum dedicated to cross-platform portable languages, packages, or tools. If you don’t understand why this is a big mistake, you’d better not ask anything until you figure out the differences.

Generally speaking, asking questions in carefully selected public forums is more likely to get useful answers than asking the same question in private forums. There are several reasons for this: one is the number of potential responders, the other is the size of the audience. Hackers are more willing to answer questions that can help many people.

Understandably, seasoned hackers and authors of some popular software are receiving too many misdirected messages. Like the straw that breaks the camel’s back, your joining might push things to the extreme—it’s happened several times, some popular software authors have withdrawn from supporting their own software because the accompanying flood of useless emails into their private inboxes became unbearable.

Stack Overflow

Search, then ask on Stack Exchange.

In recent years, the Stack Exchange community has become the main channel for answering technical and other questions, especially for open source projects.

Because Google indexing is instant, search on Google before looking at Stack Exchange. There’s a high probability someone has already asked a similar question, and Stack Exchange sites are often among the top search results. If you don’t find any answers on Google, then go to specific topic-related sites. Using tags can further narrow your search results.

Stack Exchange has grown to over one hundred sites, here are the most commonly used ones:

• Super User is for general computer questions, if your question isn’t about code or programming, just things like network connections, go here.
• Stack Overflow is for programming-related questions.
• Server Fault is for server and network administration related questions.

Websites and IRC Forums

Local user groups, or the Linux distribution you’re using, might be promoting their web forums or IRC channels and providing help for beginners (in some non-English countries, beginner forums might still be mailing lists), these places are good first choices for asking questions, especially when you think you might be encountering relatively simple or common problems. Ad-sponsored IRC channels are openly welcoming places to ask questions, usually with immediate responses.

In fact, if a program’s problem only occurs in versions provided by specific Linux distributions (this is common), it’s best to ask in that distribution’s forum or mailing list first, then ask in the program’s own forum or mailing list. (Otherwise) the project’s hackers might just reply “use our version.”

Before posting in any forum, check if there’s a search function. If there is, try searching for a few keywords of the problem, this might help. If you’ve already done a general web search before this (which you should do), search the forum again anyway, search engines might not have had time to index all the forum’s content.

There’s a growing trend to provide user support services through forums or IRC channels, while email is mostly reserved for communication between project developers. So it’s best to seek help related to the project in forums or IRC first.

When using IRC, it’s best not to post very long problem descriptions first, some people call this channel flooding. It’s better to start chatting with a one-sentence problem description.

Second Step, Use Project Mailing Lists

When a project provides a developer mailing list, ask the list rather than individual members, even if you’re sure they can best answer your question. Check the project’s documentation and homepage to find the project’s mailing list and use it. There are several good reasons for this approach:

• Any question good enough to need to be asked to individual developers will also benefit the entire project group. Conversely, if you think your question is too stupid for the entire project group, that’s not a reason to harass individual developers.
• Asking the list can distribute the burden on developers, individual developers (especially project leaders) might be too busy to answer your question.
• Most mailing lists are archived, and those archived contents will be indexed by search engines. If you ask the list and get an answer, others can find your question and answer through web search in the future, without asking again.
• If certain questions are asked frequently, developers can use this information to improve documentation or the software itself to make it clearer. If asked privately, no one can see the complete picture of the most common problems.

If a project has both “user” and “developer” (or “hacker”) mailing lists or forums, and you won’t be touching the source code, then ask on the “user” list or forum. Don’t assume you’ll be welcome on the developer list, those people will mostly see your question as noise interfering with their development.

However, if you’re sure your question is special, and there’s no response on the “user” list or forum for several days, you can try asking on the “developer” list or forum. It’s recommended that you observe quietly for a few days before posting to understand how things work there (in fact, this is a good idea for participating in any private or semi-private list).

If you can’t find a project’s mailing list and can only find the project maintainer’s email address, go ahead and send to them. Even in this case, don’t assume the project mailing list doesn’t exist. In your email, please state that you’ve tried but couldn’t find a suitable mailing list, and mention you don’t mind your email being forwarded to others (many people think private emails shouldn’t be public even if there’s nothing secret. By allowing your email to be forwarded to others, you give the relevant person a choice in handling your email).

Use Meaningful and Descriptive Subject Lines

In mailing lists, newsgroups, or forums, a subject line within about 50 characters is a good opportunity to grab the attention of senior experts. Don’t waste this opportunity with chattering like help me, begging, urgent (let alone help!!!! which is offensive, using such titles will be reflexively ignored). Don’t try to impress us with your pain level, instead use an extremely concise description in this space to pose the question.

A good subject line example is the object — deviation style description, which is how many technical support organizations work. In the object part, point out which thing or group of things has the problem, and in the deviation part, describe what’s inconsistent with expected behavior.

Stupid question: Help! My laptop display isn’t working properly!

Smart question: X.org 6.8.1 mouse cursor deforms, certain brand graphics card MV1005 chipset.

Smarter question: X.org 6.8.1 mouse cursor, under certain brand graphics card MV1005 chipset environment - deforms.

The process of writing an object — deviation style description helps you organize detailed thinking about the problem. What’s affected? Just the mouse cursor or other graphics too? Only in X.org’s X version? Or only in version 6.8.1? Is it for a certain brand graphics chipset? Or just the MV1005 model? A hacker can immediately understand your environment and the problem you’re encountering with just a glance.

In summary, imagine you’re searching in an archive discussion thread index that only shows subject lines. Making your subject line better reflect the problem allows the next person searching for similar problems to focus on this thread without asking the same question again.

If you want to ask a question in a reply, remember to modify the content subject line to indicate you’re asking a question, a subject line that looks like Re: test or Re: new bug is hard to get enough attention. Also, without affecting coherence, appropriately quote and trim previous content to leave clues for new readers.

For discussion threads, don’t just click reply to start a brand new discussion thread, this will limit your audience. Because some mail reading programs, like mutt, allow users to sort by discussion thread and hide messages by folding threads, people doing this will never see your message.

Just changing the subject line isn’t enough. mutt and some other mail reading programs will also check information other than the mail subject line to assign it to a thread. So it’s better to send a completely new email.

On web forums, good questioning style is slightly different, because discussion threads are tightly bound to specific information, and usually can’t see content outside the thread, so asking through reply rather than changing the subject is acceptable. Not all forums allow separate subject lines in replies, and even if done, basically no one will look. However, asking through reply is itself an ambiguous practice, because they’ll only be read by people currently viewing that subject line. So, unless you only want to ask among the currently active crowd in that discussion thread, it’s better to start a new thread.

Make Questions Easy to Reply

Ending your question with Please send your reply to... will mostly prevent you from getting an answer. If you think spending a few seconds setting up a reply address in your mail client is troublesome, we also think spending a few seconds thinking about your question is more troublesome. If your mail program doesn’t support this, get a better one; if the operating system doesn’t support such mail programs, get a better one too.

In forums, asking for email replies is very rude, unless you think the reply information might be sensitive (someone might want only you, not the whole forum, to know the answer for some unknown reason). If you just want to get email reminders when someone replies to the discussion thread, you can ask the web forum to send them to you. Almost all forums support functions like track this thread or send email reminder when replied.

Use Clear, Correct, Precise, and Grammatically Correct Language

We’ve found from experience that careless questioners usually also write programs and think carelessly (I can guarantee this). Answering questions from careless people isn’t worthwhile, we’d rather spend time elsewhere.

Correct spelling, punctuation, and capitalization are important. Generally, if you think it’s too troublesome and don’t want to care about these, we also think it’s troublesome and don’t want to care about your question. Spend a little extra effort to consider your words, there’s no need to be too stiff and formal—in fact, hacker culture values the ability to accurately use informal, slang, and humorous language. But it must be accurate, and show signs that you’re thinking and paying attention to the problem.

Spell correctly, use punctuation and capitalization, don’t confuse its with it's, loose with lose, or discrete with discreet. Don’t use ALL CAPS, this is seen as rude shouting (all lowercase isn’t much better either, because it’s hard to read. Alan Cox might be able to do this, but you can’t).

More colloquially, if you write like a semi-literate person, you probably won’t get attention. Don’t use instant messaging abbreviations or Martian language, like simplifying 的 to d will make you look like a noob saving words to type fewer keys. Even worse, if you write like a child’s scribbles, that’s absolutely looking for death, you can be sure no one will pay attention to you (or at most give you a lot of criticism and sarcasm).

If you’re asking in a forum in a non-native language, you can make small spelling and grammar mistakes, but never be careless in thinking (yes, we can usually tell the difference). Also, unless you know what language the responder uses, please write in English. Busy hackers will generally directly delete messages written in languages they can’t understand. On the internet, English is the universal language, writing in English can minimize the possibility of your question being directly deleted before being read.

If English is your second language, it’s good to hint to potential responders that you have potential language difficulties:

English is not my native language; please excuse typing errors.

• English is not my native language, please forgive my typos or grammar.

If you speak $LANGUAGE, please email/PM me;
I may need assistance translating my question.

• If you speak some language, please email/private message me; I need someone to help me translate my question.

I am familiar with the technical terms,
but some slang expressions and idioms are difficult for me.

• I’m familiar with technical terms, but I’m not very familiar with slang or special usages.

I’ve posted my question in $LANGUAGE and English.
I’ll be glad to translate responses, if you only use one or the other.

• I’ve written my question in some language and English, if you only answer in one language, I’ll be happy to translate it to the other.

Use Easy-to-Read and Standard File Formats to Send Questions

If you artificially make your question hard to read, it will mostly be ignored, people prefer reading easy-to-understand questions, so:

• Use plain text instead of HTML (turning off HTML isn’t hard).
• Using MIME attachments is usually okay, provided there’s real content (like attached source code or patches), not just templates generated by mail programs (like just copies of the letter content).
• Don’t send mail where a paragraph is one sentence but auto-wraps into multiple lines (this makes replying to parts of content very difficult). Assume your readers are reading mail on 80-character-wide terminals, it’s best to set your line break point under 80 characters.
• However, for some special files don’t set fixed width (like log file copies or session records). Data should be included as-is, giving responders confidence they’re seeing the same thing you’re seeing.
• In English forums, don’t send messages using Quoted-Printable MIME encoding. This encoding might be necessary for posting non-ASCII languages, but many mail programs don’t support this encoding. When they handle line breaks, those =20 symbols scattered throughout the text are both ugly and distracting, and might even break the semantics of the content.
• Absolutely, never expect hackers to read documents written in closed formats, like Microsoft Word or Excel files. Most hackers react to this like someone dumping steaming pig manure at your doorstep. Even if they can handle it, they hate doing so.
• If you’re sending email from a Windows computer, turn off Microsoft’s stupid smart quotes feature (from [Options] > [Proofing] > [AutoCorrect Options], uncheck the smart quotes radio button), to avoid scattering garbage characters throughout your email.
• In forums, don’t abuse emoticons and HTML features (when they’re provided). One or two emoticons are usually fine, but fancy colored text tends to make people think you’re incompetent. Excessive use of emoticons, colors, and fonts makes you look like a giggling little girl. This is usually not a good idea, unless you’re only interested in sex rather than answers.

If you use a graphical user interface mail program (like Microsoft Outlook or similar), note that their default settings might not meet these requirements. Most such programs have a menu-based view source command, use it to check emails in your sent folder to ensure what’s sent is plain text without strange characters.

Describe the Problem Precisely and Substantively

• Carefully and clearly describe the symptoms of your problem or bug.
• Describe the environment where the problem occurs (machine configuration, operating system, applications, and related information), provide the distributor’s distribution and version number (like: Fedora Core 4, Slackware 9.1, etc.).
• Describe how you researched and understood this problem before asking.
• Describe the diagnostic steps taken to determine the problem before asking.
• Describe what recent hardware or software changes might be relevant.
• As much as possible, provide a method to reproduce this problem in a controlled environment.

Try to anticipate how a hacker might question you, and pre-answer the questions hackers might encounter before you ask.

Among the above points, when you’re reporting what you think might be a problem in code, giving hackers an environment to reproduce your problem is especially important. When you do this, your chances and speed of getting an effective answer will greatly increase.

Simon Tatham wrote an excellent article titled “How to Report Bugs Effectively”. Highly recommended reading.

Quality Over Quantity

You need to provide precise and substantive information. This doesn’t mean you should simply transcribe piles of error code or data completely into your question. If you have a large and complex test case that can reproduce the program crash scenario, try to trim it as small as possible.

This has at least three benefits.
First, it shows you’ve made efforts to simplify the problem, which can increase your chances of getting an answer;
Second, simplifying the problem makes you more likely to get useful answers;
Third, in the process of refining your bug report, you might find the solution or workaround yourself.

Don’t Claim You Found a Bug Without Good Reason

When you encounter problems using software, unless you’re very, very certain, don’t claim you found a bug. Hint: Unless you can provide source code patches that solve the problem, or provide regression tests showing incorrect behavior in the previous version, you’re probably not completely certain. This also applies to web pages and documents, if you (claim to) have found a bug in the document, you should be able to provide corrections or alternative documents for the relevant location.

Remember, there are many other users who haven’t encountered the problem you found, otherwise you would have discovered it when reading documents or searching the web (you did these before complaining, right?). This also means it’s very likely you made a mistake rather than there being a problem with the software itself.

People who write software work very hard to make it as perfect as possible. If you claim you found a bug, you’re questioning their ability, even if you’re right, it might offend some of them. This is especially serious when you shout Bug in the subject line.

When asking questions, even if you’re privately very sure you’ve found a real bug, it’s best to write as if you did something wrong. If there really is a bug, you’ll see this in the reply. Doing this, if there really is a bug, the maintainer will apologize to you, which is better than annoying people and then owing them an apology.

Groveling Doesn’t Replace Your Homework

Some people understand they shouldn’t be rude or arrogant when asking questions and demanding answers, but they choose the opposite extreme—groveling: I know I'm just a pathetic newbie, a loser, but.... This is both disturbing and useless, especially annoying when accompanied by vague descriptions of the actual problem.

Don’t waste your and my time with primitive primate tricks. Instead, describe the background conditions and your problem situation as clearly as possible. This positions you better than groveling.

Sometimes web forums have sections specifically for beginners to ask questions, if you really think you’ve encountered a beginner’s problem, go there, but still don’t grovel so much.

Describe Problem Symptoms, Not Your Guesses

Telling hackers what you think caused the problem doesn’t help. (If your inference was that effective, would you need to ask others for help?), so be sure to tell them the symptoms of the problem exactly, not your explanations and theories; let hackers speculate and diagnose. If you think stating your guesses is important, clearly indicate these are just your guesses and describe why they don’t work.

Stupid Question

I keep getting SIG11 errors when compiling the kernel,
I suspect a flying wire is bridging the motherboard traces, how should I check this best?

Smart Question

My assembled computer has an FIC-PA2007 motherboard with AMD K6/233 CPU (VIA Apollo VP2 chipset),
256MB Corsair PC133 SDRAM memory, when compiling the kernel, SIG11 errors occur frequently after 20 minutes from boot,
but the same problem never occurred in the first 20 minutes. Restarting doesn’t help, but shutting down for a night allows it to work for another 20 minutes.
All memory has been replaced, no effect. The relevant part of the standard compilation log is as follows…

Since the above point seems difficult for many people to follow, here’s a phrase to remind you: All diagnostic experts come from Missouri. The official motto of the U.S. State Department is: Show me (from Congressman Willard D. Vandiver’s 1899 speech: I come from a land that produces corn, cotton, cockleburs, and Democrats, and eloquent speeches neither convince me nor satisfy me. I'm from Missouri, you have to show me.) For diagnosticians, this isn’t doubt, but a real and useful need to see raw evidence as consistent as possible with what you see, not your guesses and inductive conclusions. So, show us generously!

List Problem Symptoms in Chronological Order

The series of operations before the problem occurs is often the most helpful clue to finding the problem. Therefore, your explanation should include your operation steps, and the machine and software’s reactions, until the problem occurs. In command-line situations, providing an operation log (like those generated by script tools), and quoting relevant lines (like 20 lines) of the log will be very helpful.

If the crashed program has diagnostic options (like -v verbose switch), try selecting these options that can add debugging information to the log. Remember, more doesn’t equal better. Try to select appropriate debugging levels to provide useful information rather than drowning readers in garbage.

If your explanation is very long (like more than four paragraphs), it helps to briefly describe the problem at the beginning, then detail it in chronological order. This way hackers know what to pay attention to when reading your log.

Describe the Goal, Not the Process

If you want to figure out how to do something (rather than reporting a bug), describe your goal at the beginning, then state the specific steps where you’re stuck.

People seeking technical help often have a higher-level goal in mind, and they get stuck on a specific path they think will achieve that goal, then come ask how to proceed, without realizing the path itself has problems. The result requires great effort to resolve.

Stupid Question

How can I get hexadecimal RGB values from a certain drawing program’s color picker?

Smart Question

I’m trying to replace an image’s color table with one I’ve chosen, the only method I know now is to edit each color table slot,
but I can’t get hexadecimal RGB values from a certain drawing program’s color picker.

The second way of asking is smarter, you might get a reply like suggest using another more suitable tool.

Don’t Ask for Private Email Replies

Hackers believe the problem-solving process should be public and transparent, during which if more experienced people notice incomplete or inappropriate parts, the initial reply can and should be corrected. At the same time, as helpers, they can get some reward, which is having their ability and knowledge seen by other peers.

When you ask for private replies, this process and reward are both suspended. Don’t do this, let the responder decide whether to answer privately—if they do so, it’s usually because they think the question is written too poorly or is too shallow to be of interest to others.

There’s a limited exception to this rule, if you’re sure the question might attract many similar replies, then the magic question sentence would be Email me and I'll summarize the replies for the forum. Trying to rescue mailing lists or newsgroups from floods of similar replies is very polite—but you must keep your promise.

Clearly Express Your Question and Needs

Endless questions are nearly endless time black holes. The people most likely to give you useful answers are usually also the busiest people (they’re busy because they personally complete most of the work). Such people have considerable aversion to uncontrolled time black holes, so they also tend to dislike endless questions.

If you clearly express what you need the responder to do (like providing guidance, sending a piece of code, checking your patch, or other things), you’re most likely to get useful answers. Because this sets an upper limit on time and energy, making it easier for responders to concentrate on helping you. Doing this is great.

To understand the world experts live in, imagine professional skills as an abundant resource, while response time is a scarce resource. The less time you ask them to contribute, the more likely you are to get answers from truly professional and busy experts.

So, define your problem to minimize the time experts need to spend identifying your problem and answering, this technique is quite helpful for getting useful answers—but this technique is usually different from simplifying the problem. Therefore, asking I want to better understand X, can you point me to some good explanations? is usually better than asking Can you explain X?. If your code doesn’t work, usually asking others to look at what’s wrong is wiser than asking others to fix it for you.

When Asking Questions About Code

Don’t ask others to help debug problematic code without hinting at where to start. Posting hundreds of lines of code, then saying: It doesn't work will get you completely ignored. Posting just a few dozen lines of code, then saying: After line 7, I expected it to show <x>, but what actually appeared was <y> is more likely to get a response.

The most effective way to describe program problems is to provide the most minimal bug-demonstrating test case. What is the most minimal test case? It’s a microcosm of the problem; a small program fragment that just shows the program’s abnormal behavior, without other distracting content. How to make the most minimal test case? If you know which line or section of code causes abnormal behavior, copy it and add enough code to reproduce the situation (for example, enough to let this code be compiled/interpreted/processed by the application). If you can’t reduce the problem to a specific block, copy the code and remove parts that don’t affect producing the problem behavior. In short, the smaller the test case, the better (see the Quality Over Quantity section).

Generally speaking, getting a fairly minimal test case isn’t easy, but always trying to do so first is a good habit. This approach can help you understand how to solve the problem yourself—and even if your attempt fails, hackers will see you’ve made efforts in the process of trying to get answers, which can make them more willing to cooperate with you.

If you just want others to help review your code, say so at the beginning of the letter, and definitely mention which part you think needs special attention and why.

Don’t Post Homework Questions

Hackers are very good at distinguishing which questions are homework-style questions; because most of us have solved such problems ourselves. Similarly, these problems should be solved by you, you’ll learn from them. You can ask for hints, but don’t ask for complete solutions.

If you suspect you’ve encountered a homework-style problem but still can’t solve it, try asking in user groups, forums, or (as a last resort) the project’s user mailing list or forum. Although hackers will notice, some experienced users might still give you hints.

Remove Meaningless Question Sentences

Avoid ending questions with meaningless phrases like Can anyone help me? or Is there an answer to this?.

First: If your description of the problem isn’t very good, asking this is adding unnecessary detail.

Second: Because this is adding unnecessary detail, hackers will be annoyed with you—and usually respond with logically correct but meaningless answers to show their contempt, for example: Yes, someone can help you or No, there's no answer.

Generally, avoid using yes or no, true or false, is there or isn't there type questions, unless you want yes or no type answers.

Even If You’re Urgent, Don’t Write Urgent in the Subject

This is your problem, not ours. Claiming urgent is very likely to backfire: most hackers will directly delete questions that rudely and selfishly attempt to get immediate attention. Even worse, the word urgent (or other attention-seeking subject lines) usually gets filtered by spam filters—people you hope will see your question might never see it.

There’s a half-exception: if you’re somewhere very high-profile that would excite hackers, it might be worth doing. In this case, if you have time pressure and mention this politely, people might be interested in answering faster.

Of course, this is risky, because what excites hackers is probably different from what excites you. For example, sending such a subject line from NASA’s International Space Station is fine, but sending it with self-satisfying charitable acts or political causes definitely won’t work. In fact, posting something like Urgent: Help me save this fluffy little seal! will definitely get you ignored or annoy hackers, even if they think fluffy little seals are important.

If you find this incredible, you’d better read the rest of this guide a few more times until you understand before posting.

Politeness Never Hurts, and Sometimes Helps

Be polite, use please and thank you for your attention, or thank you for your care. Let everyone know you’re grateful for them spending time providing free help.

Frankly, this isn’t more important than being clear, correct, precise, and grammatically correct and avoiding proprietary formats (and can’t replace them). Hackers generally prefer reading somewhat abrupt but technically sharp bug reports over polite but vague reports. (If this puzzles you, remember we evaluate the value of questions by what they can teach us.)

However, if you have a string of problems to solve, being polite will definitely increase your chances of getting useful responses.

(We notice that since this guide was published, the only serious defect feedback from senior hackers was about the pre-thanking part. Some hackers feel thanks in advance implies no need to thank anyone afterwards. Our suggestion is either say thanks in advance first, then thank responders afterwards, or express gratitude differently, like using thank you for your attention or thank you for your care.)

After the Problem Is Solved, Add a Brief Follow-up

After the problem is solved, send a note to everyone who helped you, let them know how the problem was solved, and thank them again. If the problem attracted wide attention in newsgroups or mailing lists, it’s appropriate to post a note there.

The ideal way is to reply to the original question topic, and include fixed, solved, or other equivalent obvious markers in the subject line. In busy mailing lists, a potential responder seeing discussion threads Problem X and Problem X - Solved will understand there’s no need to waste time anymore (unless they personally find Problem X interesting), and can use that time to solve other problems.

The follow-up note doesn’t need to be long or deep; a simple sentence like Hello, turns out it was a network cable problem! Thanks everyone – Bill is better than saying nothing. In fact, unless the conclusion is really technical, a short and cute summary is better than a long essay. Describe how the problem was solved, but there’s no need to recount the problem-solving process.

For deep problems, posting a summary of debugging logs is helpful. Describe the final state of the problem, explain what solved it, after that point out avoidable blind spots. The avoidable blind spots part should be placed after the correct solution and other summary materials, don’t turn this information into a detective novel. Listing the names of those who helped you will make you more friends.

Besides being polite and substantive, this type of follow-up also helps others find the solution that actually solved your problem in mailing lists/newsgroups/forums, letting them benefit too.

At minimum, this follow-up helps give everyone who participated in assistance a sense of satisfaction from the problem being solved. If you’re not a technical expert or hacker yourself, trust us, this feeling is very important for those masters or experts you asked for help. Unresolved problems are frustrating; hackers are eager to see problems solved. Good deeds are rewarded, satisfy their craving, and you’ll taste the sweetness next time you ask.

Think about how to avoid others encountering similar problems in the future, ask yourself whether writing a document or adding a FAQ would help. If so, send them to the maintainer.

Among hackers, this kind of good follow-up behavior is actually more important than traditional etiquette, and is how you build reputation by treating others well, which is a very valuable asset.

How to Interpret Answers

RTFM and STFW: How to Know You’ve Completely Messed Up

There’s an ancient and sacred tradition: if you receive a RTFM (Read The Fucking Manual) response, the responder thinks you should read the fucking manual. Of course, basically they’re right, you should read it.

RTFM has a younger relative. If you receive a STFW (Search The Fucking Web) response, the responder thinks you should search the fucking web. That person is probably right too, go search. (A gentler way to say this is Google is your friend!)

In forums, you might also be asked to crawl through the forum’s old posts. In fact, someone might even kindly provide you with a discussion thread that previously solved this problem. But don’t rely on this care, you should search old posts before asking.

Usually, people who answer with one of these two phrases will give you a manual containing the content you need or a website address, and they’re reading it while typing these words. These responses mean the responder thinks:

• The information you need is very easy to obtain;
• You searching for this information yourself will let you learn more than being spoon-fed.

You shouldn’t be upset about this; by hacker standards, they’ve shown you some degree of attention, rather than ignoring your request. You should thank them for their grandmotherly kindness.

If You Still Don’t Understand

If you don’t understand the response, don’t immediately ask for explanation. Like when you tried to solve the problem yourself before (using manuals, FAQs, the web, experts around you), first try to understand their response. If you really need them to explain, remember to show you’ve learned something from it.

For example, if I answer you: It seems like zentry is stuck; you should clear it first., then, this is a very bad follow-up question response: What is zentry? A good way to ask would be: Oh~~~ I read the documentation but only -z and -p parameters mention zentries, and neither clearly explains how to clear it. Do you mean one of these two? Or did I miss something?

Handling Rude Responses

Many seemingly rude behaviors in hacker circles aren’t intentional offense. Instead, they’re a direct, straight-to-the-point communication style that focuses more on solving problems than making people feel comfortable but vague.

If you feel offended, try to react calmly. If someone really does something out of line, seniors in mailing lists, newsgroups, or forums will probably call them out. If this doesn’t happen and you get angry, then the words of the person you’re angry at might be normal in the hacker community, and you will be seen as the wrong party, which will hurt your chances of getting information or help.

On the other hand, you’ll occasionally encounter truly rude and boring speech. Contrary to the above, hitting back hard at real offenders and tearing them apart with sharp language is acceptable. However, be very, very sure before acting. There’s a fine line between correcting rude remarks and starting a meaningless flame war, and hackers themselves often cross this line recklessly. If you’re a newbie or outsider, the chance of avoiding this recklessness isn’t high. If you want information rather than killing time, it’s best not to put your hands on the keyboard to avoid risk.

(Some people assert that many hackers have mild autism or Asperger’s syndrome, lacking the nerves needed to lubricate normal human social interaction. This could be true or false. If you’re not a hacker yourself, maybe thinking we have problems can help you deal with our weird behavior. Just do it, we don’t care. We like the way we are, and usually have well-founded doubts about patient labels.)

Jeff Bigler’s observation summary is relevant and worth reading (tact filters).

In the next section, we’ll talk about another problem, the offense you’ll receive when you behave inappropriately.

How to Avoid Playing the Loser

In hacker community forums, you might mess up a few times—in the ways described in this guide or similar ways. And you’ll be told publicly how you messed up, maybe with some colorful language in the attack.

After this happens, the worst thing you can do is whine about your experience, claim you were verbally attacked, demand apologies, scream loudly, hold your breath, threaten legal action, complain to their employer, forget to close the toilet lid, etc. Instead, you should do this:

Get through it, this is normal. In fact, it’s healthy and reasonable.

Community standards don’t maintain themselves, they’re maintained through participants actively and publicly enforcing them. Don’t whine that all criticism should be sent through private email, that’s not how it works. When someone comments that one of your statements is wrong or offers a different view, insisting you were personally attacked is also unhelpful, these are loser attitudes.

There are other hacker forums, misled by high-etiquette requirements, that prohibit participants from posting any messages finding fault with others’ posts, claiming if you don't want to help users, shut up. The result is thoughtful participants leave one by one, doing this only turns them into meaningless nagging and useless technical forums.

To exaggerate: do you want “friendliness” (in the above way) or usefulness? Pick one.

Remember: when a hacker says you messed up, and (no matter how harsh) tells you not to do it again, they’re acting out of care for you and their community. For them, ignoring you and filtering you out of their life is simpler. If you can’t be grateful, at least show some dignity, don’t whine loudly, and don’t expect others to treat you like a fragile doll just because you’re a dramatically supersensitive soul and self-entitled newcomer.

Sometimes, even if you didn’t mess up (or only in their imagination you did), some people will attack you personally for no reason. In this case, complaining will really mess things up.

These troublemakers are either useless people who have no way but think they’re experts, or psychologists testing whether you’ll really mess up. Other readers either ignore them or deal with them in their own way. These troublemakers are making trouble for themselves, you don’t need to worry about this.

Also don’t get yourself involved in flame wars, it’s best to ignore most flame wars—of course, this is after you verify they’re just flame wars, and haven’t pointed out where you messed up, and haven’t cleverly hidden the real answer to the problem behind them (this is also possible).

Questions You Shouldn’t Ask

Here are several classic stupid questions, and what hackers think when they don’t answer:

Question: Where can I find X program or X resource?

Answer: Right where I found it, idiot—the other end of the search engine. Good heavens! Is there anyone who doesn’t know how to use Google?

Question: How do I use X to do Y?

Answer: If you want to solve Y, don’t give possibly inappropriate methods when asking. This kind of question shows the asker is not only completely ignorant about X, but also confused about what Y is supposed to solve, and is trapped in thinking by a specific situation. It’s best to ignore such people until they figure out the problem clearly.

Question: How do I set my shell prompt?

Answer: If you have enough wisdom to ask this question, you should also have enough wisdom to RTFM, then find out yourself.

Question: Can I use the Bass-o-matic file conversion tool to convert AcmeCorp files to TeX format?

Answer: Try it and you’ll know. If you’ve tried, you’d know the answer and wouldn’t need to waste my time.

Question: My {program/setting/SQL statement} doesn’t work

Answer: This isn’t really a question, I’m not interested in questions where I have to ask you twenty questions to find your real problem—I have more interesting things to do. When seeing such questions, my reaction is usually one of three:

• Do you have anything else to add?
• Too bad, hope you can fix it.
• What does this have to do with me?

Question: My Windows computer has problems, can you help me?

Answer: Sure, throw away Microsoft’s garbage and switch to an open source operating system like Linux or BSD.

Note: If the program has an official Windows version or interacts with Windows (like Samba), you can ask Windows-related questions, just don’t be surprised by replies that the problem is caused by the Windows operating system rather than the program itself, because Windows is generally so bad that this statement is usually correct.

Question: My program won’t move, I think system tool X has a problem

Answer: You could well be the first person to notice an obvious flaw in system calls and library files used repeatedly by thousands of users, but it’s more likely you have no basis at all. Extraordinary claims require extraordinary evidence, when you claim this, you must have clear and detailed defect documentation to back it up.

Question: I have problems installing Linux (or X), can you help me?

Answer: No, I can only find the problem by personally working on your computer. Go find your local Linux user group for practical guidance (you can find a list of user groups here).

Note: If the installation problem is related to a specific Linux distribution, asking in its mailing list, forum, or local user group might be appropriate. In this case, describe the exact details of the problem. Before this, carefully search using Linux and all suspected hardware as keywords.

Question: How can I crack the root account/steal OP privileges/read other people’s email?

Answer: Wanting to do this shows you’re a despicable person; looking for a hacker to help you shows you’re an idiot!

Good Questions and Stupid Questions

Finally, I’ll illustrate how to ask questions smartly through examples; two ways of asking the same question are placed together, one is stupid, the other is wise.

Stupid Question:

Where can I find information about Foonly Flurbamatic?

This way of asking is just looking for a STFW answer.

Smart Question:

I Googled “Foonly Flurbamatic 2600” but didn’t find any useful results. Does anyone know where to find programming documentation for this device?

This question has already been STFW’d, looks like they really have trouble.

Stupid Question:

The source code I got from the foo project won’t compile. Why is it so bad?

He thinks it’s all someone else’s fault, this arrogant questioner.

Smart Question:

The foo project code won’t compile under Nulix 6.2. I’ve read the FAQ, but it doesn’t mention any problems related to Nulix. Here’s my compilation log, is there anything I’m doing wrong?

The questioner has specified the environment, read the FAQ, listed the errors, and didn’t push responsibility onto others, their question deserves attention.

Stupid Question:

My motherboard has problems, who can help me?

Some hacker’s answer to this kind of question is usually: Okay, do you need me to pat your back and change your diaper too?, then press delete.

Smart Question:

I’ve tried X, Y, and Z on my S2464 motherboard, but nothing worked, I also tried A, B, and C. Note the strange phenomenon when I try C. Apparently florbish is grommicking, but the result is unexpected. What usually causes grommicking on Athlon MP motherboards? Does anyone know what tests I should do next to find the problem?

This guy, from another perspective, is worth answering. He shows problem-solving ability, not just waiting for answers to fall from the sky.

In the last question, note the subtle but important difference between tell me the answer and give me insight, point out what other diagnostic work I should do.

In fact, the latter question came from a real question on the Linux kernel mailing list (lkml) in August 2001. I (Eric) was the one who asked the question. I observed this unexplained locking phenomenon on a Tyan S2464 motherboard, and list members provided important information to solve this problem.

Through my questioning method, I gave others something to chew on; I managed to make it easy for people to participate and be attracted. I showed I had ability equal to theirs, and invited them to explore with me. By telling them the detours I’d taken to avoid them wasting time, I also showed respect for their valuable time.

Afterwards, when I thanked everyone and praised this good discussion experience, a Linux kernel mailing list member said he felt my question was solved not because I was a famous person on this list, but because I asked in the right way.

Hackers are, in a sense, guys with rich knowledge but lacking human touch; I believe he’s right, if I asked like a beggar, no matter who I am, I would definitely annoy some people or be ignored by them. He suggested I write this down, which directly led to this guide.

If You Don’t Get an Answer

If you still don’t get an answer, please don’t think we feel we can’t help you. Sometimes it’s just that the people who see your question don’t know the answer. No response doesn’t mean you’re being ignored, although admittedly this difference is hard to distinguish.

Overall, simply reposting the question is a very bad idea. This will be seen as meaningless noise. Be patient, the person who knows the answer to your question might live in a different time zone, might be sleeping, or your question might not have been organized well in the first place.

You can get help through other channels, these channels are usually more suitable for beginners’ needs.

There are many online and local user groups, composed of enthusiastic software lovers (even if they might never have written any software themselves). Usually people form such groups to help each other and help beginners.

Additionally, you can seek help from many commercial companies, whether big or small. Don’t be frustrated about having to pay to get help! After all, if your car engine’s cylinder seal blows out—entirely possible—you still have to take it to a repair shop and pay for repairs. Even if the software didn’t cost you a penny, you can’t demand that technical support always be free.

For popular software like Linux, there are at least tens of thousands of users for every developer. It’s fundamentally impossible for one person to handle help requests from tens of thousands of users. Know that even if you pay for this assistance, what you pay is negligible compared to similar software you purchase (usually closed-source software technical support costs are much higher than open source software, and the content isn’t as rich).

How to Answer Questions Better

Be kind. The pressure from problems often makes people seem rude or stupid, but that’s not really the case.

Reply privately to first-time offenders. There’s no need to publicly shame those who honestly make mistakes, a true newbie might not even know how to search or where to find FAQs.

If you’re not sure, say so! An authoritative-sounding wrong answer is worse than none at all, don’t give people wrong directions just because sounding like an expert is fun. Be humble and honest, set a good example for questioners and peers.

If you can’t help, don’t hinder. Don’t joke about actual steps, that might ruin a user’s setup—some poor fool will take it as real instructions.

Ask tentative questions to draw out more details. If you do this well, the questioner can learn something—and so can you. Try turning stupid questions into good ones, remember we were all beginners once.

Although complaining RTFM to those lazy people is justified, pointing out where the documentation is (even just suggesting a Google search keyword) would be better.

If you decide to answer, give good answers. When someone is using the wrong tool or method, don’t suggest clumsy workarounds, recommend better tools, redefine the problem.

Answer questions positively! If the questioner has already researched deeply and shown they’ve tried X, Y, Z, A, B, C without results, answering try A or B or try X, Y, Z, A, B, C with a link is useless.

Help your community learn from problems. When replying to a good question, ask yourself how can I modify related documentation or FAQ to avoid answering the same question again?, then send a patch to the documentation maintainer.

If you made the answer after research, show your technique rather than just serving the result. After all, give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime.

Related Resources

If you need basic knowledge about how personal computers, Unix systems, and networks work, see Unix and Internet Fundamentals HOWTO.

When you release software or patches, try to follow Software Release Practice HOWTO.

Acknowledgments

Evelyn Mitchel contributed some stupid question examples and inspired the How to Answer Questions Better section, Mikhail Ramendik contributed some particularly valuable suggestions and improvements.

The English version of this guide is copyrighted by Eric S. Raymond and Rick Moen.

Original URL: http://www.catb.org/~esr/faqs/smart-questions.html

Reposted from: Developer Relations »