Reprint Notice

The following content is reposted by Asuna from How-To-Ask-Questions-The-Smart-Way

It is intended solely to accelerate access within mainland China. If there is any infringement, please contact us and it will be removed!

How To Ask Questions The Smart Way

How To Ask Questions The Smart Way

Copyright © 2001,2006,2014 Eric S. Raymond, Rick Moen

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

Copyleft 2001 by D.H.Grand(nOBODY/Ginux), 2010 by Gasolin, 2015 by Ryan Wu

This Chinese guide is the latest translation, based on version 3.10 of the original and the 2010 translation by Gasolin;

To help point out translation problems, please 发 issue, or 发 pull request me directly.

An 繁體中文版 is also available for this article.

原文版本历史

Disclaimer

Many projects link to this guide in the help documentation on their websites. That’s great—it’s exactly the use we intended. But if you are the project administrator and are trying to create a hyperlink to this guide, please note prominently near the hyperlink:

This guide does not provide actual support services for this project!

We have learned the pain of missing the above disclaimer the hard way: we will be endlessly pestered by fools who think that publishing this guide means we have a responsibility to solve every technical problem in the world.

If you are reading this guide because you are seeking some help, and you leave still feeling that you can get direct help from the authors of this article, then you are one of the fools we mentioned earlier. Don’t ask us questions; we will only ignore you. What we want to teach you in this guide is how to get assistance from the people who truly understand the software or hardware problem you have encountered, and 99% of the time that will not be us. Unless you are sure that one of the authors of this guide happens to be an expert in the field of the problem you are facing, please do not disturb us, and everyone will be a little happier.

Introduction

In the world of 黑客, when you throw out 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 so you get answers you are satisfied with.

Now that open source software has become quite prevalent, you can often get answers just as good as those from hackers from other, more experienced users. This is a good thing; compared with hackers, users tend to be more tolerant of the problems beginners commonly encounter. Nevertheless, treating these experienced users in the way we recommend here is usually also the most effective way to get useful answers from them.

First, you should understand that hackers love challenging questions, or good questions that stimulate their thinking. If we weren’t like that, we wouldn’t be the people you want to ask. If you give us a good question worth chewing over and savoring, we will be grateful to you. Good questions are an incentive, a generous gift. Good questions can improve our understanding, and often expose problems we never realized or thought about before. To hackers, “Good question!” is sincere and high praise.

Nevertheless, hackers have a bad reputation for being contemptuous or arrogant toward simple questions, which sometimes makes us seem hostile to beginners and the ignorant, but that’s not really the case.

We make no secret of our contempt for people who are unwilling to think, or who don’t do what they should before asking. Those people are time killers—they only want to take, never give, and they consume time we could spend on more interesting questions or more worthwhile people. We call such people 失败者（撸瑟） (for historical reasons, we 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 just a tool, a means to an end. They have their own lives and more important things to do. We understand this, and we never expect everyone to be interested in the technical problems that fascinate us. Nevertheless, our style of answering questions is aimed at people who are genuinely interested and willing to actively participate in solving problems, and this will not change, nor should it. If even this changed, we would be less efficient at doing what we do best.

We are (to a large extent) volunteers, taking time out of busy lives to answer questions, and we are often overwhelmed by them. So we ruthlessly filter out some topics, especially abandoning those who look like losers, so that we can use our time more efficiently to answer the questions of 赢家（winner）.

If you dislike our attitude, our condescension, or our arrogance, put yourself in our shoes. We are not asking you to submit to us—in fact, most of us are very happy to communicate with you as equals, and as long as you make a small effort to meet the basic requirements, we will welcome you into our culture. But it is inefficient for us to help people who are unwilling to help themselves. Ignorance is fine, but pretending to be an idiot is not.

So you don’t have to be technically proficient to attract our attention, but you do have to show the traits that can guide you toward proficiency—being sharp, having ideas, being observant, and being willing to actively participate in solving problems. If you can’t do these things that make you stand out, we suggest you spend some money and sign a technical support service contract with a commercial company, instead of asking individual 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, and you certainly don’t want to be one of the losers. The best way to get a quick and effective answer is to ask like a winner — intelligently, confidently, with an approach to solving the problem, and only occasionally needing a little help on a specific point.

(Feedback to improve this guide is welcome. You can send your suggestions to [email protected] or [email protected]. Note, however, that this document is not a general guide to 网络礼节, and we will usually reject suggestions that do not help people get useful answers on technical forums.)

Before You Ask

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

  1. Try searching old posts on the forum where you plan to ask for an answer.
  2. Try searching the web to find an answer.
  3. Try reading the manual to find an answer.
  4. Try reading the FAQ to find an answer.
  5. Try checking or experimenting yourself to find an answer.
  6. Ask a knowledgeable friend around you to find an answer.
  7. If you are a programmer, try reading the source code to find an answer.

When you ask a question, first state that you have already made these efforts; this helps establish that you are not a freeloader who wastes other people’s time. It’s even better if you can also express what you learned in the course of making those efforts, because we are more willing to answer questions from people who show they can learn from the answer.

Use certain strategies, such as first searching Google for the various error messages you encounter (search Google 论坛 and the web), and you will very likely find the file or mailing list thread that solves the problem directly. Even if there is no result, adding a line such as 我在 Google 中搜过下列句子但没有找到什么有用的东西 when seeking help on a mailing list or newsgroup is a good thing, even if it only shows what the search engine cannot provide. Doing this (adding the searched strings) also lets other people who encounter similar problems be led by search engines to your question.

Don’t be impatient, and don’t expect a few seconds of Google search to solve a complex problem. Before asking an expert for help, read the FAQ again, relax, get comfortable, and spend a little more time thinking about the problem. Trust us, they can tell from your question how much reading and thinking you have done, and if you come prepared, you are more likely to get an answer. Don’t dump all your questions at once just because your first search found no answer (or found too many).

Prepare your question and think it through carefully, because a careless question will only get a careless answer, or no answer at all. The more you show the effort you put into solving the problem before asking for help, the more likely you are to get substantive help.

Be careful not to ask the wrong question. If your question is based on a false assumption, some ordinary hacker (J. Random Hacker) will most likely be thinking 蠢问题… while giving you a meaningless literal explanation, hoping you will learn a lesson from the answer to the question (rather than from the answer you wanted).

Never assume you are entitled to an answer; you are not; you really aren’t. After all, you haven’t paid anything for this service. You will have to earn an answer yourself, by asking substantive, interesting, thought-provoking questions — questions with the potential to contribute to the community’s experience, not merely passively extracting knowledge from others.

On the other hand, showing that you are willing to do something in the process of finding the answer is a very good start. 谁能给点提示？, 我的这个例子里缺了什么？, and 我应该检查什么地方 are more likely to get an answer than 请把我需要的确切的过程贴出来. Because you show that as long as someone can point you in the right direction, you have the ability and determination to finish it.

When You Ask

Choose Your Forum Carefully

Be careful about where you ask. If you do any of the following, you are likely to be ignored or seen as a loser:

  • Posting your question on a forum that doesn’t match the topic.
  • Posting a very basic question on a forum that discusses advanced technical topics, or vice versa.
  • Cross-posting the same question to too many different newsgroups.
  • Sending private email to someone who is neither an acquaintance nor obligated to solve your problem.

Hackers filter out questions that are in the wrong place, to protect their communication channels from being flooded with irrelevant material. You wouldn’t want that to happen to you.

So the first step is to find the right forum. Again, Google and other search engines are your friends; use them to find the site most relevant to the software or hardware problem you are having trouble with. Usually there are links to FAQs, mailing lists, and related documentation there. If your efforts (including reading the FAQ) come up empty, the site may also have a bug-reporting process or link; if so, follow it.

Sending email to strangers or forums is probably the riskiest thing you can do. For example, don’t assume that the author of a content-rich web page wants to serve as your free consultant. Don’t be too optimistic about whether your question will be welcome — if you are not sure, send it elsewhere, or don’t send it at all.

When choosing a forum, newsgroup, or mailing list, don’t trust its name too much; look at the FAQ or charter first to figure out whether your question is on topic. Browse the existing threads before posting, so you can get a feel for the culture there. In fact, searching the history of the newsgroup or mailing list for keywords related to your problem beforehand is an excellent idea; you may find the answer that way. Even if you don’t, it can help you formulate a better question.

Don’t “spray” all the help channels at once like a machine gun; that’s as unpleasant as shouting. Take them one at a time.

Get your subject right! One of the most typical mistakes is asking about Unix or Windows OS program interfaces in a forum dedicated to some cross-platform portable language, suite, or tool. If you don’t understand why this is a big mistake, it’s best to ask nothing until you’ve clarified the difference.

Generally, asking in a carefully chosen public forum is more likely to get useful answers than asking the same question in a private forum. There are several reasons for this: one is how many potential responders there are, and another is how large the audience is. Hackers are more willing to answer questions that help many people.

Understandably, seasoned hackers and the authors of some popular software are receiving too much misdirected mail. Like the straw that finally breaks the camel’s back, your addition may push things to the extreme — it has happened several times that authors of popular software stopped providing support because of the unbearable flood of useless email into their private inboxes.

Stack Overflow

Search, then ask on Stack Exchange.

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

Because Google indexing is immediate, search Google before looking at Stack Exchange. There is a high chance someone has already asked a similar question, and Stack Exchange sites often appear at the top of search results. If you don’t find any answer on Google, then go to the site specifically related to the topic. Searching with tags (Tag) can narrow down your search results further.

If you still can’t find anything useful for your question, post your question on the most relevant site. When asking, make good use of the formatting tools, especially be sure to format code and add relevant tags (especially the names of programming languages, operating systems, or libraries/packages). When someone asks you for more relevant information, edit your post to add it [translator’s note: rather than posting a reply or answer!]. If you think an answer is helpful to you, click the up arrow to vote for it; if an answer provides the correct solution to the problem, click the check mark below the voting buttons to mark it as accepted.

Stack Exchange has grown to 超过一百个网站, and the following are the most commonly used sites:

  • Super User is for general computer questions. If your question has nothing to do with code or programming and is just about network connections or similar, ask here.
  • Stack Overflow is for questions about programming.
  • Server Fault is for questions about servers and system administration.

Websites and IRC Forums

Your local user group (user group), or the Linux distribution you use, may be promoting their web forum or IRC channel and offering newbie help (in some non-English-speaking countries, newbie forums are likely still mailing lists). These are all good places to start asking questions, especially when you think the problem you’re encountering may be relatively simple or common. Ad-sponsored IRC channels are publicly welcoming places to ask questions and usually offer immediate responses.

Actually, if a program problem occurs only in the version provided by a particular Linux distribution (which is common), it’s best to ask first in that distribution’s forum or mailing list, and then in the program’s own forum or mailing list. (Otherwise) the project’s hackers may simply reply, “Use our version.”

Before posting on any forum, first check whether it has a search function. If it does, try searching for a few keywords from your question; it may help. If you’ve already done a general web search before this (and you should have), search the forum again anyway; the search engine may not have had time to index all of the forum’s content yet.

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

When using IRC, first of all, it’s best not to post a very long problem description; some people call this channel flooding. It’s best to start the chat with a one-sentence problem description.

Step 2: Use the Project Mailing List

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

  • Any question good enough to ask an individual developer will also benefit the entire project community. Conversely, if you think your question is too silly for the entire project community, that’s still no reason to harass an individual developer.
  • Asking the list distributes the burden on developers; individual developers (especially project leaders) may be too busy to answer your question.
  • Most mailing lists are archived, and archived content is indexed by search engines. If you ask the list and get an answer, others in the future can find your question and answer through a web search, so they won’t have to ask again.
  • If certain questions are asked frequently, developers can use this information to improve the documentation or the software itself to make it clearer. If you only ask privately, no one can see the full picture of the most common questions.
    (This is part 3 of 12 of the same post.)

If a project has both a “user” mailing list or forum and a “developer” (or “hacker”) one, and you’re not going to be touching the source code, then ask on the “user” list or forum. Don’t assume you’ll be welcome on the developer list; most of those people will see your question as noise that interferes with their development work.

However, if you’re certain your question is unusual and it has gone unanswered for several days on the “user” list or forum, you might try asking on the “developer” list or forum. It’s best to lurk quietly for a few days beforehand to learn how things are done 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 all you can find is the maintainer’s email address, go ahead and write to them. Even then, don’t assume the (project’s) mailing list doesn’t exist. In your email, state that you’ve already tried and couldn’t find a suitable mailing list, and mention that you don’t object to your email being forwarded to others (many people believe that private email shouldn’t be made public even when there’s nothing secret about it. By allowing your email to be forwarded, you give the recipient the choice of what to do with it).

Use a meaningful and clearly descriptive subject line

In mailing lists, newsgroups, or forums, a subject line of roughly 50 characters or less is a great opportunity to grab the attention of seasoned experts. Don’t waste that opportunity with chatty 帮帮忙, 跪求, 急 (not to mention off-putting phrases like 救命啊！！！！, which will be reflexively ignored). Don’t imagine you can impress us with how much you’re suffering; instead, use that space to describe the problem as briefly and precisely as possible.

A good example of a subject line is the 目标 —— 差异-style description, which is exactly what many technical support organizations do. In the 目标 part, indicate which thing or group of things has the problem; in the 差异 part, describe where the behavior differs from what’s expected.

Stupid question: Help! My laptop won’t display properly!

Smart question: X.org 6.8.1 mouse pointer deforms, Brand X graphics card MV1005 chipset.

Smarter question: X.org 6.8.1 mouse pointer deforms under Brand X graphics card MV1005 chipset.

The process of writing an 目标 —— 差异-style description helps you organize your careful thinking about the problem. What is affected? Just the mouse pointer, or other graphics as well? Does it only occur in the X version of X.org? Or only in version 6.8.1? Is it specific to a certain brand’s graphics chipset? Or only the MV1005 model? A hacker can tell at a glance your environment and the problem you’re having.

In short, imagine you’re searching through an archived thread index that shows only subject lines. Making your subject line better reflect the problem lets the next person searching for a similar issue pay attention to this thread instead of asking the same question again.

If you want to ask a question in a reply, remember to change the subject line to show that you’re asking a question; a subject that looks like Re: 测试 or Re: 新 bug is hard to take seriously enough. Also, as long as it doesn’t hurt continuity, quote and trim the preceding content appropriately to leave clues for new readers.

For threads, don’t just click reply to start a brand-new thread; that will limit your audience. Because some mail readers, such as mutt, let users sort by thread and hide messages by collapsing threads, and people who do that will never see your message.

Changing the subject alone isn’t enough. mutt and some other mail readers also check information beyond the subject line in order to assign threads. So it’s better to send a brand-new email.

On web forums, the right way to ask is slightly different, because threads are tightly bound to specific information and their contents usually can’t be seen outside the thread, so asking via a reply rather than changing the subject is acceptable. Not all forums allow a separate subject in a reply, and if you do that, basically no one will look at it. Still, asking via a reply is inherently ambiguous, because it will only be read by people currently viewing that subject. So unless you only want to ask among the people currently active in that thread, it’s better to start a new one.

Make your question easy to reply to

Ending your question with 请将你的回复发送到…… will most likely get you no answer. If you think it’s too much trouble to spend a few seconds setting a reply address in your mail client, we think it’s too much trouble to spend a few seconds thinking about your question. If your mail program doesn’t support it, 换个好点的; if your operating system doesn’t support such a mail program, switch to a better one.

On forums, asking for replies by email is very rude, unless you think the reply information might be sensitive (some people, for unknown reasons, will let only you rather than the whole forum know the answer). If you just want email notification when someone replies to the thread, you can ask the web forum to send it. Almost all forums support features like 追踪此讨论串, 有回复时发送邮件提醒.

Use clear, correct, precise, and grammatical language

We’ve found from experience that careless askers also tend to write programs and think carelessly (I’d bet on it). Answering a careless person’s question isn’t worth it; we’d rather spend the time elsewhere.
(This is part 4 of 12 of the same post.)

Correct spelling, punctuation, and capitalization matter a great deal. Generally speaking, if you feel it’s too much trouble to bother with these things, then we also feel it’s too much trouble to bother with your question. Put in a little extra effort to choose your words carefully—there’s no need to be stiff or overly formal; in fact, hacker culture values the precise use of informal language, slang, and humor. But it must be accurate, and there should be signs that you are thinking about and paying attention to the problem.

Spell correctly, use punctuation and capitalization properly, and don’t confuse its with it's, loose with lose, or discrete with discreet. Don’t write EVERYTHING IN ALL CAPS—that reads as rude shouting (all lowercase isn’t much better, since it’s hard to read. Alan Cox might get away with it, but you won’t).

To put it more plainly, if you write like a semi-literate [译注：小白], you probably won’t get a response. Also, don’t use instant-messaging abbreviations or 火星文—shortening 的 to d, for example, makes you look like a newbie who’s skimping on keystrokes. Worse still, scribbling like a child is absolutely asking for trouble; you can be sure no one will pay attention to you (or at best, you’ll get a pile of criticism and sarcasm).

If you’re asking questions on a forum in a non-native language, you can make minor spelling and grammar mistakes, but you must never be sloppy in your thinking (yes, we can usually tell the difference). Also, unless you know the language of the people who will reply, please write in English. Busy hackers will generally just delete messages written in a language they can’t understand. English is the lingua franca of the internet, and writing in English minimizes the chance that your question will be deleted unread.

If English is your second language, it’s a good idea to let potential responders know you may have language difficulties:
[Translator’s note: the original text is included below for use]

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

  • English is not my native language; please excuse any typos or grammar mistakes.

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

  • If you speak a certain language, please email/PM 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 am familiar with the technical terms, but I’m not very good 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 both a certain language and English.
  • If you answer in only one of them, I’ll be glad to translate the response into the language you use.

Send questions in an easy-to-read, standard file format

If you deliberately make your question hard to read, it will most likely be ignored. People prefer questions that are easy to understand, so:
(This is part 5 of 12 of the same post.)

  • Use plain text, not HTML (关闭 HTML isn’t hard).
  • Using MIME attachments is usually fine, provided there’s actual content (such as attached source code or a patch), and not just a template generated by the mail program (like a copy of the message body).
  • Don’t send an email where a single sentence of text wraps into multiple lines after auto-wrapping (this makes replying to parts of it very difficult). Imagine your reader is reading mail on an 80-character-wide terminal, and it’s best to set your line-wrap point below 80 characters.
  • However, for some special files, do not set a fixed width (such as a log file copy or a session transcript). The data should be included as-is, so the responder can be confident they’re seeing the same thing you are.
  • On English-language forums, don’t send messages using Quoted-Printable MIME encoding. This encoding may be necessary for posting non-ASCII languages, but many mail programs don’t support it. When they handle line breaks, the =20 symbols scattered throughout the text are both ugly and distracting, and may even break the meaning of the content.
  • Absolutely, never expect hackers to read documents written in closed formats, such as Microsoft Word or Excel files. Most hackers react to this the way you’d react to someone dumping a steaming pile of pig droppings at your front door. Even if they can handle it, they hate doing so.
  • If you’re sending email from a Windows computer, turn off Microsoft’s stupid 智能引号 feature (from [Options] > [Spelling] > [AutoCorrect Options], uncheck the 智能引号 checkbox), so you don’t scatter junk characters all over your email.
  • On forums, don’t abuse the 表情符号 and HTML features (when they’re offered). One or two smileys are usually fine, but fancy colored text tends to make people think you’re incompetent. Overusing smileys, colors, and fonts makes you look like a giggling little girl. This is usually not a good idea, unless you’re interested in sex rather than answers.

If you use a GUI mail program (such as Microsoft Outlook or something similar), note that their default settings don’t necessarily meet these requirements. Most such programs have a menu-based 查看源代码 command; use it to check the mail in your Sent folder, to make sure you’re sending plain text files without strange characters.

Describe the problem precisely and meaningfully

  • Describe your problem or the symptoms of the bug carefully and clearly.
  • Describe the environment in which the problem occurs (machine configuration, operating system, application, and related information), and provide the distributor’s release and version number (e.g., Fedora Core 4, Slackware 9.1, etc.).
  • Describe how you researched and understood the problem before asking.
  • Describe the diagnostic steps you took to pin down the problem before asking.
  • Describe any recent hardware or software changes that might be relevant.
  • Provide, as far as possible, a method by which the problem can be 重现这个问题的可控环境.

Try to imagine how a hacker would question you, and answer in advance the questions hackers are likely to ask before you ask.

Among the above points, when you’re reporting something you believe may be a problem in the code, giving hackers an environment in which they can reproduce your problem is especially important. When you do this, your chances of getting an effective answer, and the speed at which you get it, will increase greatly.

Simon Tatham wrote an excellent article titled “如何有效的报告 Bug”. I strongly recommend you read it too.

Quantity is not quality

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

This serves at least three purposes.
First, it shows that you’ve made an effort to simplify the problem, which increases your chances of getting an answer;
Second, simplifying the problem makes it more likely you’ll get a useful answer;
Third, in the process of refining your bug report, you’ll very likely find the solution or a workaround yourself.

Don’t cry “Bug” at every turn

When you run into a problem while using software, unless you’re very, very well-founded, don’t claim to have found a Bug. Hint: unless you can provide a source code patch that fixes the problem, or provide a regression test showing that the behavior was incorrect in a previous version, you’re probably not fully confident enough. The same applies to web pages and files: if you (claim to) have found a Bug in a file, you should be able to provide a correction at the corresponding location or a replacement file.

Remember that many other users haven’t encountered the problem you found—otherwise you’d have found it when reading the documentation or searching the web (did you 已经做了这些，是吧 before complaining?). This also means it’s very likely you’re mistaken rather than that the software itself has a problem.

People who write software always work very hard to make it as perfect as possible. If you claim to have found a Bug, you’re questioning their competence, and even if you’re right, you may offend some of them. This is especially serious when you shout in the subject line that there’s a Bug.

When asking, even if you’re privately quite 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 that in the reply. That way, if there really is a Bug, the maintainer will apologize to you, which is better than annoying someone and then owing them an apology.

Groveling cannot replace your homework

Some people understand that they shouldn’t ask questions rudely or arrogantly and demand answers, but they choose another extreme — groveling: 我知道我只是个可悲的新手，一个撸瑟，但.... This is both annoying and useless, and is especially objectionable when accompanied by a vague description of the actual problem.

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

Sometimes web forums have sections specifically for beginners’ questions. If you genuinely think you have a beginner’s question, go there — but don’t grovel there either.

Describe the symptoms, not your guesses

Telling the hackers what you think caused the problem isn’t much help. (If your inference were that effective, why would you need to ask anyone?) So make sure you tell them the symptoms of the problem exactly as they are, not your explanations and theories; let the hackers speculate and diagnose. If you think it’s important to state your guesses, make clear that they are only guesses, and describe why they don’t hold up.

Stupid question

I keep getting SIG11 errors while compiling the kernel.
I suspect a jumper wire is lying across a trace on the motherboard. What’s the best way to check for this?

Smart question

My home-built machine is an FIC-PA2007 motherboard with an AMD K6/233 CPU (VIA Apollo VP2 chipset),
256MB Corsair PC133 SDRAM. When I compile the kernel, I start getting SIG11 errors 20 minutes after boot,
but I never get the same problem in the first 20 minutes. Rebooting doesn’t help, but after shutting down overnight it works for another 20 minutes.
I’ve swapped out all the memory with no effect. The relevant part of a standard compile log follows…

Since many people seem to find this hard to comply with, here’s a line to remind you: 所有的诊断专家都来自密苏里州。 The official motto of the US State Department is: 让我看看 (from a speech by Congressman Willard D. Vandiver in 1899: 我来自一个出产玉米，棉花，牛蒡和民主党人的国家，滔滔雄辩既不能说服我，也不会让我满意。我来自密苏里州，你必须让我看看。) For the diagnostician, this isn’t a form of doubt — it’s simply a real and useful need, so that what they see matches the raw evidence you see as closely as possible, rather than your guesses and conclusions. So show us openly!

List the symptoms in chronological order

The series of operations before the problem occurs is often the most helpful clue for finding it. Your explanation should therefore include your steps, along with the machine’s and software’s responses, up to the point where the problem occurs. In the case of command-line processing, providing a session log (e.g., generated by running a script tool) and quoting the relevant few lines (say, 20) is very helpful.

If the crashing program has diagnostic options (such as the -v verbose switch), try selecting those that add debug information to the log. Remember that 多 does not equal 好. Try choosing an appropriate debug level so as to provide useful information without drowning the reader in junk.

If your explanation is long (say, more than four paragraphs), it helps to summarize the problem at the start, then go into detail in chronological order. That way the hackers know what to pay attention to as they read your log.

Describe the goal, not the process

If you want to figure out how to do something (rather than report a Bug), describe your goal at the start, then state the specific steps where you got stuck.

People often seeking technical help have a higher-level goal in mind, and they get stuck on what they assume is the path to that goal, then come asking which way to go, without realizing the path itself is the problem. The result is that it takes a great deal of effort to sort things out.

Stupid question

How do I get a hex RGB value from the color picker of some drawing program?

Smart question

I’m trying to replace an image’s color table with color codes of my own choosing. The only way I know to do this now is to edit each table slot,
but I can’t get the hex RGB values from the color picker of a drawing program.

The second way of asking is smarter — you might get a reply like 建议采用另一个更合适的工具.

Don’t ask for replies by private email

Hackers believe the problem-solving process should be public and transparent, so that if more experienced people notice something incomplete or inappropriate along the way, the initial replies can and should be corrected. At the same time, the helper gets a reward: their ability and knowledge are seen by their peers.

When you ask for a private reply, that process and that reward are cut off. Don’t do it — let the responder decide whether to answer privately. If they do, it’s usually because they think the question is so poorly written or so shallow that it couldn’t possibly interest anyone else.

There is a limited exception to this rule: if you’re confident the question might attract a flood of near-identical replies, then the magic question is 向我发电邮，我将为论坛归纳这些回复. Trying to save a mailing list or newsgroup from a flood of duplicate replies is very polite — but you must keep your word.

Be clear and explicit about your question and your needs

Open-ended questions are nearly endless time sinks. The people most likely to give you a useful answer are usually also the busiest (they’re busy because they do most of the work themselves). Such people have a strong aversion to unbounded time sinks, so they tend to dislike open-ended questions as well.

If you explicitly state what you need the responder to do (provide guidance, send a snippet of code, review your patch, or whatever else), you are far more likely to get a useful answer. This sets an upper bound on the time and effort required, which lets responders focus on helping you. That’s great.

To understand the world the experts live in, imagine technical skill as an abundant resource and response time as a scarce one. The less of their time you ask for, the more likely you are to get an answer from a genuinely expert and genuinely busy specialist.

So define your question in a way that minimizes the time an expert must spend identifying your problem and answering it — this technique is very helpful for getting a useful answer — but it is usually different from simplifying the question. Therefore, asking 我想更好地理解 X，可否指点一下哪有好一点说明？ is usually better than asking 你能解释一下 X 吗？. If your code doesn’t work, it is usually much wiser to ask someone to look at what’s wrong than to ask them to fix it for you.

When asking about code

Don’t ask others to debug your broken code without giving them a hint about where to start. Posting several hundred lines of code and saying: 它不能工作 will get you completely ignored. Posting a few dozen lines of code and saying: 在第七行以后，我期待它显示 <x>，但实际出现的是 <y> is more likely to get you a response.

The most effective way to describe a program problem is to provide a minimal bug-demonstrating test case. What is a minimal test case? It is a miniature of the problem: a small piece of code that shows exactly the abnormal behavior of the program without including other distracting content. How do you make a minimal test case? If you know which line or which block of code causes the abnormal behavior, copy it and add enough code to reproduce the situation (for example, enough for the code to be compiled/interpreted/processed by the application). If you cannot narrow the problem down to a specific block, copy the code and remove the parts that do not affect the problematic behavior. In short, the smaller the test case, the better (see the 话不在多而在精 section).

Generally speaking, getting a fairly minimal test case is not 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 is unsuccessful, hackers will see that you made an effort in trying to get an answer, which can make them more willing to work with you.

If you just want someone to review your code, say so at the beginning of your message, and be sure to mention which part you think particularly needs attention and why.

Don’t post your homework problems

Hackers are very good at telling which questions are homework-style questions; most of us have solved such problems ourselves. Likewise, these problems need to be solved by you, and you will learn from doing so. You can ask for a hint, but don’t ask for a complete solution.

If you suspect you have run into a homework-style problem but still cannot 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 may still give you a hint.

Remove meaningless questions

Avoid ending a question with meaningless statements such as 有人能帮我吗？ or 这有答案吗？.

First: if your description of the problem is not very good, asking this way is even more superfluous.

Second: because asking this way is superfluous, hackers will be annoyed by it — and will usually express their contempt with logically correct but meaningless answers, such as: 没错，有人能帮你 or 不，没答案.

In general, avoid questions of the 是或否, 对或错, 有或没有 type unless you want to get 是或否类型的回答.

Even if you are in a hurry, don’t write 紧急 in the title

This is your problem, not ours. Claiming 紧急 is very likely to backfire: most hackers will simply delete questions that rudely and selfishly try to attract immediate attention. More seriously, the word 紧急 (or other attention-seeking titles) is often filtered out by spam filters — and the people you hope will see your question may never see it.

There is a half exception: if you are in some very high-profile place that excites hackers, it may be worth doing this. In that case, if you are under time pressure, mention it politely too, and people may be interested enough to answer faster.

Of course, this is very risky, because what excites hackers is often different from what excites you. For example, posting such a title from the NASA International Space Station is fine, but posting it for self-righteous charitable acts or political causes definitely is not. In fact, posting something like 紧急：帮我救救这个毛茸茸的小海豹！ will definitely get you ignored or irritate hackers, even if they think fluffy little seals are important.

If you find this incredible, you had better read the rest of this guide several more times until you understand it before posting.

Politeness never hurts, and sometimes it even helps

Be courteous, and use 请 and 谢谢您的关注, or 谢谢你的关照, often. Let everyone know that you are grateful for the time they spend helping you for free.

Frankly, this is no more important than — and cannot replace — using clear, correct, precise, grammatical language and avoiding proprietary formats. Hackers generally prefer to read a somewhat brusque but technically clear bug report rather than a polite but vague one. (If this puzzles you, remember that we evaluate questions by what they can teach us.)

(This is part 8 of 12 of the same post.)

However, if you have a whole string of questions to resolve, being polite will certainly increase your chances of getting useful responses.

(We have noticed that since this guide was published, the only serious criticism we have received from veteran hackers concerns thanking in advance. Some hackers feel that 先谢了 carries the implication that there is no need to thank anyone afterward. Our advice is either to say 先谢了 first, then thank the responder afterward, or express gratitude in another way, such as with 谢谢你的关注 or 谢谢你的关照.)

Add a Brief Follow-Up After the Problem Is Solved

After the problem is solved, send a note to everyone who helped you, let them know how it was solved, and thank them again. If the problem attracted widespread attention on a newsgroup or mailing list, it is appropriate to post a note there as well.

The ideal way is to reply to the original thread and include 已修正, 已解决, or another equally clear marker in the subject. On a busy mailing list, a potential responder who sees a thread marked 问题 X or 问题 X - 已解决 will understand that there is no need to waste time on it (unless they personally find 问题 X interesting), and can use that time to solve other problems.

The follow-up does not need to be long or in depth; a simple 你好，原来是网线出了问题！谢谢大家 – Bill is better than saying nothing. In fact, unless the conclusion is truly technical, a short and sweet summary is better than a long essay. Explain how the problem was solved, but there is no need to recount the entire process.

For in-depth problems, posting a summary of the debugging log is helpful. Describe the final state of the problem, explain what solved it, and only after that point out the pitfalls that could have been avoided. The part about avoiding pitfalls should come after the correct solution and other summary material; do not turn this information into a detective novel. Listing the names of those who helped you will win you more friends.

Besides being polite and thoughtful, this kind of follow-up also helps others searching the mailing list/newsgroup/forum find the solution that actually solved your problem, so they can benefit too.

At the very least, this follow-up helps give everyone who helped a sense of satisfaction from the problem being solved. If you are not a technical expert or hacker yourself, trust us: this feeling is very important to the masters or experts you ask for help. Leaving a problem unresolved is discouraging; hackers are eager to see problems solved. Good things come to those who do good—satisfy that desire, and you will reap the benefits the next time you ask a question.

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

Among hackers, this kind of good follow-up is actually more important than conventional etiquette. It is also how you earn a reputation by treating others well, which is a very valuable asset.

How to Interpret Answers

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

There is an ancient and sacred tradition: if you receive RTFM（Read The Fucking Manual） in response, the responder believes you should go read the damn manual. Of course, they are basically right—you should read it.

RTFM has a younger cousin. If you receive STFW（Search The Fucking Web） in response, the responder believes you should go search the damn web. That person is probably right too—go search. (A gentler way to put it is Google 是你的朋友!)

On forums, you may also be asked to dig through old forum posts. In fact, someone may even kindly provide you with a thread where this problem was solved before. But do not rely on this kindness—search the old posts before asking.

Usually, the person who answers you with one of these two phrases will give you a manual or a URL containing what you need, and they are reading it themselves as they type. These replies mean the responder believes:

  • The information you need is very easy to find;
  • Finding it yourself will teach you more than having it spoon-fed to you.

You should not be upset by this; by hacker standards, they have shown you a certain amount of attention instead of ignoring your request. You should thank them for their grandmotherly kindness.

If You Still Don’t Understand

If you cannot understand the response, do not immediately demand an explanation. Try to understand their response first, the same way you tried to solve the problem yourself before (using manuals, FAQs, the web, and the experts around you). If you really need them to explain, remember to show that you have already learned something from it.

For example, if I answer you: 看来似乎是 zentry 卡住了；你应该先清除它。, then this is a very bad follow-up response: zentry 是什么？. A good way to ask would be: 哦~~~我看过说明了但是只有 -z 和 -p 两个参数中提到了 zentries，而且还都没有清楚的解释如何清除它。你是指这两个中的哪一个吗？还是我看漏了什么？

Dealing with Rude Responses

Much of what looks like rudeness in hacker circles is not intended to offend. Rather, it is a blunt, cut-to-the-chase communication style that cares more about solving the problem than about making people feel comfortable while remaining vague.

If you feel offended, try to respond calmly. If someone really steps out of line, the old-timers on the mailing list, newsgroup, or forum will probably call them out. If that does not happen and you lose your temper, then what the person you are angry at said may look normal in the hacker community, while you will be seen as the one at fault, which will hurt your chances of getting information or help.

(This is part 9 of 12 of the same post.)

On the other hand, you will occasionally encounter genuinely rude and obnoxious behavior. Contrary to the above, it is acceptable to hit back hard at genuine offenders and tear them apart with sharp language. However, before acting you must be very, very sure of your ground. Correcting rude remarks is only a hair’s breadth away from starting a pointless flame war, and it is not uncommon for hackers themselves to blunder across that line. If you’re a newbie or outsider, your chances of avoiding such blunders are not high. If what you want is information rather than to pass the time, it’s best not to put your hands on the keyboard and risk it.

(Some people assert that many hackers have a mild form of autism or Asperger’s syndrome and lack the neural circuitry needed to lubricate normal human social interaction. This may or may not be true. If you’re not a hacker yourself, perhaps thinking we’re brain-damaged can help you cope with our odd behavior. Go right ahead—we don’t mind. We like the way we are, and we usually have well-founded doubts about such diagnostic labels.)

Jeff Bigler’s summary of observations on this is also relevant and worth reading (tact filters).

In the next section, we’ll discuss another issue: the 冒犯 you may receive when you behave improperly.

How to Avoid Acting Like a Loser

In forums in the hacker community, you may from time to time screw up in the ways described in this guide or in similar ways. And you will be told publicly how you screwed up, perhaps with a bit of colorful invective thrown into the attack.

After this happens, the worst things you can do are whine about your treatment, claim you’ve been verbally attacked, demand an apology, scream, sulk, threaten legal action, complain to their employer, leave the toilet seat up, and so on. Instead, you should do this:

Get over it. It’s normal. In fact, it’s healthy and reasonable.

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

There are also other hacker forums that, misled by a requirement for excessive politeness, forbid participants from posting any message that finds fault with someone else’s post, claiming 如果你不想帮助用户就闭嘴。; as a result, thoughtful participants leave in droves, and doing so only turns them into meaningless chatter and useless technical forums.

To put it bluntly: do you want “friendliness” (in the above sense) or usefulness? Pick one.

Remember: when a hacker says you’ve screwed up and (however harshly) tells you not to do it again, he is acting out of concern for you and his community. It would be simpler for him to ignore you and filter you out of his life. If you can’t manage gratitude, at least show a little dignity: don’t wail loudly, and don’t expect to be treated like a fragile doll just because you’re a dramatic, supersensitive soul and an entitled newcomer.

Sometimes, even if you didn’t screw up (or only screwed up in his imagination), someone will attack you personally for no reason. In that case, complaining will really make the problem worse.

These troublemakers are either useless types who can’t do anything but think they’re experts, or psychological experts testing whether you’ll really screw up. Other readers will 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 that.

Also, don’t let yourself get drawn into flame wars; it’s best to ignore most flame wars—provided, of course, that you’ve checked and they really are just flame wars, that they haven’t pointed out where you screwed up, and that they haven’t cleverly hidden the real answer to the question behind them (which is also possible).

Questions You Should Not Ask

Here are a few classic stupid questions, along with what hackers are thinking when they don’t answer:

Question: 我能在哪找到 X 程序或 X 资源？

Question: 我怎样用 X 做 Y？

Question: 如何设定我的 shell 提示？

Question: 我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 文件转换为 TeX 格式吗？

Question: 我的程序/设定/SQL 语句没有用

Question: 我的 Windows 电脑有问题，你能帮我吗？

Question: 我的程序不会动了，我认为系统工具 X 有问题

Question: 我在安装 Linux（或者 X ）时有问题，你能帮我吗？

Question: 我怎么才能破解 root 帐号/窃取 OP 特权/读别人的邮件呢？

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

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

Question: How do I use X to do Y?

Answer: If what you’re trying to solve is Y, don’t present a possibly inappropriate method when asking. This kind of question shows that the asker is not only completely ignorant of X but also confused about the problem Y is meant to solve, and has let a particular situation box in their thinking. It’s best to ignore such people until they’ve clarified their question.

Question: How do I set my shell prompt??

Answer: If you’re smart enough to ask this question, you should be smart enough to RTFM and find out for yourself.

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

Answer: Try it and see. If you’ve tried it, you’ll know the answer, and you won’t have wasted my time.

Question: My {program/configuration/SQL statement} doesn’t work
(This is part 10 of 12 of the same post.)

Answer: That isn’t really a question. I have no interest in questions where I have to ask you twenty questions just to figure out what your real question is — I have better things to do. When I see this kind of question, my reaction is usually one of these three:

  • Is there anything else you’d like to add?
  • That’s too bad, I hope you get it sorted out.
  • What does that have to do with me?

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

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

Note: if a program has an official Windows version or interacts with Windows (e.g. Samba), you may ask Windows-related questions; just don’t be surprised when the answer is that the problem comes from the Windows operating system rather than the program itself, because Windows is generally so bad that this is usually correct.

Question: My program has stopped working. I think system tool X is broken.

Answer: You may well be the first person to notice an obvious defect in a system call or library file that has been used over and over by thousands of users. Far more likely, you are completely off base. Extraordinary claims require extraordinary evidence, and when you make a claim like this you must back it up with a clear, detailed bug report.

Question: I’m having trouble installing Linux (or X), can you help me?

Answer: No, I can only find the fault by working on your computer in person. Go find your local Linux user group for hands-on guidance (you can find a list of user groups at 这儿).

Note: if the installation problem relates to a particular Linux distribution, asking on its mailing list, forum, or local user group may be appropriate. In that case, describe the exact details of the problem. Before that, search carefully using Linux with all the suspect hardware as keywords.

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

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

Good Questions and Bad Questions

Finally, I’ll use some examples to show how to ask questions intelligently; two ways of asking the same question are placed side by side, one stupid and one smart.

Stupid question:

Where can I find information about Foonly Flurbamatic?

This question is just begging for an answer like STFW.

Smart question:

I Googled “Foonly Flurbamatic 2600” but didn’t find anything useful. Does anyone know where to look for information on programming this device?

He has already STFW’d — it looks like he really is stuck.

Stupid question:

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

He thinks it’s everyone else’s fault, this arrogant, presumptuous asker.

Smart question:

The foo project code won’t compile under Nulix version 6.2. I’ve read the FAQ, but it says nothing about Nulix-related problems. Here’s a transcript of my compile attempt — is there anything I’m doing wrong?

The asker has stated the environment, read the FAQ, and listed the errors, and he hasn’t dumped the blame on anyone else. His question deserves attention.

Stupid question:

My motherboard has a problem, who’ll help me?

A hacker’s usual answer to this kind of question is 好的，还要帮你拍拍背和换尿布吗？, followed by the delete key.

Smart question:

I tried X, Y and Z on the S2464 motherboard and nothing worked, so I also tried A, B and C. Please note the strange behavior when I try C. Obviously florbish is grommicking, but the results are unexpected. What usually causes grommicking on an Athlon MP motherboard? Does anyone know what tests I should run next to pin down the problem?

This guy, seen from another angle, is worth answering. He’s shown that he can work the problem rather than sitting around waiting for an answer to fall from the sky.

In the last question, note the subtle but important distinction between 告诉我答案 and 给我启示，指出我还应该做什么诊断工作.

In fact, the latter question comes from a real post to the Linux kernel mailing list (lkml) in August 2001. I (Eric) was the one asking. I had observed this inexplicable lockup on a Tyan S2464 motherboard, and the list members supplied important information that solved the problem.

Through the way I asked, I gave people something to chew on; I made it easy and attractive for them to get involved. I showed that I was their equal in ability and invited them to explore the matter with me. By telling them about the blind alleys I’d already gone down, so they wouldn’t waste time on them, I also showed respect for their valuable time.

Afterwards, when I thanked everyone and expressed my appreciation for the good discussion, one member of the Linux kernel mailing list said he felt my question got answered not because I was a name on that list, but because I asked it the right way.

(This is part 11 of 12 of the same post.)

Hackers, from a certain angle, are people with abundant knowledge but no gift for human warmth; I believe he’s right — if I ask questions like a beggar, then no matter who I am, I’m bound to annoy some people or be ignored by them. He suggested I write this down, which directly led to the creation of this guide.

If You Don’t Get an Answer

If you still don’t get an answer, please don’t assume we think we can’t help you. Sometimes it’s simply that the people who saw your question don’t know the answer. No response doesn’t mean you were ignored, though admittedly that distinction is hard to tell.

In general, simply reposting your question is a very bad idea. It will be seen as meaningless noise. Have some patience: the person who knows the answer to your question may live in a different time zone, may be asleep, or your question may simply not have been well organized to begin with.

You can get help through other channels, which are usually better suited to beginners’ needs.

There are many online and local user groups made up of enthusiastic software hobbyists (even if they may never have written any software themselves). People usually form such groups to help each other and to help newcomers.

In addition, you can seek help from many commercial companies, large or small. Don’t be frustrated that you have to pay for help! After all, if your car’s engine cylinder gasket blows — entirely possible — you still have to take it to a repair shop and pay for the repair. 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 simply impossible for one person to handle support calls from tens of thousands of users. Keep in mind that even if you pay for such assistance, what you pay is negligible compared with similar software you’d buy (closed-source software technical support usually costs far more than open source and delivers far less).

How to Answer Questions Well

Be a little kinder. The pressure of a problem often makes people seem rude or stupid when they really aren’t.

Reply privately to first-time offenders. There’s no need to publicly humiliate someone who honestly made a mistake; a genuine newbie may not even know how to search or where to find the FAQ.

If you’re not sure, say so! A confident-sounding wrong answer is worse than none at all. Don’t send people down the wrong path just because it’s fun to sound like an expert. Be modest and honest, and set a good example for both the asker and your peers.

If you can’t help, don’t hinder. Don’t joke around with actual steps — that might ruin the asker’s setup; some poor sucker will take it as a real instruction.

Probe with tentative follow-up questions to draw out more detail. If you do it well, the asker can learn something — and so can you. Try turning a dumb question into a good one, and don’t forget that we were all newbies once.

Although it’s legitimate to grumble RTFM at the lazy ones, it’s better to provide a link to the documentation (even if it’s just suggesting Google search keywords).

If you decide to answer, give a good answer. When someone is using the wrong tool or approach, don’t suggest a clumsy workaround; recommend a better tool and reframe the problem.

Answer the question positively! If the asker has clearly researched deeply and shown that they’ve tried X, Y, Z, A, B, and C without results, replying with 试试看 A 或是 B or 试试 X 、 Y 、 Z 、 A 、 B 、 C plus a link is completely useless.

Help your community learn from questions. When you reply to a good question, ask yourself 如何修改相关文件或常见问题文件以免再次解答同样的问题？, then send a patch to the maintainer.

If you answer only after doing some research, show your technique rather than just handing over the result. After all, 授人以鱼不如授人以渔.

If you need basic knowledge about how personal computers, Unix systems, and networks work, see Unix 系统和网络基本原理.

When you release software or patches, try to follow 软件发布实践.

Acknowledgments

Evelyn Mitchel contributed some examples of dumb questions and inspired the writing of the 如何更好地回答问题 section; Mikhail Ramendik contributed some especially valuable suggestions and improvements.

(This is part 12 of 12 of the same post.)