Reprinted from: The wisdom of asking questions
Statement
Many projects link to this guide in their help/help pages, which is great and we encourage everyone to do the same. But if you are the person responsible for managing this project’s web page, please indicate this prominently near the hyperlink:
**This guide does not provide actual support services for this project! **
We have learned deeply the pain caused by the above statement. Without this statement, we are constantly being pestered by idiots. These idiots think that since we publish this guide, we have a responsibility to solve every technical problem in the world.
If you’re reading this guide because you’re looking for some help, and come away feeling like you could use direct help from the author of this article, then you’re one of those idiots we mentioned earlier. Don’t ask us questions, we’ll just ignore you. We’re teaching you in this guide how to get help from the people who actually understand the software or hardware problem you’re having, and 99% of the time that won’t be us. Unless you’re sure that one of the authors of this guide happens to be an expert in your problem area, don’t bother us and everyone will be happier.
Introduction
In the world of hacker, when you ask a technical question, whether you can get a useful answer in the end often depends on the way you ask and follow up. This guide will teach you how to ask the right questions to get answers that satisfy you.
Not just hackers, open source (Open Source) software is now quite popular, and you can often get good answers from other experienced users, which is a good thing; users are often more tolerant of problems that novices often encounter than hackers. However, treating experienced users as hackers and communicating with them using the methods outlined in this guide is also the most effective way to get satisfactory answers from them.
The first thing you should understand is that hackers love challenging problems, or good questions that stimulate their thinking. If we weren’t, we wouldn’t be the people you want to ask about. If you give us a good question worth chewing over, we’ll be grateful. Good questions are motivational and great gifts. Good questions improve our understanding and often expose issues we never realized or thought about before. To a hacker, “Good question!” is a sincere compliment.
Still, hackers have a reputation for being disdainful or arrogant when it comes to simple problems, which sometimes makes us seem hostile to newbies and the ignorant, but that’s not the case.
We make no secret of our disdain for those who don’t want to think, or don’t do what they should before asking. Those people are time killers – they only take, never give, consuming our time that could be spent on more interesting questions or people more worthy of answering. We call such a person 失败者（撸瑟） (for historical reasons, we sometimes spell it lusers).
We realized that many people just wanted to use the software we wrote and had no interest in learning the technical details. For most people, computers are just a tool, a means to an end. They have their own lives and more important things to do. We understand this and never expect everyone to be interested in the technical issues that fascinate us. Nonetheless, our style of answering questions directed at those who are genuinely interested and willing to actively participate in solving the problem will not change and should not change. If even that changes, we are becoming less effective at doing what we do best.
We (largely) volunteer, take time out of our busy lives to answer questions, and are often inundated with questions. So we ruthlessly filter out some topics, especially those who look like losers, in order to use our time more efficiently to answer 赢家（winner） questions.
If you are disgusted by our attitude, condescension, or arrogance, try to put yourself in our shoes. We’re not asking you to submit to us - in fact, most of us are more than happy to interact with you as equals, and as long as you make a small effort to meet the basic requirements, we’ll welcome you into our culture. But asking us to help those who are unwilling to help themselves is ineffective. It’s okay to be ignorant, but it’s not okay to act like an idiot.
So, you don’t have to be technically proficient to attract our attention, but you do have to exhibit the traits that lead to that prowess — being alert, thoughtful, observant, and willing to take an active part in solving problems. If you can’t do these things that make you unique, we recommend that you spend some money to sign a technical support service contract with a commercial company instead of asking individual hackers to help you for free.
If you decide to seek help from us, of course you don’t want to be seen as a loser, let alone be one of the losers. The best way to get quick, effective answers right away is to ask like a winner—smart, confident, with a problem-solving mindset, but who just needs a little help occasionally with a particular question.
(Suggestions for improving this guide are welcome. You can email your suggestions to esr@thyrsus.com or respond-auto@linuxmafia.com. Please note, however, that this article is not a general guide to netiquette, and we generally reject suggestions that do not contribute to useful answers in technical forums.)
Before asking a question
Before you ask a technical question via email, newsgroup, or chat room, please do the following:
- Try searching for answers in old posts on the forum where you are asking a question.
- Try searching online to find the answer.
- Try reading the manual to find the answer.
- Try reading the Frequently Asked Questions document (FAQ) to find answers.
- Try to check or experiment on your own to find the answer.
- Ask your strong friends to find out.
- If you are a program developer, try reading the source code to find the answer.
When you ask a question, show that you’ve done the above; this will help establish that you’re not a freeloader who’s wasting other people’s time. It would be better if you could also express what you learned in the process of doing the above efforts, because we are more willing to answer questions from people who show that they can learn from the answers.
Using some strategies, such as first Googling the various error messages you encounter (searching Google Forums and the web) may lead directly to files or mailing list threads that may solve the problem. Even if there are no results, adding 我在 Google 中搜过下列句子但没有找到什么有用的东西 when asking for help on a mailing list or newsgroup is a good thing, even if it just indicates what help the search engine cannot provide. Doing this (plus the searched string) also allows other people with similar questions to be directed to your question by search engines.
Take it easy, don’t expect a few seconds of Google search to solve a complex problem. Before asking an expert for help, read the FAQ, relax, get comfortable, and take some time to think about the problem. Trust us, they can tell from your questions how much reading and thinking you have done. If you come prepared, you will be more likely to get an answer. Don’t throw out all the questions at once just because your first search didn’t turn up the answer (or turned up too many answers).
Prepare your questions and think about them carefully, because hasty questions will only lead to hasty answers, or no answers at all. The more you can demonstrate the effort you put into solving the problem before asking for help, the more likely you are to receive substantial help.
Be careful not to ask the wrong questions. If your question is based on incorrect assumptions, a J. Random Hacker will probably answer you with meaningless literal explanations while thinking 蠢问题… in his head, hoping that you will learn from the answer to the question (rather than the answer you want to get).
Never think you are qualified to have the answer, you are not; you are not. After all, you are not paid anything for this service. You will earn an answer yourself by asking a question that is meaningful, interesting, and thought-provoking - a question that has the potential to contribute to the community’s experience, rather than just passively soliciting 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 be answered than 请把我需要的确切的过程贴出来. Because you show that you have the ability and determination to get it done if only someone can point you in the right direction.
When you ask a question
Choose the forum where you ask questions carefully
Choose the occasion where you ask your question carefully. You’re likely to be ignored or viewed as a failure if you do any of the following:
- Post your question in a forum off-topic.
- Post very basic questions in forums that discuss advanced technical questions; and vice versa.
- Cross-posting the same question on too many different news groups.
- Send a private email to someone who is neither an acquaintance nor obligated to solve your problem.
Hackers will weed out questions that are misplaced to protect their communication channels from being flooded with irrelevant stuff. You don’t want this 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 websites most relevant to the difficult software or hardware problem you’re experiencing. There are usually links to FAQs, mailing lists, and related documentation. If your efforts (including reading the FAQ) are fruitless, there may be a process or link for bug-reporting on the website. If so, check it out.
Sending emails to unknown people or forums is probably the riskiest thing to do. For example, don’t assume that the author of a content-rich web page will want to serve as your free consultant. Don’t be too optimistic about whether your question will be received—if you’re not sure, send it elsewhere, or don’t send it at all.
When choosing a forum, news group, or mailing list, don’t rely too much on the name. Check the FAQ or permission slip first to see if your question is relevant. Browsing through existing topics before posting will give you a feel for the culture. In fact, it’s a good idea to search the history of newsgroups or mailing lists beforehand for keywords related to your question, and you may be able to find the answer. Even if not, it can help you formulate better questions.
Don’t “machine gun” all avenues of help at once, as this can be as unpleasant as shouting. Come one by one.
Figure out your theme! One of the most typical mistakes is to ask a question about a Unix or Windows operating system program interface in a forum dedicated to a cross-platform portable language, suite, or tool. If you don’t understand why this is a big mistake, it’s best not to ask anything until you understand the difference.
Generally speaking, asking a question in a carefully selected public forum will result in a more useful answer than asking the same question in a private forum. There are several reasons to support this, one is the number of potential responders, and the other is the size of the audience. Hackers are more likely to answer questions that can help a lot of people.
Understandably, sophisticated hackers and the authors of some popular software are receiving a plethora of misinformation. Like the straw that breaks the camel’s back, your inclusion can also take things to an extreme - several times, authors of popular software have withdrawn support for their software because the accompanying influx of useless emails into their personal mailboxes became unbearable.
Stack Overflow
Search, then ask on Stack Exchange.
In recent years, the Stack Exchange community has become a primary channel for answering technical and other questions, especially those about open source projects.
Because Google indexing is instant, search on Google before looking at Stack Exchange. There’s a high chance that someone has already asked a similar question, and Stack Exchange sites tend to be among the first results. If you don’t find any answers on Google, look for them on a website specific to the topic. Searching with tags allows you to narrow down your search results.
Stack Exchange has grown to over a hundred websites, the following are the most commonly used sites:
- Super User asks some general computer questions. If your question has nothing to do with coding or writing programs, but is just about network connections and the like, please go here.
- Stack Overflow is for asking questions related to writing programs.
- Server Fault asks questions related to the server and network management.
Website and IRC Forum
Your local user group, or your Linux distribution may be promoting their web forum or IRC channel with newbie help (in some non-English speaking countries, the newbie forum may also be a mailing list). These are good places to start asking questions, especially if you think you may have a relatively simple or common problem. Ad-sponsored IRC channels are places where questions are openly welcomed and responses can often be immediate.
In fact, if the problem with the program only occurs with the version provided by a specific Linux distribution (which is very common), it is better to ask the question in the forum or mailing list of that distribution first, and then ask the question in the forum or mailing list of the program itself. (Otherwise) the project’s hackers might just reply “use our version”.
Before posting in any forum, make sure there is a search function. If so, try searching for a few keywords of the question, maybe this will help. If you’ve done a general web search before (and you should), search the forum again. Search engines may not have time to index the entire content of the forum.
There is a growing trend to provide user support services through forums or IRC channels, while email is mostly reserved for communication between project developers. So it’s best to first seek assistance with the project in the forums or IRC.
When using IRC, it’s best not to post long problem descriptions in the first place, which some people call channel flooding. It’s best to start the chat with a one-sentence description of the problem.
The second step is to use the project mailing list
When a project provides a developer mailing list, ask questions to the list rather than to the individual members of the list, even if you are sure he can best answer your question. Check the project’s documentation and home page, find the project’s mailing list and use it. There are several good reasons for this approach:
- Any questions good enough to be asked of individual developers will also benefit the entire project group. On the other hand, if you think your question is too stupid for the entire project team, it is not a reason to harass individual developers.
- Asking questions to the list can spread the burden on developers. Individual developers (especially project leaders) may be too busy to answer your questions.
- Most mailing lists will be archived, and those archived content will be indexed by search engines. If you ask a question on the list and get an answer, others in the future can find your question and answer through a web search, so you don’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 questions are only asked privately, no one will see the full context of the most common questions.
If a project has both “users” and “developers” (or “hackers”) mailing lists or forums, and you don’t have access to the source code, ask questions on the “users” list or forum. Don’t assume you’ll be welcome on the developer list, as those people will probably see your question as noise that’s distracting from their development.
However, if you are sure that your problem is unique and you haven’t received a reply in the “Users” list or forum for a few days, try asking in the “Developers” list or forum. It is recommended that you sit back and watch for a few days to get a feel for how things are done there before posting (in fact this is a good idea to participate in any private or semi-private list)
If you can’t find a project’s mailing list and can only find the email address of the project maintainer, feel free to send him a message. Even in this case, don’t assume the (project) mailing list doesn’t exist. In your email, state that you have tried but failed to find a suitable mailing list, and also mention that you have no objection to your email being forwarded to others (many people believe that private email should not be made public, even if it is nothing secret. By allowing your email to be forwarded to others, you give the appropriate person a choice in what to do with your email).
Use meaningful and descriptive titles
In a mailing list, news group, or forum, a title of approximately 50 words or less is a good opportunity to grab the attention of a senior expert. Don’t waste this opportunity by nagging 帮帮忙, 跪求, 急 (not to mention something as offensive as 救命啊！！！！, which will be reflexively ignored). Don’t try to impress us with your level of pain. Instead, use a very simple and concise description to raise the question in this space.
An example of a good title is an 目标 —— 差异 style description, which is what many technical support organizations do. In the 目标 part, it is pointed out which thing or group of things is problematic, and in the 差异 part, it describes the inconsistency with the expected behavior.
Stupid question: Help! My laptop can’t display properly!
Smart question: The mouse cursor in X.org 6.8.1 will be deformed with a certain brand of graphics card MV1005 chipset.
Smarter question: The mouse cursor of X.org 6.8.1 will be deformed in the environment of a certain brand of graphics card MV1005 chipset.
The process of writing an 目标 —— 差异-style description helps you organize your detailed thinking about the problem. What was affected? Is it just the mouse cursor or are there other graphics? Only in version X of X.org? Or just in version 6.8.1? Is it for a certain brand of graphics card chipset? Or just the MV1005 model among them? A hacker can immediately understand your environment and the problems you are encountering with just one glance.
To summarize, imagine you are searching in an index of archived threads that only displays titles. Making your title better reflect the question will allow the next person searching for a similar question to follow the thread without asking the same question again.
If you want to ask a question in your reply, remember to change the title of the content to indicate that you are asking a question. A title that looks like Re: 测试 or Re: 新 bug will hardly attract enough attention. In addition, without affecting the coherence, appropriately quoting and deleting the previous content can leave clues for new readers.
For threads, don’t just click reply to start a completely new thread, as this will limit your audience. Because some email readers, such as mutt, allow users to sort by threads and hide messages by collapsing threads, people who do this will never see your messages.
Just changing the title isn’t enough. mutt and some other mail readers also check for information beyond the message header in order to assign it a thread. So rather send a brand new email.
In web forums, good questions are slightly different, because the thread is tightly tied to the specific message and the content is usually not visible outside the thread, so it is acceptable to reply to the question rather than changing the title. Not all forums allow separate titles in replies, and if you do, almost no one will read it. However, by replying to questions, this is inherently ambiguous, as they will only be read by the person who is viewing the title. So, unless you just want to ask the question among the people currently active in the thread, it’s better to start a new one.
Make questions easy to respond to
Ending your question with 请将你的回复发送到…… will probably get you no answer. If you think it’s troublesome to spend a few seconds setting up a reply address in your email client, we also think it’s more troublesome to spend a few seconds thinking about your problem. If your mail program does not support this, change to a better one; if the operating system does not support this mail program, also change to a better one.
In a forum, it’s extremely rude to ask for a reply via email, unless you think the reply may be sensitive (someone would, for some unknown reason, want the answer to be known only to you and not to the entire forum). If you just want to be notified via email when someone replies to a thread, you can ask the web forum to send it to you. Almost all forums support functions such as 追踪此讨论串, 有回复时发送邮件提醒, etc.
Use clear, correct, precise and grammatically correct statements
We have found from experience that careless questioners are usually careless in programming and thinking (I can guarantee it). It’s not worth answering the unwary’s questions; we’d rather spend our time elsewhere.
Correct spelling, punctuation, and capitalization are important. Generally speaking, if you think it’s troublesome to do this and don’t want to care about it, then we also think it’s troublesome and don’t want to care about your questions. Put a little extra thought into your words and don’t have to be rigid and formal - in fact, hacker culture values the accurate use of informality, slang, and humor. But it must be accurate and show signs that you are thinking and paying attention to the problem.
Spell correctly, use punctuation and capitalization, and do not confuse its with it's, loose with lose or discrete with discreet. Don’t use all caps, that will be seen as a rude shouting (all lowercase is no better because it’s harder to read. Alan Cox might be able to do that, but you can’t).
To put it more bluntly, if you write like a semi-literate person, you will probably not be ignored. Also do not use instant messaging abbreviations or Martian. For example, simplifying 的 to d will make you look like a novice who saves words in order to save a few keys. What’s worse is that if you draw talismans like a child, you are definitely seeking death, and you can be sure that no one will pay attention to you (or at best, they will give you a lot of criticism and sarcasm).
If you’re asking in a forum where you’re not speaking your native language, you can make a few mistakes in spelling and grammar, but you can’t be sloppy in your thinking (yes, we can usually tell the difference). Also, write in English unless you know the language of the respondent. Busy hackers often simply delete messages written in a language they don’t understand. English is the universal language on the Internet, and writing in English minimizes the likelihood that your question will be deleted without even being read.
If English is your second language, it is good to remind potential respondents of your potential language difficulties: [Translation Note: The original text is attached below for your use]
English is not my native language; please excuse typing errors.
*English is not my native language, please forgive my typos or grammar.
If you speak $LANGUAGE, please email/PM me; I may need assistance translating my question.
- If you speak a certain language, please send me a letter/PM; 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 technical terms, but I don’t know much about common sayings 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 wrote my question in language and in English, if you answer in only one language I will be happy to translate it into another.
Send questions using an easy-to-read, standard file format
If you make a question artificially difficult to read, it will most likely be ignored. People would rather read a question that is easy to understand, so:
- Use plain text instead of HTML (Turn off HTML is not difficult).
- It is usually okay to use MIME attachments as long as there is actual content (such as attached source code or patch) and not just a template generated by the mail program (such as just a copy of the message content).
- Don’t send an email where the text is just a one-line sentence but wraps into multiple lines (which makes it very difficult to reply to part of the text). Assuming your readers are reading the email on a terminal that is 80 characters wide, it is best to set your line break point to less than 80 characters.
- However, do not set a fixed width for some special files (such as log file copies or session records). The data should be included as is, giving respondents confidence that they are seeing the same thing you are seeing.
- In English forums, do not use
Quoted-PrintableMIME encoding to send messages. This encoding may be necessary for posting non-ASCII languages, but many mail programs do not support it. When they handle line breaks, those=20symbols scattered throughout the text are ugly and distracting, and may even ruin the semantics of the content. - Definitely, never expect hackers to read documents written in a closed format, such as Microsoft Word or Excel files. Most hackers would react to this like you would if someone dumped steaming pig manure on your doorstep. Even if they can handle it, they hate doing it.
- If you’re sending email from a Windows computer, turn off Microsoft’s stupid
智能引号feature (check the智能引号radio box from Options > Proofing > AutoCorrect Options) to avoid spamming your emails with junk characters. - In the forum, do not abuse the
表情符号andHTMLfunctions (when they are provided). One or two emojis are usually fine, but fancy colored text tends to make people think you’re a wimp. Overusing emojis, colors, and fonts can make you look like a giggling little girl. This is usually not a good idea unless you’re just interested in the sex and not the answers.
If you use a graphical user interface mail program (such as Microsoft Outlook or similar), be aware that their default settings may not necessarily meet these requirements. Most of these programs have a menu-based 查看源代码 command that you can use to check the mail in your outgoing folder to make sure you are sending a plain text file without any weird characters.
Describe the problem accurately and make sense
- Carefully and clearly describe the symptoms of your problem or bug.
- Describe the environment in which the problem occurs (machine configuration, operating system, applications, and related information), and provide the dealer’s release and version number (such as:
Fedora Core 4,Slackware 9.1, etc.). - Describe how you researched and understood the question before asking it.
- Describe the diagnostic steps taken to identify the problem before asking questions.
- Describe any recent hardware or software changes that may be relevant.
- Provide a method that can
重现这个问题的可控环境as much as possible.
Try to guess what a hacker will ask you, and answer the questions the hacker may have before you ask.
Of the above points, when you are reporting a problem that you think may be in the code, it is especially important to give hackers an environment in which they can reproduce your problem. When you do this, your chances and speed of getting a valid answer will be greatly improved.
Simon Tatham wrote an excellent article called “How to Report Bugs Effectively”. I highly recommend you read it too.
Don’t talk too much but be precise
You need to provide accurate and informative information. This does not require you to simply transcribe a bunch of error code or information into your question. If you have a large and complex test case that reproduces a crash situation, try to trim it as small as possible.
This has at least three uses. First, showing that you have made an effort to simplify the question will increase your chances of getting an answer; Second, simplifying the question makes you more likely to get a useful answer; Third, in the process of refining your bug report, you are likely to find a solution or workaround yourself.
Don’t always claim to have found a bug
When you encounter a problem while using software, don’t easily claim to have found a bug unless you are very, *very well-founded. Tip: Unless you can provide a source code patch that fixes the problem, or provide regression tests that show incorrect behavior in a previous version, you probably won’t be completely convinced. The same applies to web pages and files. If you (claim to) have found Bug for a file, you should be able to provide a correction or replacement file in the corresponding location.
Remember, there are many other users who haven’t encountered the problem you noticed, otherwise you would have discovered it while reading the document or searching the web (you [have done this, right] before complaining (#before asking)?). This also means that it’s more likely that you’ve made a mistake than there is a problem with the software itself.
People who write software always work very hard to make it as perfect as possible. If you claim to have found a bug, you are questioning their ability, and even if you are right, you may offend some of them. This is especially serious when you scream about having Bug in the title.
When asking a question, even if you’re secretly convinced that you’ve found a real bug, it’s best to write like you did something wrong. If there is a bug, you will see this in the reply. This way, if there is a bug, the maintainer will apologize to you, which is better than if you pissed off someone and then owe them an apology.
Being humble cannot replace your homework.
Some people understand that they shouldn’t ask questions and demand answers rudely or arrogantly, but they choose the other extreme - talking down to them: 我知道我只是个可悲的新手，一个撸瑟，但.... This is both annoying and unhelpful, especially when accompanied by a description that is vaguely relevant to the actual problem.
Stop wasting your time and mine with primitive primate tricks. Instead, describe the background conditions and your problem situation as clearly as possible. This positions you better than talking down to someone.
Sometimes online forums will have a section specifically for newbies to ask questions. If you really think you have a beginner’s question, just go there, but don’t be so down-to-earth.
Describe the symptoms of the problem rather than your guess
Telling hackers how you think the problem is caused isn’t helpful. (If your inferences are so valid, why bother asking others for help?) So make sure you tell them the symptoms of the problem, not your explanations and theories; let the hackers speculate and diagnose. If you think it’s important to state your guesses, clearly state that they are just guesses on your part, and describe why they don’t work.
Stupid question
I encountered SIG11 errors one after another when compiling the kernel. I suspect that a flying cable is connected to the motherboard trace. What is the best way to check this situation?
Smart Questions
My assembled computer is a FIC-PA2007 motherboard with an AMD K6/233 CPU (VIA Apollo VP2 chipset), 256MB Corsair PC133 SDRAM memory. When compiling the kernel, SIG11 errors occur frequently after 20 minutes of booting. But the same problem never happened in the first 20 minutes. Restarting didn’t help, but shutting it down overnight got me working for another 20 minutes. All memory has been replaced with no effect. The relevant parts of the standard compilation record are as follows….
Since this seems to be a struggle for many, here’s a reminder: 所有的诊断专家都来自密苏里州。 The official motto of the U.S. Department of State is: 让我看看 (from a speech by Congressman Willard D. Vandiver in 1899: 我来自一个出产玉米，棉花，牛蒡和民主党人的国家，滔滔雄辩既不能说服我，也不会让我满意。我来自密苏里州，你必须让我看看。) For the diagnostician, this is not a suspicion, but simply a real and useful need to see something that is as consistent as possible with the raw evidence you see, rather than your guesswork and inductive conclusions. So, show it to us generously!
List the problem symptoms in order of occurrence time
A series of operations before a problem occurs are often the most helpful clues for finding the problem. Therefore, your instructions should include the steps you took and how the machine and software reacted until the problem occurred. In the case of command line processing, it can be helpful to provide a record of the operation (for example, generated by running a script tool) and quote the relevant number of lines (for example, 20 lines) of the record.
If the hanging program has diagnostic options (such as the -v verbose switch), try selecting these options to add debugging information to the log. Remember, 多 is not equal to 好.试着选取适当的调试级别以便提供有用的信息而不是让读者淹没在垃圾中。
如果你的说明很长（如超过四个段落），在开头简述问题，接下来再按时间顺序详述会有所帮助。这样黑客们在读你的记录时就知道该注意哪些内容了。
描述目标而不是过程
如果你想弄清楚如何做某事（而不是报告一个 Bug），在开头就描述你的目标，然后才陈述重现你所卡住的特定步骤。
经常寻求技术帮助的人在心中有个更高层次的目标，而他们在自以为能达到目标的特定道路上被卡住了，然后跑来问该怎么走，但没有意识到这条路本身就有问题。结果要费很大的劲才能搞定。
蠢问题
我怎样才能从某绘图程序的颜色选择器中取得十六进制的的 RGB 值？
聪明问题
我正试着用替换一幅图片的色码（color table）成自己选定的色码，我现在知道的唯一方法是编辑每个色码区块（table slot）， 但却无法从某绘图程序的颜色选择器取得十六进制的的 RGB 值。
第二种提问法比较聪明，你可能得到像是建议采用另一个更合适的工具的回复。
别要求使用私人电邮回复
黑客们认为问题的解决过程应该公开、透明，此过程中如果更有经验的人注意到不完整或者不当之处，最初的回复才能够、也应该被纠正。同时，作为提供帮助者可以得到一些奖励，奖励就是他的能力和学识被其他同行看到。
当你要求私下回复时，这个过程和奖励都被中止。别这样做，让回复者来决定是否私下回答 —— 如果他真这么做了，通常是因为他认为问题编写太差或者太肤浅，以至于对其它人没有兴趣。
这条规则存在一条有限的例外，如果你确信提问可能会引来大量雷同的回复时，那么这个神奇的提问句会是向我发电邮，我将为论坛归纳这些回复。试着将邮件列表或新闻群组从洪水般的雷同回复中解救出来是非常有礼貌的 —— 但你必须信守诺言。
清楚明确的表达你的问题以及需求
漫无边际的提问是近乎无休无止的时间黑洞。最有可能给你有用答案的人通常也正是最忙的人（他们忙是因为要亲自完成大部分工作）。这样的人对无节制的时间黑洞相当厌恶，所以他们也倾向于厌恶那些漫无边际的提问。
如果你明确表述需要回答者做什么（如提供指点、发送一段代码、检查你的补丁、或是其他等等），就最有可能得到有用的答案。因为这会定出一个时间和精力的上限，便于回答者能集中精力来帮你。这么做很棒。
要理解专家们所处的世界，请把专业技能想像为充裕的资源，而回复的时间则是稀缺的资源。你要求他们奉献的时间越少，你越有可能从真正专业而且很忙的专家那里得到解答。
所以，界定一下你的问题，使专家花在辨识你的问题和回答所需要付出的时间减到最少，这技巧对你有用答案相当有帮助 —— 但这技巧通常和简化问题有所区别。因此，问我想更好的理解 X，可否指点一下哪有好一点说明？通常比问你能解释一下 X 吗？更好。如果你的代码不能运作，通常请别人看看哪里有问题，比要求别人替你改正要明智得多。
询问有关代码的问题时
别要求他人帮你调试有问题的代码，不提示一下应该从何入手。张贴几百行的代码，然后说一声：它不能工作会让你完全被忽略。只贴几十行代码，然后说一句：在第七行以后，我期待它显示 <x>，但实际出现的是 <y>比较有可能让你得到回应。
最有效描述程序问题的方法是提供最精简的 Bug 展示测试用例（bug-demonstrating test case）。什么是最精简的测试用例？那是问题的缩影；一小个程序片段能刚好展示出程序的异常行为，而不包含其他令人分散注意力的内容。怎么制作最精简的测试用例？如果你知道哪一行或哪一段代码会造成异常的行为，复制下来并加入足够重现这个状况的代码（例如，足以让这段代码能被编译/直译/被应用程序处理）。如果你无法将问题缩减到一个特定区块，就复制一份代码并移除不影响产生问题行为的部分。总之，测试用例越小越好（查看话不在多而在精一节）。
一般而言，要得到一段相当精简的测试用例并不太容易，但永远先尝试这样做的是种好习惯。这种方式可以帮助你了解如何自行解决这个问题 —— 而且即使你的尝试不成功，黑客们也会看到你在尝试取得答案的过程中付出了努力，这可以让他们更愿意与你合作。
如果你只是想让别人帮忙审查（Review）一下代码，在信的开头就要说出来，并且一定要提到你认为哪一部分特别需要关注以及为什么。
别把自己家庭作业的问题贴上来
黑客们很擅长分辨哪些问题是家庭作业式的问题；因为我们中的大多数都曾自己解决这类问题。同样，这些问题得由你来搞定，你会从中学到东西。你可以要求给点提示，但别要求得到完整的解决方案。
如果你怀疑自己碰到了一个家庭作业式的问题，但仍然无法解决，试试在使用者群组，论坛或（最后一招）在项目的使用者邮件列表或论坛中提问。尽管黑客们会看出来，但一些有经验的使用者也许仍会给你一些提示。
去掉无意义的提问句
避免用无意义的话结束提问，例如有人能帮我吗？或者这有答案吗？。
首先：如果你对问题的描述不是很好，这样问更是画蛇添足。
其次：由于这样问是画蛇添足，黑客们会很厌烦你 —— 而且通常会用逻辑上正确，但毫无意义的回答来表示他们的蔑视， 例如：没错，有人能帮你或者不，没答案。
一般来说，避免用 是或否、对或错、有或没有类型的问句，除非你想得到是或否类型的回答。
即使你很急也不要在标题写紧急
这是你的问题，不是我们的。宣称紧急极有可能事与愿违：大多数黑客会直接删除无礼和自私地企图即时引起关注的问题。更严重的是，紧急这个字（或是其他企图引起关注的标题）通常会被垃圾信过滤器过滤掉 —— 你希望能看到你问题的人可能永远也看不到。
有半个例外的情况是，如果你是在一些很高调，会使黑客们兴奋的地方，也许值得这样去做。在这种情况下，如果你有时间压力，也很有礼貌地提到这点，人们也许会有兴趣回答快一点。
当然，这风险很大，因为黑客们兴奋的点多半与你的不同。譬如从 NASA 国际空间站（International Space Station）发这样的标题没有问题，但用自我感觉良好的慈善行为或政治原因发肯定不行。事实上，张贴诸如紧急：帮我救救这个毛绒绒的小海豹！肯定让你被黑客忽略或惹恼他们，即使他们认为毛绒绒的小海豹很重要。
如果你觉得这点很不可思议，最好再把这份指南剩下的内容多读几遍，直到你弄懂了再发文。
礼多人不怪，而且有时还很有帮助
彬彬有礼，多用请和谢谢您的关注，或谢谢你的关照。让大家都知道你对他们花时间免费提供帮助心存感激。
坦白说，这一点并没有比清晰、正确、精准并合法语法和避免使用专用格式重要（也不能取而代之）。黑客们一般宁可读有点唐突但技术上鲜明的 Bug 报告，而不是那种有礼但含糊的报告。 （如果这点让你不解，记住我们是按问题能教给我们什么来评价问题的价值的）
然而，如果你有一串的问题待解决，客气一点肯定会增加你得到有用回应的机会。
（我们注意到，自从本指南发布后，从资深黑客那里得到的唯一严重缺陷反馈，就是对预先道谢这一条。一些黑客觉得先谢了意味着事后就不用再感谢任何人的暗示。我们的建议是要么先说先谢了，然后事后再对回复者表示感谢，或者换种方式表达感激，譬如用谢谢你的关注或谢谢你的关照。）
问题解决后，加个简短的补充说明
问题解决后，向所有帮助过你的人发个说明，让他们知道问题是怎样解决的，并再一次向他们表示感谢。如果问题在新闻组或者邮件列表中引起了广泛关注，应该在那里贴一个说明比较恰当。
最理想的方式是向最初提问的话题回复此消息，并在标题中包含已修正，已解决或其它同等含义的明显标记。在人来人往的邮件列表里，一个看见讨论串问题 X和问题 X - 已解决的潜在回复者就明白不用再浪费时间了（除非他个人觉得问题 X的有趣），因此可以利用此时间去解决其它问题。
补充说明不必很长或是很深入；简单的一句你好，原来是网线出了问题！谢谢大家 – Bill比什么也不说要来的好。事实上，除非结论真的很有技术含量，否则简短可爱的小结比长篇大论更好。说明问题是怎样解决的，但大可不必将解决问题的过程复述一遍。
对于有深度的问题，张贴调试记录的摘要是有帮助的。描述问题的最终状态，说明是什么解决了问题，在此之后才指明可以避免的盲点。避免盲点的部分应放在正确的解决方案和其它总结材料之后，而不要将此信息搞成侦探推理小说。列出那些帮助过你的名字，会让你交到更多朋友。
除了有礼貌和有内涵以外，这种类型的补充也有助于他人在邮件列表/新闻群组/论坛中搜索到真正解决你问题的方案，让他们也从中受益。
至少，这种补充有助于让每位参与协助的人因问题的解决而从中得到满足感。如果你自己不是技术专家或者黑客，那就相信我们，这种感觉对于那些你向他们求助的大师或者专家而言，是非常重要的。问题悬而未决会让人灰心；黑客们渴望看到问题被解决。好人有好报，满足他们的渴望，你会在下次提问时尝到甜头。
思考一下怎样才能避免他人将来也遇到类似的问题，自问写一份文件或加个常见问题（FAQ）会不会有帮助。如果是的话就将它们发给维护者。
在黑客中，这种良好的后继行动实际上比传统的礼节更为重要，也是你如何透过善待他人而赢得声誉的方式，这是非常有价值的资产。
如何解读答案
RTFM 和 STFW：如何知道你已完全搞砸了
有一个古老而神圣的传统：如果你收到RTFM （Read The Fucking Manual）的回应，回答者认为你应该去读他妈的手册。当然，基本上他是对的，你应该去读一读。
RTFM 有一个年轻的亲戚。如果你收到STFW（Search The Fucking Web）的回应，回答者认为你应该到他妈的网上搜索。那人多半也是对的，去搜索一下吧。 （更温和一点的说法是 Google 是你的朋友！）
在论坛，你也可能被要求去爬爬论坛的旧文。事实上，有人甚至可能热心地为你提供以前解决此问题的讨论串。但不要依赖这种关照，提问前应该先搜索一下旧文。
通常，用这两句之一回答你的人会给你一份包含你需要内容的手册或者一个网址，而且他们打这些字的时候也正在读着。这些答复意味着回答者认为
- 你需要的信息非常容易获得；
- 你自己去搜索这些信息比灌给你，能让你学到更多。
你不应该因此不爽；依照黑客的标准，他已经表示了对你一定程度的关注，而没有对你的要求视而不见。你应该对他祖母般的慈祥表示感谢。
如果还是搞不懂
如果你看不懂回应，别立刻要求对方解释。像你以前试着自己解决问题时那样（利用手册，FAQ，网络，身边的高手），先试着去搞懂他的回应。如果你真的需要对方解释，记得表现出你已经从中学到了点什么。
比方说，如果我回答你：看来似乎是 zentry 卡住了；你应该先清除它。，然后，这是一个很糟的后续问题回应：zentry 是什么？ 好的问法应该是这样：哦~~~我看过说明了但是只有 -z 和 -p 两个参数中提到了 zentries，而且还都没有清楚的解释如何清除它。你是指这两个中的哪一个吗？还是我看漏了什么？
处理无礼的回应
很多黑客圈子中看似无礼的行为并不是存心冒犯。相反，它是直接了当，一针见血式的交流风格，这种风格更注重解决问题，而不是使人感觉舒服而却模模糊糊。
如果你觉得被冒犯了，试着平静地反应。如果有人真的做了出格的事，邮件列表、新闻群组或论坛中的前辈多半会招呼他。如果这没有发生而你却发火了，那么你发火对象的言语可能在黑客社区中看起来是正常的，而你将被视为有错的一方，这将伤害到你获取信息或帮助的机会。
另一方面，你偶尔真的会碰到无礼和无聊的言行。与上述相反，对真正的冒犯者狠狠地打击，用犀利的语言将其驳得体无完肤都是可以接受的。然而，在行事之前一定要非常非常的有根据。纠正无礼的言论与开始一场毫无意义的口水战仅一线之隔，黑客们自己莽撞地越线的情况并不鲜见。如果你是新手或外人，避开这种莽撞的机会并不高。如果你想得到的是信息而不是消磨时光，这时最好不要把手放在键盘上以免冒险。
（有些人断言很多黑客都有轻度的自闭症或亚斯伯格综合症，缺少用于润滑人类社会正常交往所需的神经。这既可能是真也可能是假的。如果你自己不是黑客，兴许你认为我们脑袋有问题还能帮助你应付我们的古怪行为。只管这么干好了，我们不在乎。我们喜欢我们现在这个样子，并且通常对病患标记都有站得住脚的怀疑）。
Jeff Bigler 的观察总结和这个相关也值得一读 (tact filters)。
在下一节，我们会谈到另一个问题，当你行为不当时所会受到的冒犯。
如何避免扮演失败者
在黑客社区的论坛中有那么几次你可能会搞砸 —— 以本指南所描述到的或类似的方式。而你会在公开场合中被告知你是如何搞砸的，也许攻击的言语中还会带点夹七夹八的颜色。
这种事发生以后，你能做的最糟糕的事莫过于哀嚎你的遭遇、宣称被口头攻击、要求道歉、高声尖叫、憋闷气、威胁诉诸法律、向其雇主报怨、忘了关马桶盖等等。相反地，你该这么做：
熬过去，这很正常。事实上，它是有益健康且合理的。
社区的标准不会自行维持，它们是通过参与者积极而公开地执行来维持的。不要哭嚎所有的批评都应该通过私下的邮件传送，它不是这样运作的。当有人评论你的一个说法有误或者提出不同看法时，坚持声称受到个人攻击也毫无益处，这些都是失败者的态度。
也有其它的黑客论坛，受过高礼节要求的误导，禁止参与者张贴任何对别人帖子挑毛病的消息，并声称如果你不想帮助用户就闭嘴。 结果造成有想法的参与者纷纷离开，这么做只会使它们沦为毫无意义的唠叨与无用的技术论坛。
夸张的讲法是：你要的是“友善”（以上述方式）还是有用？两个里面挑一个。
记着：当黑客说你搞砸了，并且（无论多么刺耳）告诉你别再这样做时，他正在为关心你和他的社区而行动。对他而言，不理你并将你从他的生活中滤掉更简单。如果你无法做到感谢，至少要表现得有点尊严，别大声哀嚎，也别因为自己是个有戏剧性超级敏感的灵魂和自以为有资格的新来者，就指望别人像对待脆弱的洋娃娃那样对你。
有时候，即使你没有搞砸（或者只是在他的想像中你搞砸了），有些人也会无缘无故地攻击你本人。在这种情况下，抱怨倒是真的会把问题搞砸。
这些来找麻烦的人要么是毫无办法但自以为是专家的不中用家伙，要么就是测试你是否真会搞砸的心理专家。其它读者要么不理睬，要么用自己的方式对付他们。这些来找麻烦的人在给他们自己找麻烦，这点你不用操心。
也别让自己卷入口水战，最好不要理睬大多数的口水战 —— 当然，这是在你检验它们只是口水战，并且未指出你有搞砸的地方，同时也没有巧妙地将问题真正的答案藏于其后（这也是有可能的）。
不该问的问题
以下是几个经典蠢问题，以及黑客没回答时心中所想的：
问题：我怎样用 X 做 Y？
问题：我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 档案转换为 TeX 格式吗？
问题：我在安装 Linux（或者 X ）时有问题，你能帮我吗？
问题：我怎么才能破解 root 帐号/窃取 OP 特权/读别人的邮件呢？
问题：我能在哪找到 X 程序或 X 资源？
回答：就在我找到它的地方啊，白痴 —— 搜索引擎的那一头。 Oh my gosh!难道还有人不会用 Google 吗？
问题：我怎样用 X 做 Y？
回答：如果你想解决的是 Y ，提问时别给出可能并不恰当的方法。这种问题说明提问者不但对 X 完全无知，也对 Y 要解决的问题糊涂，还被特定形势禁锢了思维。最好忽略这种人，等他们把问题搞清楚了再说。
问题：如何设定我的 shell 提示？ ?
回答：如果你有足够的智慧提这个问题，你也该有足够的智慧去 RTFM，然后自己去找出来。
问题：我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 档案转换为 TeX 格式吗？
回答：试试看就知道了。如果你试过，你既知道了答案，就不用浪费我的时间了。
问题：我的{程序/设定/SQL 语句}不工作
回答：这不算是问题吧，我对要我问你二十个问题才找得出你真正问题的问题没兴趣 —— 我有更有意思的事要做呢。在看到这类问题的时候，我的反应通常不外如下三种
- 你还有什么要补充的吗？
- 真糟糕，希望你能搞定。
- 这关我屁事？
问题：我的 Windows 电脑有问题，你能帮我吗？
回答：能啊，扔掉微软的垃圾，换个像 Linux 或 BSD 的开源操作系统吧。
注意：如果程序有官方版 Windows 或者与 Windows 有互动（如 Samba），你可以问与 Windows 相关的问题， 只是别对问题是由 Windows 操作系统而不是程序本身造成的回复感到惊讶， 因为 Windows 一般来说实在太烂，这种说法通常都是对的。
问题：我的程序不会动了，我认为系统工具 X 有问题
回答：你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与函数库档案有明显缺陷的人，更有可能的是你完全没有根据。不同凡响的说法需要不同凡响的证据，当你这样声称时，你必须有清楚而详尽的缺陷说明文件作后盾。
问题：我在安装 Linux（或者 X ）时有问题，你能帮我吗？
回答：不能，我只有亲自在你的电脑上动手才能找到毛病。还是去找你当地的 Linux 使用群组者寻求实际的指导吧（你能在这儿找到使用者群组的清单）。
注意：如果安装问题与某 Linux 的发行版有关，在它的邮件列表、论坛或本地使用者群组中提问也许是恰当的。此时，应描述问题的准确细节。在此之前，先用 Linux 和所有被怀疑的硬件作关键词仔细搜索。
问题：我怎么才能破解 root 帐号/窃取 OP 特权/读别人的邮件呢？
回答：想要这样做，说明了你是个卑鄙小人；想找个黑客帮你，说明你是个白痴！
好问题与蠢问题
最后，我将透过举一些例子，来说明怎样聪明的提问；同一个问题的两种问法被放在一起，一种是愚蠢的，另一种才是明智的。
蠢问题：
我可以在哪儿找到关于 Foonly Flurbamatic 的资料？
这种问法无非想得到 STFW 这样的回答。
聪明问题：
我用 Google 搜索过 “Foonly Flurbamatic 2600”，但是没找到有用的结果。谁知道上哪儿去找对这种设备编程的资料？
这个问题已经 STFW 过了，看起来他真的遇到了麻烦。
蠢问题：
我从 foo 项目找来的源码没法编译。它怎么这么烂？
他觉得都是别人的错，这个傲慢自大的提问者。
聪明问题：
foo 项目代码在 Nulix 6.2 版下无法编译通过。我读过了 FAQ，但里面没有提到跟 Nulix 有关的问题。这是我编译过程的记录，我有什么做的不对的地方吗？
提问者已经指明了环境，也读过了 FAQ，还列出了错误，并且他没有把问题的责任推到别人头上，他的问题值得被关注。
蠢问题：
我的主机板有问题了，谁来帮我？
某黑客对这类问题的回答通常是：好的，还要帮你拍拍背和换尿布吗？，然后按下删除键。
聪明问题：
我在 S2464 主机板上试过了 X 、 Y 和 Z ，但没什么作用，我又试了 A 、 B 和 C 。请注意当我尝试 C 时的奇怪现象。显然 florbish 正在 grommicking，但结果出人意料。通常在 Athlon MP 主机板上引起 grommicking 的原因是什么？有谁知道接下来我该做些什么测试才能找出问题？
这个家伙，从另一个角度来看，值得去回答他。他表现出了解决问题的能力，而不是坐等天上掉答案。
在最后一个问题中，注意告诉我答案和给我启示，指出我还应该做什么诊断工作之间微妙而又重要的区别。
事实上，后一个问题源自于 2001 年 8 月在 Linux 内核邮件列表（lkml）上的一个真实的提问。我（Eric）就是那个提出问题的人。我在 Tyan S2464 主板上观察到了这种无法解释的锁定现象，列表成员们提供了解决这一问题的重要信息。
通过我的提问方法，我给了别人可以咀嚼玩味的东西；我设法让人们很容易参与并且被吸引进来。我显示了自己具备和他们同等的能力，并邀请他们与我共同探讨。通过告诉他们我所走过的弯路，以避免他们再浪费时间，我也表明了对他们宝贵时间的尊重。
事后，当我向每个人表示感谢，并且赞赏这次良好的讨论经历的时候， 一个 Linux 内核邮件列表的成员表示，他觉得我的问题得到解决并非由于我是这个列表中的名人，而是因为我用了正确的方式来提问。
黑客从某种角度来说是拥有丰富知识但缺乏人情味的家伙；我相信他是对的，如果我像个乞讨者那样提问，不论我是谁，一定会惹恼某些人或者被他们忽视。他建议我记下这件事，这直接导致了本指南的出现。
如果得不到回答
如果仍得不到回答，请不要以为我们觉得无法帮助你。有时只是看到你问题的人不知道答案罢了。没有回应不代表你被忽视，虽然不可否认这种差别很难区分。
总的来说，简单的重复张贴问题是个很糟的点子。这将被视为无意义的喧闹。有点耐心，知道你问题答案的人可能生活在不同的时区，可能正在睡觉，也有可能你的问题一开始就没有组织好。
你可以通过其他渠道获得帮助，这些渠道通常更适合初学者的需要。
有许多网上的以及本地的使用者群组，由热情的软件爱好者（即使他们可能从没亲自写过任何软件）组成。通常人们组建这样的团体来互相帮助并帮助新手。
另外，你可以向很多商业公司寻求帮助，不论公司大还是小。别为要付费才能获得帮助而感到沮丧！毕竟，假使你的汽车发动机汽缸密封圈爆掉了 —— 完全可能如此 —— 你还得把它送到修车铺，并且为维修付费。就算软件没花费你一分钱，你也不能强求技术支持总是免费的。
对像是 Linux 这种大众化的软件，每个开发者至少会对应到上万名使用者。根本不可能由一个人来处理来自上万名使用者的求助电话。要知道，即使你要为这些协助付费，和你所购买的同类软件相比，你所付出的也是微不足道的（通常封闭源代码软件的技术支持费用比开源软件的要高得多，且内容也没那么丰富）。
如何更好地回答问题
态度和善一点。问题带来的压力常使人显得无礼或愚蠢，其实并不是这样。
对初犯者私下回复。对那些坦诚犯错之人没有必要当众羞辱，一个真正的新手也许连怎么搜索或在哪找常见问题都不知道。
如果你不确定，一定要说出来！一个听起来权威的错误回复比没有还要糟，别因为听起来像个专家很好玩，就给别人乱指路。要谦虚和诚实，给提问者与同行都树个好榜样。
如果帮不了忙，也别妨碍他。不要在实际步骤上开玩笑，那样也许会毁了使用者的设置 —— 有些可怜的呆瓜会把它当成真的指令。
试探性的反问以引出更多的细节。如果你做得好，提问者可以学到点东西 —— 你也可以。试试将蠢问题转变成好问题，别忘了我们都曾是新手。
尽管对那些懒虫抱怨一声 RTFM 是正当的，能指出文件的位置（即使只是建议个 Google 搜索关键词）会更好。
如果你决定回答，就请给出好的答案。当别人正在用错误的工具或方法时别建议笨拙的权宜之计（workaround），应推荐更好的工具，重新界定问题。
正面的回答问题！如果这个提问者已经很深入的研究而且也表明已经试过 X 、 Y 、 Z 、 A 、 B 、 C 但没得到结果，回答 试试看 A 或是 B 或者 试试 X 、 Y 、 Z 、 A 、 B 、 C 并附上一个链接一点用都没有。
帮助你的社区从问题中学习。当回复一个好问题时，问问自己如何修改相关文件或常见问题文件以免再次解答同样的问题？，接着再向文件维护者发一份补丁。
如果你是在研究一番后才做出的回答，展现你的技巧而不是直接端出结果。毕竟授人以鱼不如授人以渔。
相关资源
如果你需要个人电脑、Unix 系统和网络如何运作的基础知识，参阅 Unix 系统和网络基本原理。
当你发布软件或补丁时，试着按软件发布实践操作。
鸣谢
Evelyn Mitchel 贡献了一些愚蠢问题例子并启发了编写如何更好地回答问题这一节， Mikhail Ramendik 贡献了一些特别有价值的建议和改进。