The Wisdom of Asking Questions

How To Ask Questions The Smart Way

The copyright for the English version of this guide belongs to Eric S. Raymond and Rick Moen.

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

Declaration#

Many projects link to this guide on their usage assistance/documentation pages, which is great, and we encourage everyone to do so. However, if you are responsible for managing the project webpage, please prominently state near the hyperlink:

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

We have learned painfully from the lack of the above declaration. Without this statement, we are constantly harassed by some idiots who think that since we published this guide, we have a responsibility to solve all the technical problems in the world.

If you are reading this guide because you need some assistance and leave disappointed because you find that you cannot get direct help from the authors of this guide, then you are one of those idiots we are talking about. Don't ask us questions; we will just ignore you. We are teaching you how to get help from those who really understand the software or hardware problems you are facing, and in 99% of cases, that won't be us. Unless you are sure that one of the authors of this guide happens to be an expert in the area of your problem, please do not disturb us; it will make everyone happier.

Introduction#

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

Not just hackers, but now open-source software is quite popular, and you can often get good answers from other experienced users, which is a good thing; users tend to be more tolerant of the common problems that newcomers face 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.

First, you should understand that hackers love challenging questions or good questions that stimulate our thinking. If we didn't, we wouldn't be the ones you want to ask. If you give us a good question that is worth chewing over, we will be grateful to you. A good question is an incentive, a generous gift. A good question can enhance our understanding and often expose issues we have never realized or thought about before. For hackers, "Good question!" is a sincere and strong compliment.

Nevertheless, hackers have a bad reputation for disdain or arrogance towards simple questions, which sometimes makes us seem hostile to newcomers and the ignorant, but that is not the case.

We do not shy away from admitting our disdain for those who are unwilling to think or who do not do what they should do before asking. Those people are time wasters – they only want to take and never give, consuming our time that could be spent on more interesting questions or more deserving people. We call such people lusers (due to historical reasons, we sometimes spell it as lusers).

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

We (to a large extent) voluntarily take time out of our busy lives to answer questions and are often overwhelmed by inquiries. So we ruthlessly filter out some topics, especially discarding those that seem like they come from losers, in order to use our time more efficiently to answer winners questions.

If you dislike our attitude, our aloofness, or arrogance, try to put yourself in our shoes. We are not asking you to submit to us – in fact, most of us are very willing to communicate with you as equals, as long as you make a small effort to meet basic requirements, we will welcome you into our culture. But helping those who are unwilling to help themselves is inefficient. Ignorance is fine, but pretending to be ignorant is not.

So, you do not need to be technically savvy to attract our attention, but you must demonstrate qualities that show you can guide yourself to become savvy – cleverness, thoughtfulness, good observation, and a willingness to actively participate in solving problems. If you cannot do these things that set you apart, we suggest you spend some money to hire a commercial company for technical support instead of asking hackers for free help.

If you decide to seek our help, of course, you do not want to be seen as a loser, nor do you want to be one. The best way to get quick and effective answers is to ask like a winner – smart, confident, and with a problem-solving mindset, only occasionally needing a little help with specific questions.

(Feel free to suggest improvements to this guide. You can email your suggestions to [email protected] or [email protected]. However, please note that this document is not a universal guide to netiquette, and we generally reject suggestions that do not help in obtaining useful answers in technical forums.)

Before Asking#

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

Try searching the old posts in the forum where you are preparing to ask for answers.
Try searching the web to find answers.
Try reading the manual to find answers.
Try reading the FAQ to find answers.
Try checking or experimenting on your own to find answers.
Ask your knowledgeable friends nearby for answers.
If you are a programmer, try reading the source code to find answers.

When you ask a question, please indicate that you have made the above efforts; this will help establish that you are not a time-wasting freeloader. It would be even better if you could express what you have learned in the process of making those efforts, as we are more willing to answer questions from those who show they can learn from the answers.

Employ certain strategies, such as first using Google to search for various error messages you encounter (search both Google Groups and the web), as this is likely to lead you directly to documents or mailing list threads that can solve your problem. Even if you do not find results, adding a line like I searched Google for the following phrases but did not find anything useful when seeking help in mailing lists or newsgroups is a good idea, even if it only indicates what the search engine could not help with. Doing this (along with the strings you searched) also allows others who encounter similar problems to be directed to your question by the search engine.

Do not rush; do not expect a complex problem to be solved by a few seconds of Google searching. Before seeking help from experts, read the FAQ again, relax, sit comfortably, and take some time to think 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. Do not throw all your questions out just because your first search did not yield answers (or found too many answers).

Prepare your question and think it through carefully, as hasty questions can only yield hasty answers or no answers at all. The more you can demonstrate the effort you put into solving the problem before seeking help, the more likely you are to receive substantial assistance.

Be careful not to ask the wrong question. If your question is based on incorrect assumptions, a typical hacker (J. Random Hacker) will likely think to themselves stupid question... while responding with a meaningless literal explanation, hoping you will learn from the answer (rather than the answer you wanted).

Never assume you are entitled to an answer; you are not; you are not. After all, you have not paid for this service. You will have to earn an answer by asking meaningful, interesting, and thought-provoking questions – questions that have the potential to contribute to the community's experience, rather than just passively seeking knowledge from others.

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

When You Ask#

Use Meaningful and Descriptive Titles#

In mailing lists, newsgroups, or forums, a title of about 50 characters is a good opportunity to catch the attention of seasoned experts. Do not waste this opportunity with vague titles like Help! or Urgent! (let alone something off-putting like Help me!!!!; such titles will be reflexively ignored). Do not expect to impress us with the degree of your suffering; instead, use this space to pose your question in a very simple and concise manner.

A good title example is a Goal -- Difference style description, which many technical support organizations use. In the Goal part, indicate which item or group of items is problematic, and in the Difference part, describe where the behavior is inconsistent with expectations.

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

Smart question: The mouse cursor distorts in X.org 6.8.1 with the MV1005 chipset.

Even smarter question: The mouse cursor distorts in X.org 6.8.1 under the MV1005 chipset environment.

Writing a Goal -- Difference style description helps you organize your detailed thoughts about the problem. What is affected? Is it just the mouse cursor or other graphics as well? Does it only occur in the X version of X.org? Or just in version 6.8.1? Is it specific to a certain brand of graphics chipset? Or just the MV1005 model? A hacker should be able to glance and immediately understand your environment and the problem you are facing.

In short, imagine you are searching an archive discussion thread that only displays titles. Making your title better reflect the problem will allow the next person searching for similar issues to pay attention to this thread without having to ask the same question again.

If you want to ask a question in a reply, remember to modify the content title to indicate that you are asking a question; a title that looks like Re: Test or Re: New Bug is unlikely to attract enough attention. Additionally, appropriately quoting and trimming previous content without affecting coherence can provide clues for new readers.

For discussion threads, do not click reply directly to start a whole new thread; this will limit your audience. Some email reading programs, like mutt, allow users to sort by discussion thread and hide messages by folding threads, so those who do this will never see your message.

Simply changing the title is not enough. Mutt and some other email reading programs also check other information beyond the email title to assign it to a discussion thread. So it is better to send a completely new email.

In web forums, good questioning practices are slightly different because threads are tightly coupled with specific information and often the content cannot be seen outside the thread, so asking questions by replying rather than changing the title is acceptable. Not all forums allow separate titles to appear in replies, and doing so will likely result in no one reading it. However, asking questions by replying is inherently ambiguous because they will only be read by those currently viewing that title. So unless you only want to ask questions among the currently active participants in that thread, it is better to start anew.

Make It Easy to Reply#

Ending your question with Please send your reply to... will likely result in no response. If you think it is a hassle to spend a few seconds setting a reply address in your email client, we also find it a hassle to spend a few seconds thinking about your question. If your email program does not support this, get a better one; if it is the operating system that does not support such email programs, get a better one.

In forums, asking for replies via email is very rude unless you believe the information in the reply might be sensitive (and someone might only want to let you know the answer for some unknown reason). If you just want to be notified via email when someone replies to the thread, you can ask the web forum to send you notifications. Almost all forums support features like Track this discussion or Send email alerts when there are replies.

Use Clear, Correct, Precise, and Grammatically Correct Sentences#

From experience, we find that careless questioners are often careless in writing code and thinking (I can guarantee that). Answering careless people's questions is not worth it; we would rather spend our time elsewhere.

Correct spelling, punctuation, and capitalization are very important. Generally, if you find it a hassle to do so and do not care about these things, we also find it a hassle and do not care about your question. Spend a little extra effort to consider your wording; it does not need to be too stiff or formal – in fact, hacker culture values the accurate use of informal, colloquial, and humorous language. But it must be accurate and show signs that you are thinking and paying attention to the problem.

Correctly spell, punctuate, and capitalize; do not confuse its with it's, loose with lose, or discrete with discreet. Do not use all caps, as this is considered shouting (all lowercase is not much better, as it is hard to read. Alan Cox might get away with it, but you cannot).

In simpler terms, if you write like a semi-literate person [Note: "小白" refers to a beginner], you will likely be ignored. Also, do not use instant messaging abbreviations or text speak, such as simplifying 的 to ㄉ; this will make you look like a beginner trying to save a few keystrokes. Worse, if you write like a child, you are definitely asking for trouble; you can be sure no one will pay attention to you (or at most, you will receive a lot of criticism and ridicule).

If you are asking questions in a non-native language forum, you can make some spelling and grammatical mistakes, but you must not be careless in your thinking (yes, we can usually tell the difference). Also, unless you know the responder uses a different language, please write in English. Busy hackers will generally delete messages written in languages they cannot understand. English is the common language on the internet, and writing in English minimizes the chances of your question being deleted before it is even read.

If English is your second language, it is good to inform potential responders that you may have language difficulties:
[Note: The following is provided for use]

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

English is not my native language; please excuse 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 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 technical terms, but I find slang or special usages difficult to understand.

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 have written my question in a certain language and English; if you respond in only one language, I will be happy to translate it into the other.

Use Easily Readable and Standard File Formats to Send Questions#

If you make your question difficult to read, it will likely be ignored; people prefer to read understandable questions, so:

Use plain text instead of HTML (turn off HTML easily)
Using MIME attachments is usually acceptable, provided they contain real content (e.g., accompanying source code or patches), rather than just the email program's generated template (e.g., just a copy of the letter's content).
Do not send a text that is just a single line but broken multiple times (this makes it very difficult to reply to part of the content). Imagine your reader is reading the email on an 80-character-wide terminal; it is best to set your line breaks to less than 80 characters.
However, also do not use any fixed line break material (e.g., logs or session records). The files should be left intact so that the responder can be confident they see the same thing you see.
In English forums, do not send messages using Quoted-Printable MIME encoding. This encoding may be necessary for posting non-ASCII languages, but many email programs do not support this encoding. When it breaks, the =20 symbols scattered throughout the text are both unsightly and distracting, and may even distort 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 like you would if someone dumped steaming pig manure on your doorstep. Even if they could handle it, they would hate doing so.
If you are sending emails from a Windows computer, turn off Microsoft's stupid smart quotes feature (from [Options] > [Spelling] > [AutoCorrect Options], uncheck the smart quotes checkbox) to avoid spreading garbage characters throughout your email.
In forums, do not abuse emoticons and HTML features (when provided). One or two emoticons are usually fine, but fancy colored text tends to make people think you are incompetent. Overusing emoticons, colors, and fonts will make you look like a silly little girl. This is usually not a good idea unless you are more interested in sex than useful replies.

If you use a graphical email program (like Microsoft Outlook or similar), be aware that their default settings may not meet these requirements. Most of these programs have a menu-based View Source command to check messages in your sent folder to ensure you are sending a clean plain text file without extraneous impurities.

Describe the Problem Accurately and Meaningfully#

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), providing the vendor's distribution 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 identify the problem before asking.
Describe any recent hardware or software changes that may be relevant.
Provide a method to reproduce the problem in a controlled environment as much as possible.

Try to anticipate how a hacker might question you and preemptively provide answers when they ask.

Among the above points, when reporting a problem you believe may be in the code, providing a hacker with an environment to reproduce your problem is especially important. When you do this, your chances of receiving effective answers and speed will greatly increase.

Simon Tatham has written an excellent article titled How to Report Bugs Effectively. I strongly recommend you read it as well.

Be Concise but Informative#

You need to provide precise and meaningful information. This does not mean you should simply transcribe a pile of error codes or data into your question. If you have a large and complex test case that reproduces the program crash, try to trim it down as much as possible.

Doing this serves at least three purposes:
First, it shows that you have made an effort to simplify the problem, which can increase your chances of getting a response;
Second, simplifying the problem makes you more likely to receive useful answers;
Third, in the process of refining your bug report, you may very well find the solution or a workaround yourself.

You Can Be Humble, But Do Your Homework First#

Some people understand that they should not ask rudely or arrogantly and demand answers, but they choose the other extreme – being overly humble: I know I'm just a pathetic newbie, a luser, but... This is both annoying and unhelpful, especially when accompanied by vague descriptions of the actual problem.

Do not waste your time or mine with primitive primate tricks. Instead, describe the background conditions and your problem situation as clearly as possible. This is better than being overly humble.

Sometimes web forums have sections specifically for beginners to ask questions; if you really think you have a beginner's question, go there, but do not be overly humble.

Describe the Symptoms of the Problem, Not Your Guesses#

Telling hackers what you think caused the problem is not helpful. (If your reasoning were that effective, would you need to ask anyone for help?), so be sure to tell them the symptoms of the problem as they are, not your explanations and theories; let the hackers speculate and diagnose. If you think it is important to state your guesses, clearly indicate that these are just your guesses and describe why they do not work.

Stupid question

I keep getting SIG11 errors when compiling the kernel; I suspect a wire is shorting on the motherboard. How should I check this?

Smart question

My assembled computer has an FIC-PA2007 motherboard with an AMD K6/233 CPU (VIA Apollo VP2 chipset), 256MB Corsair PC133 SDRAM memory, and I frequently get SIG11 errors when compiling the kernel after 20 minutes of booting, but never in the first 20 minutes. Restarting does not help, but shutting down overnight allows it to work for another 20 minutes. All memory has been replaced with no effect. The standard compilation log for the relevant parts is as follows...

Since this seems to make it difficult for many people to cooperate, here is a phrase to remind you: All diagnostic experts come from Missouri. The official motto of the U.S. State Department is: Show me (from a speech by Congressman Willard D. Vandiver in 1899: I come from a state that produces corn, cotton, bull thistles, and Democrats; eloquence neither convinces nor satisfies me. I come from Missouri; you have to show me.) For diagnosticians, this is not a doubt but a genuine and useful need to see something that is as close to the original evidence they see as possible, rather than your guesses and inductive conclusions. So, show us generously!

List the Symptoms of the Problem Chronologically#

The series of actions leading up to the problem often provides the most helpful clues for identifying the issue. Therefore, your description should include your steps and the machine and software's responses until the problem occurs. In command-line processing, providing a log of actions (such as generated by running a script tool) and quoting several relevant lines (e.g., 20 lines) will be very helpful.

If the crashed program has diagnostic options (like the -v verbose switch), try to choose those options that add debugging information to the log. Remember, more does not equal better. Try to select an appropriate debugging level to provide useful information rather than drowning the reader in garbage.

If your description is lengthy (more than four paragraphs), it helps to summarize the problem at the beginning and then detail it chronologically. This way, hackers will know what to pay attention to when reading your log.

Describe the Goal, Not the Process#

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

People who frequently seek technical help often have a higher-level goal in mind, and they get stuck on a specific path they think will lead them to that goal, but they do not realize that the path itself is problematic. As a result, it takes a lot of effort to sort it out.

Stupid question

How can I get the hexadecimal RGB value from the color picker of a certain drawing program?

Smart question

I am trying to replace the color codes of an image with my chosen codes. The only method I know is to edit each color block, but I cannot get the hexadecimal RGB value from the color picker of a certain drawing program.

The second way of asking is smarter; you might receive a reply like Consider using another more suitable tool.

Clearly Express Your Question and Needs#

Vague questions are nearly endless time sinks. The people most likely to give you useful answers are often the busiest (they are busy because they are doing most of the work themselves). Such people tend to be quite averse to endless time sinks, so they also tend to dislike vague questions.

If you clearly state what you need the responder to do (such as provide guidance, send a piece of code, check your patch, or something else), you are most likely to receive useful answers. This sets a time and energy limit, allowing the responder to focus on helping you. This is great.

To understand the world of experts, think of professional skills as abundant resources, while the time to reply is a scarce resource. The less time you ask them to devote, the more likely you are to get answers from genuinely professional and busy experts.

So, define your question in a way that minimizes the time experts spend identifying your problem and answering it; this skill is very helpful in getting you useful answers – but this skill is usually different from simplifying the problem. Therefore, asking I want to better understand X; could you point me to a good explanation? is usually better than asking Can you explain X to me? If your code does not work, it is usually wiser to ask someone to look at where the problem is rather than asking them to fix it for you.

When Asking About Code#

Do not ask others to debug your problematic code without giving them a hint about where to start. Posting hundreds of lines of code and saying It doesn't work will likely get you completely ignored. Posting a few dozen lines of code and saying After line seven, I expect it to display <x>, but it actually shows <y> is more likely to get a response.

The most effective way to describe a programming problem is to provide the smallest possible bug demonstration test case (bug-demonstrating test case). What is the smallest test case? It is a microcosm of the problem; a small piece of code that just demonstrates the abnormal behavior of the program without including other distracting content. How to create the smallest test case? If you know which line or segment of code causes the abnormal behavior, copy it and add enough code to reproduce the situation (for example, enough to compile/interpreter/process this code). If you cannot reduce the problem to a specific block, copy a piece of code and remove parts that do not affect the problematic behavior. In short, the smaller the test case, the better (see the section Be Concise but Informative).

In general, getting a reasonably small test case is not easy, but it is a good habit to always try to do so first. This approach can help you understand how to solve the problem yourself – and even if your attempt is unsuccessful, hackers will see that you have made an effort in trying to get an answer, which can make them more willing to cooperate with you.

If you just want someone to review your code, state that at the beginning of your message, and be sure to mention which parts you think need special attention and why.

Don't Post Homework Questions#

Hackers are very good at spotting which questions are homework questions; most of us have solved such problems ourselves. These questions need to be solved by you; you will learn from it. You can ask for hints, but do not ask for a complete solution.

If you suspect you have encountered a homework question but still cannot solve it, try asking in user groups, forums, or (as a last resort) in the project's user mailing list or forum. Although hackers will see through it, some experienced users may still provide you with hints.

Eliminate Meaningless Question Phrases#

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

First: If your description of the problem is not very good, asking like this is redundant.

Second: Because asking like this is redundant, hackers will find you annoying – and will often respond with logically correct but meaningless answers to express their disdain, such as: Yes, someone can help you or No, there is no answer.

In general, avoid yes/no, true/false, or have/not have type questions unless you want to receive yes/no type answers.

Politeness Goes a Long Way and Can Sometimes Help#

Be polite, use please and thank you for your attention or thank you for your care. Let everyone know you appreciate their time spent helping you for free.

To be honest, this point is not more important than being clear, correct, precise, and grammatically correct, nor can it replace it. Hackers generally prefer to read a somewhat brusque but technically clear bug report rather than a polite but vague one. (If this confuses you, remember we evaluate the value of a problem based on what it can teach us.)

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

(We have noticed that since the publication of this guide, the only serious defect feedback received from seasoned hackers has been regarding the preemptive thanks. Some hackers feel that Thanks in advance implies that no further thanks are necessary afterward. Our suggestion is to either say Thanks in advance and then thank the responders afterward, or express gratitude in another way, such as using Thank you for your attention or Thank you for your care.)

After the Problem is Resolved, Add a Brief Follow-Up#

After the problem is resolved, send a note to everyone who helped you to let them know how the problem was solved, and thank them once again. If the problem generated widespread interest in a newsgroup or mailing list, it is appropriate to post a note there.

The ideal way is to reply to the original topic with this message and include an obvious marker in the title like Resolved or Solved or other equivalent meanings. In a busy mailing list, a potential responder seeing the discussion thread Problem X and Problem X - Resolved will understand not to waste time (unless they personally find Problem 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 Hi, it turned out to be a network cable issue! Thanks everyone – Bill is better than saying nothing at all. In fact, unless the conclusion is genuinely technical, a short and sweet summary is better than a lengthy discourse. Describe how the problem was solved, but there is no need to recount the entire process of solving the problem.

For deeper issues, posting a summary of the debugging log is helpful. Describe the final state of the problem, explain what resolved it, and only then point out the blind spots that could have been avoided. The part about avoiding blind spots should come after the correct solution and other summary materials, rather than turning this information into a detective novel. Listing the names of those who helped you will help you make more friends.

In addition to being polite and substantive, this type of follow-up also helps others searching the mailing list/newsgroup/forum find the actual solution to your problem, allowing them to benefit as well.

At the very least, this follow-up helps every participant feel a sense of satisfaction from the resolution of the problem. If you are not a technical expert or hacker, trust us, this feeling is very important to those masters or experts you sought help from. An unresolved problem can be disheartening; hackers crave to see problems resolved. Good people get good rewards; satisfy their desires, and you will reap the benefits the next time you ask a question.

Think about how to prevent others from encountering similar problems in the future, and ask yourself if writing a document or adding a FAQ would be helpful. If so, send them to the maintainers.

In hacker culture, this kind of good follow-up is actually more important than traditional etiquette and is a way to earn a reputation through treating others well, which is a very valuable asset.

How to Interpret Answers#

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

There is an ancient and sacred tradition: if you receive a response of RTFM (Read The Fucking Manual), the responder believes you should go read the fucking manual. Of course, they are basically right; you should go read it.

RTFM has a younger relative. If you receive a response of STFW (Search The Fucking Web), the responder believes you should have searched the fucking web. That person is likely also right; go search. (A more gentle way to say this is Google is your friend!)

In forums, you may also be asked to browse the old posts. In fact, someone may even kindly provide you with a previous discussion thread that solved this problem. But do not rely on this kindness; you should search the old posts before asking.

Typically, the person responding with one of these two phrases will provide you with a manual or a URL containing the information you need, and they are reading while typing those words. These responses mean the responder believes

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

You should not be upset by this; by hacker standards, they have shown a certain degree of concern for you and have not ignored your request. You should thank them for their grandmotherly kindness.

If You Still Don’t Understand#

If you do not understand the response, do not immediately ask the person to explain. Like you did when you previously tried to solve the problem (using manuals, FAQs, the web, knowledgeable friends), first try to understand their response. If you really need the person to explain, remember to show that you have learned something from it.

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

Questions You Should Not Ask#

Here are some classic stupid questions, along with what hackers think when they do not answer:

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

Question: How do I do Y with X?

Question: How do I set my shell prompt?

Question: Can I convert AcmeCorp files to TeX format using Bass-o-matic?

Question: My program/settings/SQL statement does not work.

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

Question: My program has stopped working; I think system tool X is the problem.

Question: I have a problem installing Linux (or X); can you help me?

Question: How can I hack the root account/steal OP privileges/read someone else's email?

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

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

Question: How do I do Y with X?

Answer: If you want to solve Y, do not suggest a method that may not be appropriate when asking. This question indicates that the asker is not only completely ignorant of X but also confused about the problem Y aims to solve, and is mentally trapped by a specific situation. It is best to ignore such people until they figure out their problem.

Question: How do I set my shell prompt?

Answer: If you have enough sense to ask this question, you should also have enough sense to RTFM and find out for yourself.

Question: Can I convert AcmeCorp files to TeX format using Bass-o-matic?

Answer: Try it and see. If you have tried, you already know the answer, so do not waste my time.

Question: My program/settings/SQL statement does not work.

Answer: That is not really a question; I am not interested in asking you twenty questions to find out what your real problem is – I have more interesting things to do. When I see such questions, my reactions usually fall into one of three categories:

Do you have anything to add?
Too bad; I hope you can figure it out.
What does this have to do with me?

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

Answer: Sure, throw away the useless garbage and switch to an open-source operating system like Linux or BSD.

Note: If the program has an official version for Windows or interacts with Windows (like Samba), you can ask questions related to Windows, just do not be surprised if the response indicates that the problem is caused by the Windows operating system rather than the program itself, as Windows is generally so bad that this statement is usually true.

Question: My program has stopped working; I think system tool X is the problem.

Answer: You could very well be the first person to notice a significant flaw in system calls and library files that have been repeatedly used by thousands of users; more likely, you have no basis for your claim. Extraordinary claims require extraordinary evidence; when you make such a claim, you must have a clear and detailed defect report to back it up.

Question: I have a problem installing Linux (or X); can you help me?

Answer: No, I would need to physically work on your computer to find the problem. Go seek actual guidance from your local Linux user group (you can find a list of user groups here).

Note: If the installation issue is related to a specific Linux distribution, it may be appropriate to ask in its mailing list, forum, or local user group. At this point, you should describe the exact details of the problem. Before that, search carefully using Linux and all suspected hardware as keywords.

Question: How can I hack the root account/steal OP privileges/read someone else's email?

Answer: Wanting to do that shows you are a despicable person; wanting to find a hacker to help you shows you are an idiot!

Good Questions vs. Stupid Questions#

Finally, I will illustrate how to ask smart questions by presenting examples of the same question asked in two ways, one stupid and one wise.

Stupid question:

Where can I find information about the Foonly Flurbamatic?

This way of asking is just asking for a response like STFW.

Smart question:

I searched Google for "Foonly Flurbamatic 2600", but did not find useful results. Does anyone know where to find programming information for this device?

This question has already STFW, and it seems they are genuinely having trouble.

Stupid question

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

This arrogant questioner thinks it is all someone else's fault.

Smart question

The foo project code does not compile under Nulix 6.2. I have read the FAQ, but it does not mention any issues related to Nulix. Here is the log of my compilation process; is there something I did wrong?

The questioner has indicated the environment, read the FAQ, listed the errors, and has not shifted the blame for the problem onto others; their question is worth addressing.

Stupid question

My motherboard has a problem; who can help me?

A hacker's typical response to such questions is: Okay, do you want me to pat your back and change your diaper too? and then hit delete.

Smart question

I have tried X, Y, and Z on the S2464 motherboard, but nothing worked; I also tried A, B, and C. Note the strange phenomenon when I tried C. Clearly, florbish is grommicking, but the result is unexpected. What are the usual causes of grommicking on Athlon MP motherboards? Does anyone know what tests I should do next to identify the problem?

This person, from another perspective, is worth answering. They demonstrate the ability to solve problems rather than just waiting for answers to fall from the sky.

In the last question, note the subtle yet important distinction between Tell me the answer and Give me a hint, point me to what further diagnostic work I should do.

In fact, the latter question originated from a real inquiry in the Linux kernel mailing list (lkml) in August 2001. I (Eric) was the one who asked the question. I observed this inexplicable locking phenomenon on the Tyan S2464 motherboard, and members of the list provided crucial information to resolve this issue.

By the way I asked my question, I gave others something to chew on; I managed to make it easy for people to engage and be drawn in. I showed that I had the same ability as them and invited them to explore with me. By telling them the paths I had taken to avoid wasting their time, I also demonstrated respect for their valuable time.

Afterward, when I thanked everyone and appreciated the good discussion experience, a member of the Linux kernel mailing list remarked that he felt my problem was resolved not because I was a celebrity on the list, but because I asked the right way.

Hackers, in a sense, are knowledgeable but lack warmth; I believe he was right. If I had asked like a beggar, no matter who I was, I would have annoyed some people or been ignored. He suggested I keep this in mind, which directly led to the creation of this guide.

How to Better Answer Questions#

Be Kind in Attitude. The pressure that questions bring often makes people seem rude or foolish, but that is not the case.

Reply Privately to First-Time Offenders. There is no need to publicly humiliate those who honestly make mistakes; a true newbie may not even know how to search or where to find FAQs.

If You Are Unsure, Be Sure to Say So! An authoritative-sounding incorrect response is worse than none at all; do not give others misleading directions just because it sounds fun to sound like an expert. Be humble and honest, setting a good example for both the questioner and your peers.

If You Cannot Help, Do Not Hinder Them. Do not joke about actual steps; that may ruin the user's setup – some poor fool may take it as a real command.

Ask Probing Questions to Draw Out More Details. If you do well, the questioner can learn something – and you can too. Try to turn stupid questions into good questions; remember we were all newbies once.

While it is legitimate to complain to lazy people with RTFM, it is better to point out where the document is (even if it is just suggesting Google search keywords).

If You Decide to Answer, Provide a Good Answer. Do not suggest clumsy workarounds when others are using the wrong tools or methods; recommend better tools and redefine the problem.

Respond Positively to Questions! If the questioner has already done in-depth research and indicated they have tried X, Y, Z, A, B, C but have not succeeded, answering with Try A or B or Try X, Y, Z, A, B, C and including a link is of no use.

Help Your Community Learn from Problems. When responding to a good question, ask yourself, How can I modify the relevant documents or FAQs to avoid answering the same question again? Then send a patch to the document maintainers.

If you are answering after doing some research, show your skills rather than just handing over the results. After all, Teaching someone to fish is better than giving them a fish.

If you need basic knowledge of how personal computers, Unix systems, and networks work, refer to Unix and Internet Fundamentals HOWTO.

When you publish software or patches, try to follow Software Release Practices.

Acknowledgments#

Evelyn Mitchel contributed some examples of stupid questions and inspired the writing of the section How to Better Answer Questions, while Mikhail Ramendik provided some particularly valuable suggestions and improvements.