提问的智慧（How To Ask Questions The Smart Way）

Forum Administration Announcements & Rules
1

Original: How To Ask Questions The Smart Way

Translation: Wang Gang<yafrank at 126 dot com>
Date: October 26, 2013
Content

Table of Contents

Translations: Indonesian, Belarusian, Brazilian Portuguese, Simplified Chinese, Dutch, French, Georgian, German, Greek, Hebrew, Japanese, Polish, Portuguese, Romanian, Russian, Spanish, Thai. If you wish to copy, mirror, translate or quote this article, please see my copying policy.

Disclaimer

Many project websites link to this article in their “How to get help” sections; that’s fine, it’s what we want. But if you are the webmaster responsible for generating the link on behalf of the project, please prominently display near that link: We do not provide support for this project!

We have already learned the pain of not having this notice; we will be endlessly pestered by idiots who think that, since we published this document, we are obliged to solve every technical problem in the world.

If you are reading this because you need help and then leave with the impression that you can get it directly from the authors, you are one of those idiots. Don’t ask us questions; we will simply ignore you. We are here to teach you how to get help from people who actually understand your hardware or software problem, but 99.9 % of the time we won’t be those people. Unless you are absolutely sure the author of this document is an expert on your particular problem, do not bother us; everyone will be happier that way.

Introduction

In the world of hackers, the kind of answers you get to your technical questions depends as much on the way you ask as on the difficulty of developing the answer. This guide will teach you how to ask questions in a way that is likely to get you a satisfactory answer.

Open-source software is already very widespread; you can usually get answers from other, more experienced users rather than from hackers. That’s good; these folks are generally more tolerant of newbie mistakes. Nevertheless, using the approach recommended here will get you the most useful answers fastest.

The first thing to understand is that hackers like hard problems and good, thought-provoking questions about them. If we didn’t, we wouldn’t be writing this document. If you give us an interesting question to chew on, we’ll be grateful. Good questions are a stimulus and a gift; they help us develop our understanding and often reveal problems we hadn’t noticed or thought about. Among hackers, “Good question!” is a strong and sincere compliment.

Hackers also have a reputation for meeting simple questions with hostility or arrogance. It sometimes looks like we’re reflexively rude to newbies and the ignorant. But this isn’t really true.

We are simply hostile to people who seem unwilling to think or do their own homework before asking questions. People like that are time sinks—they take without giving back, they waste time we could have spent on another, more interesting question or on someone more deserving of an answer. We call such people “losers” (and, for historical reasons, sometimes spell it “lusers”).

We realize that many people just want to use the software we write and have no interest in learning technical details. For most people, a computer is merely a tool, a means to an end; they have more important things to do and lives to live. We acknowledge that, and we don’t expect everyone to be interested in the technical matters that fascinate us. Our answering style is tuned for people who do take such an interest and are willing to be active participants in problem-solving. That’s not going to change, nor should it.

Most of us are volunteers, taking time out of busy lives to answer questions. We filter questions ruthlessly, especially those that look like they’re from losers, so we can spend our limited time helping the winners.

If you find this attitude obnoxious, condescending, or arrogant, check your assumptions. We’re not asking you to genuflect. In fact, if you do your homework, most of us will be happy to treat you as a peer and welcome you into our culture. Helping people who won’t help themselves is inefficient.

You don’t have to be technically competent to get our attention, but you must display the kind of attitude that leads to competence—alert, thoughtful, observant, willing to be an active partner in developing a solution. If you can’t live up to this, we suggest you pay someone for a commercial support contract instead of asking hackers to work for free.

If you decide to come to us for help, you don’t want to be a loser, and you don’t want to look like one. The best way to get a rapid, responsive answer is to ask the question as if you are a smart, capable person who merely happens to be stuck on one particular problem.

(Improvements to this guide are welcome; send them to esr@thyrsus.com or respond-auto@linuxmafia.com. Note that this document is not intended to be a general netiquette guide; I will usually reject suggestions not specifically related to eliciting useful answers in technical forums.)

Before You Ask

Before posting to any email list, newsgroup, or forum, do the following:

  • Search the archives of the forum you plan to post to.
  • Search the Web.
  • Read the manual.
  • Read the FAQ.
  • Examine or experiment.
  • Ask a skilled friend.
  • If you’re a programmer, read the source code.

When you ask, mention what you found from the above; this shows you’re not a parasite wasting our time. Tell us what you learned; we like answering people who show they can learn from the answer.

Use tactics like searching Google for your exact error message (both Google Groups and the Web). This will often turn up documentation or mailing-list threads that solve your problem. Even if it doesn’t, saying “I searched Google for the following phrase but didn’t find anything useful” is good: it shows which search keywords didn’t help, and helps the next person with the same problem.

Don’t expect a few seconds of Google search to solve a complex problem. Read the FAQ. Sit back, relax, and think about the problem. We can tell how much reading and thinking you did, and you’re more likely to get help if you come prepared. Don’t fire off all your questions at once just because your first search turned up nothing (or too much).

Think carefully and prepare your question. A sloppily written question usually gets a sloppily written answer or none at all. The more you do to demonstrate that you’ve tried to solve your problem, the more likely you are to get a useful answer.

Don’t ask the wrong question. If you base your question on a false assumption, some hacker will probably answer with a workaround that teaches you a lesson rather than giving you what you really need.

Never assume you are entitled to an answer. You aren’t; you haven’t paid for the service. Earn an answer by asking a substantial, interesting, and thought-provoking question—one that contributes experience to the community rather than merely demanding knowledge from it.

On the other hand, making it clear that you are able and willing to help in the process of developing the solution is a very good start. “Can someone point me in the right direction?”, “What am I missing?”, “Which documentation should I check?” are more likely to get answers than “Please give me the exact steps,” because they show you’re willing to do the rest of the work if someone provides a pointer.* English is not my native language; please excuse any spelling mistakes.

  • If you speak , please email/PM me; I may need your help translating my question.
  • I’m familiar with the technical term itself, but I’m not sure about some of its slang or idiomatic uses.
  • I’ve posted my question in both and English; if you reply in either, I’ll be happy to translate.

Send questions in easy-to-read, standard formats

If you deliberately make your question hard to read, it will probably be ignored. People prefer questions they can understand, so:

  • Use plain text, not HTML (turning off HTML isn’t hard).
  • MIME attachments are usually fine if they contain real content (e.g., source files or patches), not just boilerplate generated by your mail client.
  • Don’t send mails that are single-line sentences broken into many lines (this makes quoting parts of the reply difficult). Assume your readers use an 80-column terminal; wrap your lines at fewer than 80 characters.
  • But do not wrap fixed-column data (e.g., log excerpts or session transcripts). Include it verbatim so respondents see exactly what you saw.
  • In English forums, don’t send messages in “Quoted-Printable” MIME encoding. It may be necessary for non-ASCII languages, but many mailers don’t support it. When it breaks, the scattered “=20” symbols are ugly, distracting, and can corrupt meaning.
  • Never expect hackers to read documents in proprietary closed formats like Microsoft Word or Excel. Most react as if someone dumped steaming pig manure on your doorstep. Even if they can cope, they hate it.
  • If you mail from Windows, turn off Microsoft’s “Smart Quotes” (uncheck the box in Tools → AutoCorrect Options → AutoFormat as you type) to avoid sprinkling garbage characters everywhere.
  • In forums, don’t abuse “smileys” and “HTML” features when available. One or two smileys are usually fine, but flashy colored text makes you look like a ditz. Overusing smileys, colors, and fonts makes you look like a giggling teenage girl—rarely a good idea unless you’re more interested in sex than useful answers.
  • If you use a GUI mail client (Netscape Messenger, MS Outlook, etc.), note that the default settings may not meet these requirements. Most have a menu-based View Source command; use it to check your Sent folder and ensure you’re sending clean plain text.

Describe the problem accurately and with substance

  • Describe the symptoms carefully and clearly.
  • Describe the environment (machine, OS, application, anything relevant); give vendor and version numbers (e.g., “Fedora Core 7”, “Slackware 9.1”).
  • Describe what you’ve already researched and understood.
  • Describe the diagnostic steps you took before asking.
  • Describe any recent changes to your computer or software configuration.
  • If possible, provide a way to reproduce the problem in a controlled environment.
  • Do your best to anticipate what hackers will ask and have the answers ready.

If you think the problem is in code, giving a way to reproduce it is especially important; your chance of a useful, timely reply increases dramatically.

Simon Tatham has an excellent essay How to Report Bugs Effectively—I highly recommend reading it.

Less volume, more content

Be concise and substantive. Dumping huge code listings or data dumps into a help request is useless. If you have a large, complicated test case that crashes, trim it down.

Three reasons:

  1. Showing you’ve worked to simplify the problem makes answers more likely.
  2. A simplified problem is more likely to get a useful answer.
  3. While refining the bug report you may discover the fix yourself.

Don’t rush to claim you’ve found a bug

When you hit a problem in software, don’t claim you’ve found a bug unless you are very, very sure. Hint: unless you can supply a source patch that fixes it, or a regression test showing incorrect behavior against a previous version, you probably aren’t sure enough. The same goes for web pages and documentation: if you claim a “bug” in the docs, be ready to supply replacement text.

Remember, many other users don’t see the problem you do; otherwise you’d have found it while reading the docs or searching the web (you did that before complaining, right?). That means it’s probably your mistake, not the software’s.

Programmers work hard to make software perfect. Claiming you’ve found a bug questions their competence; even if you’re right, some may get annoyed. Shouting “Bug!” in the subject is also gauche.

When asking, write as if you did something wrong, even if you’re privately sure you’ve found a real bug. If it’s a bug, the reply will show it. Then the maintainer owes you an apology—better than the other way around.

Grovelling is not a substitute for doing your homework

Some know not to be rude or arrogant, but swing to the opposite extreme: “I know I’m just a pathetic newbie, a loser, but…”. This is both annoying and useless, especially when paired with a vague question.

Don’t waste time with primate hierarchies; instead, give the clearest possible description of background and problem—that positions you far better than grovelling.

Some forums have beginner boards; if you think your question is superficial, go there—but still don’t grovel.

Describe symptoms, not theories

Telling hackers what you think caused the problem is useless (if your diagnosis were that great, would you be asking for help?). Give the raw symptoms, not your interpretations; let them do the diagnosis. If you must mention guesses, label them clearly and explain why they failed.

Stupid:

I keep getting SIG11 errors compiling the kernel; I suspect a hairline crack on the motherboard. What’s the best way to find them?

Smart:

My home-built K6/233 on an FIC-PA2007 (VIA Apollo VP2 chipset) with 256 MB Corsair PC133 SDRAM starts throwing SIG11 errors about 20 minutes after power-on while compiling the kernel, never in the first 20 minutes. Rebooting doesn’t reset the clock, but shutting down overnight does. Swapped all RAM, no change. Representative compilation session log attached.

Many find this hard, so remember: “All diagnosticians are from Missouri.” The USA’s unofficial motto is “Show me” (from Congressman Willard D. Vandiver, 1899: “I come from a country that raises corn, cotton, cockleburs and Democrats… I am from Missouri. You have got to show me.”). For diagnosticians, this isn’t skepticism, it’s a useful requirement: show them the same raw evidence you saw, not your guesses. So—show me.

Describe symptoms in chronological order

What happened immediately before the failure usually holds the best clues. Record exactly what you, the machine, and the software did leading up to the crash. For command-line work, a session log (e.g., from the script utility) quoting the last ~20 relevant lines is helpful.

If the crashing program has debug options (e.g., -v), use them to add useful information. “More” is not “better”; pick a level that informs without drowning the reader.

If your log is long (more than four paragraphs), start with a short summary, then give the detailed timeline so hackers know what to focus on.

Describe the goal, not the steps

If you want to know how to do something (not report a bug), state your high-level goal first, then the specific step where you got stuck.

Often the seeker has a higher goal, is stuck on a particular path, and asks how to proceed without realizing the path itself is wrong—wasting everyone’s time.

Stupid:

How can I get the color-picker in Graphics Program X to output hexadecimal RGB values?

Smart:

I’m trying to replace the color table of an image with values I choose. The only way I know is to edit each slot, but I can’t get Graphics Program X’s color-picker to give me hexadecimal RGB values.

The second version makes it possible to suggest a better tool for the job.

Don’t ask for private replies

Hackers believe problem-solving should be public and transparent; that way, if smarter people notice incomplete or wrong answers, corrections can be made, and helpers earn reputation for their knowledge.

Asking for private replies breaks that process. Don’t; let replyers choose to answer privately—usually because they think the question is too poorly written or trivial to benefit others.

One limited exception: if you expect a flood of identical answers, the magic sentence is: “Email me and I’ll summarize the answers for the list.” Rescuing the list from repetitive noise is polite—but you must follow through.

Ask questions that are precise

Vague, rambling questions are seen as bottomless time sinks. The people most able to answer are usually the busiest; they hate open-ended drains on their time and resent rambling questions.

If you specify what you want (pointers, code, patch review, etc.), you’re more likely to get useful answers. This lets them focus and implicitly caps the effort they must spend—good.

Imagine the experts’ world: plenty of expertise, scarce response time. The less time you implicitly demand, the better your chance of an answer from someone who really knows and is really busy.

So constrain your question to minimize the experts’ time—this isn’t the same as simplifying the problem. “Where can I find a good explanation of X?” is usually smarter than “Explain X.” If your code fails, asking someone to spot the bug is smarter than asking them to fix it.

Questions about code

Don’t ask others to debug your code without showing where to start. Posting 300 lines and saying “it doesn’t work” gets you ignored. Post 30 lines and say “After line 7 I expected but got ”.It is very likely to get you a reply.

The most accurate way to describe a code problem is to provide a minimal test case that demonstrates the issue. What is a minimal test case? It is a demonstration of the problem, using only the code necessary to reproduce the unexpected behavior. How do you generate a minimal test case? If you know which line or section of code is causing the problem, copy it and provide just enough surrounding code to make a complete example (enough so the source can be accepted by the compiler, interpreter, or whatever processes it). If you cannot narrow the problem down to a specific section, copy the source and remove sections that have nothing to do with the issue. The smaller the minimal test case you can provide, the better (see “Less is more”).

Creating a very small minimal test case is not always possible, but trying is good exercise and may help you find what you need to fix on your own. Even if you don’t, hackers like to see that you’ve tried, and that makes them more cooperative.

If you just want someone to review your code, say so up front, and be sure to mention what part you think needs attention and why.

Don’t post homework questions

Hackers are good at spotting homework questions. Most of us have done our own homework, and that’s what you should do too so you can learn. Asking for hints is fine; asking for the complete solution is not.

If you suspect you have a homework question but still can’t solve it, try asking in a user group, forum, or (as a last resort) the project’s “user” mailing list or forum. Even though hackers will spot it, some experienced users may still give you hints.

Remove meaningless demands

Resist the temptation to tack on meaningless pleas like “Can someone help me?” or “Is there an answer?” at the end of your help request. First, if the problem description is incomplete, these additions are just noise. Second, because they are noise, hackers find them annoying—and will probably respond with logically correct but dismissive answers like “Yes, you can get help” and “No, there is no help for you.”

In general, avoid asking yes-or-no questions unless you want a yes-or-no answer.

Don’t flag your question as “urgent”, even if it is for you

This is your problem, not ours. Claiming urgency is likely to backfire: most hackers will simply delete such messages as rude and selfish attempts to get immediate and special attention. Moreover, “urgent” and similar keywords may trigger spam filters, so potential responders may never see your question at all!

There is a tiny partial exception: if you are using the program in some high-profile place that excites hackers, it might be worth mentioning. In that case, if you are under a deadline, politely say so; people might be interested enough to answer faster.

Of course, this is risky, because hackers’ criteria for what is exciting are probably not the same as yours. Posting from the International Space Station is fine, but doing so on behalf of a feel-good charity or political cause almost certainly is not. In fact, posting something like “URGENT: help save this fluffy baby seal!” will simply cause hackers to avoid you or flame you, even if they think fluffy baby seals are important.

If you find this unbelievable, read the rest of this text a few more times until you understand it before posting.

Courtesy never hurts

Be polite. Use “please” and “thank you for your attention” or “thanks for your consideration”, and make it clear that you appreciate the time people spend helping you for free.

Frankly, this is less important than being grammatical, clear, accurate, substantive, and avoiding proprietary formats (and it cannot substitute for them). Hackers would generally rather read a brusque but technically sharp bug report than a polite but vague one. (If this puzzles you, remember that we judge a question by what it teaches us.)

However, once you have stated your technical problem clearly, a dash of politeness does increase your chances of getting a useful answer.

(We must note that the only part of this document that some old hackers seriously object to is the formerly recommended “Thanks in advance”. Some feel it implies you needn’t thank anyone afterward. Our suggestion is either to say “Thanks in advance” and then thank the responders afterward, or express it differently, such as “Thanks for your attention” or “Thanks for your consideration”.)

Follow up with a brief note when the problem is solved

After the problem is solved, send a brief follow-up to everyone who helped, letting them know how it was fixed and thanking them again. If the question got wide attention on a mailing list or newsgroup, that is the appropriate place.

The best way is to reply to the original thread, and put something like “SOLVED”, “FIXED”, or similar in the subject. In a busy list, a potential responder who sees threads titled “Problem X” and “Problem X-FIXED” knows not to waste time (unless he personally finds “Problem X” interesting), and can use that time solving other problems.

The follow-up doesn’t have to be long or elaborate; a simple “Hi—it was a broken cable! Thanks, Bill” is better than nothing. In fact, unless the solution is technically deep, a short, sweet summary is better than a long story. State what fixed the problem; there is no need to reenact the entire troubleshooting saga.

For deep problems, posting a summary of the troubleshooting history is appropriate. Describe the final state, explain what solved the problem, and only afterward mention blind alleys that could have been avoided. Put the blind-alley section after the correct solution and other summary material, not turn the message into a detective story. List the names of people who helped you; you will make friends that way.

Besides being polite and informative, such follow-ups help others searching the list, newsgroup, or forum archives to find the actual solution to your problem, so they benefit as well.

Finally, this kind of follow-up gives everyone who helped a satisfying sense of closure. If you are not a techie or hacker yourself, believe us: that feeling is very important to the experts you asked. A thread that ends in limbo is frustrating; hackers itch to see it resolved. Scratching that itch earns you reputation that will help you enormously the next time you ask a question.

Consider how to prevent others from having the same problem in the future. Ask yourself whether writing a document or FAQ patch would help, and if so, send that patch to the maintainer.

Among hackers, this good follow-up is actually more important than conventional politeness, and it is how you earn reputation by being helpful to others, which is a valuable asset.

How to interpret answers

“Read the Fine Manual” (RTFM) and “Search the Fine Web” (STFW): how to tell you’ve seriously messed up

There is an ancient and hallowed tradition: if you get “RTFM” in reply, the sender thinks you should Read The Fine Manual. He or she is almost certainly right; go read it.

RTFM has a younger relative: if you get “STFW”, the sender thinks you should Search The Fine Web. That person is almost certainly right as well; go search. (A gentler version is “Google is your friend!”)

In forums you may also be told to search the forum archives. In fact, someone may even give you a pointer to a previous thread that dealt with the same issue. Don’t rely on this kindness; search the docs yourself first.

Usually, the person telling you to search has the manual or web page with the answer open in front of him while typing. These replies mean:

  • The information you need is easy to find.
  • You will learn more by finding it yourself than by being spoon-fed.

You should not be offended by this; by hacker standards, the responder is showing you a kind of respect by not ignoring you. You should thank him for being eager to help you.

If you still don’t understand…

If you don’t understand the answer, do not immediately reply asking for an explanation. Use the same tools you used to ask the question (manual, FAQ, web pages, knowledgeable friends, etc.) to try to understand the answer. If you still need clarification, show what you have learned.

For example, if I tell you: “It looks like there is a problem with a certain input; you need to clear it,” a bad follow-up is: “What is a certain input?” A good follow-up is: “Yes, I read the manual, and the input is only mentioned with the -z and -p switches, but neither explains how to clear it. Which one do you mean, or did I miss something?”

Dealing with rudeness

Much of what looks like rudeness in hacker circles is not intended to offend. Rather, it is the direct, cut-through-the-bullshit style of communication natural to people who are more concerned with solving problems than with making others feel warm and fuzzy.

If you feel offended, try to react calmly. If someone really crosses the line, the old-timers on the list, newsgroup, or forum will likely take him to task. If that does not happen and you lose your temper, you are probably the one who will look bad, hurting your chances of getting answers or useful information.

On the other hand, you will occasionally run into real rudeness and time-wasters. In contrast to the above, it is acceptable to flame the living shit out of true offenders, using sharp language to tear them a new one. However, be very, very sure of your ground before you do so. Correcting a rude person and starting a meaningless flamewar are separated by a thin line, and hackers themselves sometimes blunder across it; if you are a newbie or an outsider, your chances of avoiding such blunders are low. If you are after information rather than entertainment, it is safer to keep your hands off the keyboard at that moment.

(Some people assert that many hackers have mild autism or Asperger’s syndrome and are missing the brain circuitry that lubricates “normal” human social interaction. This may or may not be true. If you are not a hacker yourself, it may help you cope with our eccentric behavior to think that we are brain-damaged. Go right ahead; we do not care. We like being this way, and we generally have well-founded skepticism about clinical labels.)

In the next section we will talk about another problem: being “offended” when you are the one who messed up.

Don’t react like a loser

In hacker forums you will occasionally screw up—perhaps in the manner described in this document or similarly. You will be told how you screwed up, perhaps with colorful asides.

The worst thing you can do after such an incident is to whine about your experience, claim you have been verbally assaulted, demand an apology, scream, sulk, threaten to sue, complain to people’s employers, leave the toilet seat up, etc. Instead, do this:

Get over it. It is normal. In fact, it is healthy and appropriate.

Community standards do not maintain themselves. They are maintained by people actively applying them, publicly. Do not whine that all criticism should be conveyed privately by mail; that is not how it works. It is useless to claim you have been personally attacked when someone comments that one of your claims is wrong or that his views differ, and that is the attitude of a loser.

There are other hacker forums, misled by high-minded etiquette, that prohibit posting any message that criticizes another post and claim “if you don’t want to help users, shut up.” Thoughtful participants leave, and the forums become useless shouting matches of useless technical drivel.

Choose one: exaggerated “friendliness” (in the above sense) or usefulness.

Remember: when a hacker tells you that you have screwed up, and (no matter how abrasively) tells you not to do it again, he is acting out of concern for you and his community. It would be much easier for him to ignore you and filter you out of his life. If you cannot manage to be grateful, at least have some dignity and do not whine, and do not expect to be treated like a fragile doll just because you are a dramatic, hypersensitive newcomer who believes he is entitled to special treatment.

Sometimes, even when you have not screwed up (or when someone merely imagines you did), people will attack you without provocation. In this case, complaining is the way to really screw up.

These gadflies are either useless loudmouths who think they are experts, or psychological testers trying to see if you will screw up. Other readers will either ignore them or deal with them in their own way. These gadflies are making trouble for themselves; that is not your problem.

Do not get drawn into flame wars yourself. Most are better ignored—of course, after you have verified that they are mere flames, that they do not point out a real way in which you screwed up, and that they do not contain the actual answer cunningly hidden inside.

Questions not to ask

Here are some classic stupid questions and what hackers are thinking when they do not answer them.

Q: Where can I find program X or resource Y?

Q: How do I do Y with X?

Q: How do I configure my shell prompt?

Q: Can I convert an AcmeCorp document to TeX with the Bass-o-matic file converter?

Q: My {program, configuration, SQL statement} does not work

Q: My Windows computer has a problem, can you help?

Q: My program does not work; I think system tool X is broken

Q: I am having trouble installing Linux or X, can you help?

Q: How can I crack the superuser password / steal channel-op privileges / read someone’s e-mail?

Q:

Where can I find program X or resource Y?

A:

In the same place I found it, idiot—on the web search engine. God, doesn’t everyone know how to use Google yet?

Q:

How do I do Y with X?

A:

If you want to do Y, don’t ask about possibly inappropriate method X. This kind of question shows you are clueless about X and confused about Y, and locked into X by circumstance. Fix your problem, then ask.

Q:

How do I configure my shell prompt?

A:

If you are smart enough to ask, you are smart enough to RTFM and find out yourself.

Q:

Can I convert an AcmeCorp document to TeX with the Bass-o-matic file converter?

A:

Try it and see. If you tried it, you would have the answer and would not have wasted my time.

Q:

My {program, configuration, SQL statement} does not work

A:

This is not a question, and I have no interest in guessing what your problem is—I have better things to do. My reaction is most likely:

  • What else did you leave out?
  • Oh, too bad, hope you figure it out.
  • What does this have to do with me?

Q:

My Windows computer has a problem, can you help?

A:

Yes, delete the Windows garbage and install an open-source OS like Linux or BSD.

Note: If the program has an official Windows version or interacts with Windows (e.g., Samba), you may ask Windows-related questions, but don’t be surprised if the reply is that the problem is Windows, not the program, because Windows is generally so broken that this is often true.

Q:

My program does not work; I think system tool X is broken

A:

You are probably not the first to notice an obvious bug in a system call or library used by thousands of users. Extraordinary claims require extraordinary evidence; when you make such claims, you must back them up with clear, detailed documentation of the defect.

Q:

I am having trouble installing Linux or X, can you help?

A:

No, I would need hands-on access to your machine to debug it. Seek help from a local Linux user group (you can find lists of groups here).

Note: If the installation issue is specific to a Linux distribution, it may be appropriate to ask on that distribution’s list, forum, or local user group. Describe the exact details of the problem. Before posting, search carefully using “linux” and all suspected hardware as keywords.

Q:

How can I crack the superuser password / steal channel-op privileges / read someone’s e-mail?

A:

Wanting to do this shows you are a scumbag; wanting hackers to teach you how shows you are an idiot.

Good and bad questions

Finally, I will illustrate asking smart questions by example. The same question can be asked stupidly or intelligently.

Stupid: Where can I find info about the Foonly Flurbamatic device?

This begs for an STFW reply.

Smart: I googled “Foonly Flurbamatic 2600” but found nothing useful. Does anyone know where I can find programming info for this device?

This person has searched and may really have a problem.

Stupid: I can’t compile the foo project source; it’s crap.

The asker assumes someone else screwed up, arrogant.

Smart: The foo project source won’t compile under Red Hat 6.2. I read the FAQ, but there is nothing about Red Hat. Here is the compile log; what am I doing wrong?

The asker has specified the environment, read the FAQ, posted the error, and does not assume the fault is elsewhere—worthy of attention.

Stupid: My motherboard is broken, can anyone help?

A hacker might reply: “Sure, want me to wipe your nose and change your diaper too?” and then hit delete.

Smart: I tried X, Y, and Z on the S2464 motherboard. After they failed, I tried A, B, and C. Note the strange symptom when I tried C; obviously the flux capacitor is over-cranking, which is not expected. What typically causes this on Athlon MP motherboards? What else can I try to narrow it down?

This person appears worth answering. He or she has demonstrated problem-solving capacity rather than waiting for a magic fix.

In the last question, note the subtle but important difference between “gimme an answer” and “help me see what else I can test to get a clue.”

In fact, the last question is basically what I (Eric) asked on the Linux kernel mailing list in August 2001. I found mysterious lockups on a Tyan S2462, and list members provided the key information needed to fix it.

By asking this way, I gave people something to chew on, made it interesting, showed respect for peers’ abilities, and invited collaboration. By listing dead ends, I showed respect for their valuable time.

Afterward, when I thanked everyone and commented on the good experience, a Linux kernel list member said he thought I got the answer not because of my name, but because of the way I asked.

Hackers are, in some ways, utterly ruthless meritocrats. I think he was right; had I acted like a parasite, I would have been ignored or flamed regardless of who I was. He suggested using the episode as a guide for others, which directly led to this document.

If you can’t get an answer

If you can’t get an answer, please don’t take it personally; sometimes the members of the asked group simply don’t know the answer. No response is not the same as being ignored, though admittedly it is hard to tell the difference from outside.

In general, reposting the question is a bad idea; this will be seen as pointless harassment. Be patient; the person with the answer may live in a different time zone and be asleep, or your question may not have been clear enough in the first place.

There are other sources of help, often for newbies.

There are many online and local user groups that, while they don’t write software, are enthusiastic about it. These groups often form for mutual help and newbie support.

There are also many commercial companies that provide paid support. Don’t be dismayed that you have to pay! If your car’s head gasket blows, you pay a mechanic. Even if the software is free, you can’t expect support to be free. For popular software like Linux, each developer has at least ten thousand users; one person cannot support them all. Remember, even paid support is cheaper than buying proprietary software, and support for closed-source software is usually more expensive and worse.

How to answer questions in a helpful way

Be gentle. Problem-related stress can make people seem rude or stupid; they are not.

Reply to first-time offenders privately. There is no need to humiliate someone who simply made an honest mistake; a real newbie may not know how to search or where the FAQ is.

If you don’t know for sure, say so! A wrong but authoritative-sounding answer is worse than none. Be humble and honest, and set a good example for both questioners and peers.

If you can’t help, don’t hinder. Don’t make jokes about procedures that could trash the user’s setup—some poor sap might take them seriously.

Ask probing questions to elicit more details. If you do this well, the questioner will learn something—and so might you. Try to turn bad questions into good ones; remember we were all newbies once.

While it is fair to mutter “RTFM” at a lazy slob, pointing to the documentation (even suggesting a Google keyword) is better.

If you are going to answer, give a good answer. Don’t suggest kludgey workarounds when someone is using the wrong tool or approach; recommend better tools and reframe the question.

Answer the actual question! If the questioner has done his homework and says he tried X, Y, Z, A, B, and C, replying “Try A or B” or giving a link that says “Try X, Y, Z, A, B, or C” is useless!

Help your community learn. When you answer a good question, ask yourself “How can I change the related document or FAQ so this question need never be answered again?” and then send a patch to the maintainer.

If you did research to answer, show your technique rather than just the answer. After all, “Give a man a fish and you feed him for a day; teach him to fish and you feed him for a lifetime.”### Related Resources

If you need basic knowledge about how personal computers, Unix, and the Internet work, refer to Unix and Internet Fundamentals HOWTO.

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

Acknowledgments

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