The Wisdom of Asking Questions (Chinese Version)

The Wisdom of Asking Questions#

Eric Steven Raymond#

Thyrsus Enterprises

Rick Moen#

Revision History#

Revision 3.9    April 23, 2013    esr
Fixed links
Revision 3.8    June 19, 2012    esr
Fixed links
Revision 3.7    December 6, 2010    esr
Helpful suggestions for non-native English speakers
Revision 3.7    November 2, 2010    esr
Several translations went missing
Revision 3.6    March 19, 2008    esr
Minor updates and new links
Revision 3.5    January 2, 2008    esr
Corrections and some translation links
Revision 3.4    March 24, 2007    esr
New section: "Questions About Code"
Revision 3.3    September 29, 2006    esr
Added a good suggestion from Kai Niggemann
Revision 3.2    January 10, 2006    esr
Included content written by Rick Moen
Revision 3.1    October 28, 2004    esr
Document "Google is your friend!"
Revision 3.0    February 2, 2004    esr
Major additions on etiquette for web forums

Original: How To Ask Questions The Smart Way #

Translation: Wang Gang
Date: October 26, 2013
Content

Table of Contents#

Disclaimer
Introduction
Before Asking Questions
When Asking Questions
How to Interpret Answers
Don't React Like a Loser
Taboos in Asking Questions
Good Questions vs. Bad Questions
If You Don't Get an Answer
How to Answer Better
Related Resources
Acknowledgments

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

Disclaimer#

Many project websites link to this article in their "How to Get Help" sections, which is fine and exactly what we want. But if you are the webmaster of the project that generated this link, please prominently note near the link: We do not provide service support for this project!

We have suffered the pain of not having this note, and we are constantly pestered by some idiots who think that since we published this article, we have a responsibility to solve all the technical problems in the world.

If you are reading this article because you need help and leave with the impression that you can get help directly from the author, then you have unfortunately become one of the idiots we are talking about. Don't ask us questions; we won't respond. We are just teaching you how to get help from those who really understand your hardware and software issues, but 99.9% of the time we won't be those people. Unless you are very sure that the author of this article is an expert in the problem you are facing, please do not disturb us; it will make everyone happier.

Introduction#

In the world of hackers, the answers to your technical questions largely depend on how you ask them and the difficulty of solving the problem. This article will teach you how to ask questions in a way that is more likely to get you a satisfactory answer.

The use of open-source software is widespread, and you can often get answers from other, more experienced users rather than hackers. This is a good thing, as they tend to be more tolerant of the common faults of beginners. However, treating these experienced users as you would hackers, using the methods we recommend, is usually the most effective way to get answers to your questions.

The first thing to understand is that hackers enjoy challenging and thought-provoking questions. If it weren't for this, we wouldn't be writing this article. If you can ask an interesting question for us to chew on, we will appreciate it. Good questions are a form of motivation and a gift, helping us develop our understanding and revealing issues we may not have noticed or thought about. Among hackers, "Good question!" is a very warm and sincere compliment.

Additionally, hackers have a reputation for being hostile or arrogant towards simple questions. Sometimes we seem to have a reflexive rudeness towards beginners and foolish people, but that's not really the case.

We are simply unapologetically hostile towards those who ask questions without thinking or doing their homework. Such people are like a bottomless pit of time—they only know how to take and are unwilling to give, wasting time that could be spent on other, more interesting questions or more deserving people. We call such people "losers" (historically, we sometimes spell "loser" as "lusers").

We recognize that many people just want to use the software we write and have no interest in learning the technical details. For most people, computers are just tools, means to an end. They have their own lives and more important things to do; we acknowledge this and never expect everyone to be interested in the technical issues that fascinate us. However, our style of answering questions is tailored to those who are genuinely interested and willing to actively engage in solving problems, and that will not change. If that changes, we will no longer be as sharp in what we do best.

Most of us are volunteers, taking time from our busy lives to answer questions, and sometimes we feel overwhelmed. Therefore, we will ruthlessly filter out questions, especially those that seem to be from losers, in order to more effectively allocate our time to those who are winners.

If you find this attitude offensive, condescending, or arrogant, please check your assumptions; we are not asking you to submit—in fact, if you make the effort you should, most of us will be very happy to engage with you as equals and welcome you into our culture. Trying to help those who are unwilling to help themselves is simply inefficient for us. It's okay not to understand, but it's not okay to act foolishly.

So, you don't need to be technically savvy to attract our attention, but you must demonstrate that you can guide yourself—be alert, thoughtful, observant, and eager to participate in solving the problem. If you can't do these things that set you apart, we suggest you pay someone else for commercial support rather than asking hackers for free help.

If you decide to seek our help, you won't want to be a loser, and you don't want to be seen as one. The best way to get a quick and effective answer is to make the questioner look like a smart, confident, and thoughtful person, and suggest that you just happen to need help on a particular issue.

(Feel free to correct this article; you can send suggestions to esr@thyrsus.com or respond-auto@linuxmafia.com. Please note that this article does not intend to be a general guide to netiquette; I generally reject suggestions that are not particularly related to eliciting useful answers in technical forums.)

Before Asking Questions#

Before asking technical questions via email, newsgroups, or forums, do the following:

Try to search for answers in the historical documents of the forum you are preparing to ask in.
Try searching the internet for answers.
Try reading the manual for answers.
Try reading the "Frequently Asked Questions" (FAQ) for answers.
Try checking or experimenting on your own for answers.
Try consulting knowledgeable friends for answers.
If you are a programmer, try reading the source code for answers.

When you ask, please indicate that you have done the above, as this will help establish the impression that you are not a parasite wasting others' time. It’s best to also state what you learned from your efforts; we like to answer those who show they can learn from the answers.

Employ certain strategies, such as using Google to search for various error messages you encounter (search both Google Groups and web pages), as this is likely to lead you directly to documentation or mailing list clues that solve the problem. Even if you find nothing, it’s good to mention in your request for help in a mailing list or newsgroup, "I searched Google for the following phrases but found nothing useful," as it at least indicates what the search engine could not help with. Relating search keywords to your question and possible solutions also helps guide others with similar issues.

Don't rush; don't expect a complex problem to be solved with a few seconds of Google searching. Read the FAQ. Before asking an expert, take a step back, relax, and 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. Don't throw all your questions out at once just because your first search yielded no results (or too many).

Think carefully and prepare your question. Asking hastily will only get you hasty answers, or none at all. The more you show that you have thought and made an effort to solve your own problem before asking, the more likely you are to receive genuine help.

Be careful not to ask the wrong question. If your question is based on incorrect assumptions, a hacker will likely think, "Stupid question..." and reply with a wrong answer, hoping to teach you a lesson rather than actually answering your "question."

Never assume you are entitled to an answer. You are not entitled to it; after all, you haven't paid for the service. If you can ask a substantive, interesting, and thought-provoking question—one that undoubtedly contributes experience to the community rather than just passively demanding knowledge from others—you will "earn" an answer.

On the other hand, indicating that you are capable and willing to participate in solving the problem is a great start. "Can someone point me in the right direction?" "What am I missing?" "Which website should I check?" is usually more likely to get a response than "Please give me a complete step-by-step solution," as you indicate that you are willing to do the rest of the work if someone can just point you in the right direction.

When Asking Questions#

Carefully Choose Forums#

Be mindful of where you ask. If you do the following, you will likely be dismissed or seen as a "loser":

Posting questions unrelated to the forum's topic.
Posting superficial questions in forums aimed at advanced technical issues, or vice versa.
Posting in too many different newsgroups at once.
Sending private emails to people who are neither acquaintances nor obligated to solve your problem.

To protect communication channels from being overwhelmed by irrelevant content, hackers will remove questions that are not in the right place; you don't want that to happen to you.

Therefore, the first step is to find the right forum. Google and other search engines are still your friends; you can use them to search for the most relevant project websites related to the hardware or software issues you are encountering. They usually have links to the project's FAQ, mailing list, and documentation. If your efforts (including reading the FAQ) yield no results, those mailing lists are the last place to seek help. The project’s website may also have a process or link for reporting bugs; if so, check it out.

Sending emails to strangers or forums is often risky. For example, don't assume that the author of a content-rich webpage wants to act as your free consultant, and don't be overly optimistic about whether your question will be welcomed—if you are unsure, send it elsewhere or don't send it at all.

When choosing forums, newsgroups, or mailing lists, don't trust the names too much; first, check the FAQ or charter to clarify whether your question is on-topic. Before posting, skim through existing posts to get a feel for how things are done there. In fact, searching for keywords related to your question in the historical documents of the newsgroup or mailing list before posting is an excellent idea; you might just find the answer. Even if you don't, it can help you formulate a better question.

Don't "spray and pray" all help channels at once; this is like shouting and will be off-putting. Approach gently, one at a time.

Understand the subject! One of the most typical mistakes is to ask questions about Unix or Windows APIs in a forum dedicated to cross-platform portable languages, libraries, or tools. If you don't understand why this is a big mistake, it's best not to ask anything until you get the concepts straight.

Generally, asking questions in carefully chosen public forums is more likely to yield useful answers than asking the same question in private forums. There are several reasons for this: one is the number of potential responders, and the other is the number of participants in the forum; hackers are more willing to answer questions that inspire the majority.

Understandably, seasoned hackers and authors of popular software are overwhelmed with inappropriate messages. Like the last straw that breaks the camel's back, your addition may push things to the extreme—several times, authors of popular software have withdrawn support for their software due to the unbearable flood of spam in their private inboxes.

Forums and IRC for Beginners Usually Respond the Fastest#

Local user groups or the Linux distribution you are using may be promoting forums or IRC channels for beginners to get help (in some non-English-speaking countries, beginner forums may still be mailing lists); these are good places to start asking questions, especially when you feel the issues you are encountering may be relatively simple or common. Promoted IRC channels are open invitations to ask questions and usually provide real-time responses.

In fact, if the problematic program comes from a distribution (which is common), it's best to ask in that distribution's forum or mailing list first, then move on to the project's own forum or mailing list (otherwise) the project's hackers may simply reply, "Use our code."

Before posting in any forum, check if there is a search function. If there is, try searching for a few keywords related to your question; you may find help. If you have already done a thorough web search (which you should have), search the forum again; the search engine may not have indexed all the content of that forum yet.

There is a growing trend for projects to provide user support through forums or IRC channels, while email communication is more reserved for project developers. So seek help related to the project in forums or IRC first.

Step Two, Use the Project's Mailing List#

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

Questions directed to individual developers (if) good enough will also benefit the entire project group. Conversely, if you think your question is too stupid for the entire project group, that does not justify bothering individual developers.
Asking the list can distribute the burden on developers; individual developers (especially project leaders) may be too busy to answer your question.
Most mailing lists are archived, and those archives will be indexed by search engines; if you ask the list and get an answer, others can find your question and answer through web searches in the future, eliminating the need to ask again.
If certain questions are frequently asked, developers can use this information to improve documentation or the software itself to make it clearer. If you only ask privately, no one can see the complete picture of the most common questions.

If a project has both "user" and "developer" (or "hacker") mailing lists or forums, and you are not tinkering with the code, ask the "user" list or forum. Don't assume you will be welcomed in the developer list; those people are likely to be overwhelmed by your noise.

However, if you are sure your question is not typical and there have been no replies in the "user" list or forum for several days, you can try the "developer" list or forum. It is advisable to observe for a few days before posting, at least to see the recently saved posts to understand how things are done there (in fact, this is a good idea for participating in any private or semi-private lists).

If you cannot find a mailing list for a project and can only find the maintainer's address, feel free to email them. Even in this case, don't assume (the project) mailing list does not exist. In your email, state that you have tried but could not find a suitable mailing list, and mention that you do not mind if your email is forwarded to others (many people believe that even if there is no secret, private emails should not be made public. By allowing your email to be forwarded, you give the relevant person the option to handle your email).

Use Meaningful and Clear Subjects#

In mailing lists, newsgroups, or forums, the subject is your golden opportunity to attract the attention of qualified experts in fifty words or less; don't waste it with something like "Please help me" (let alone in all caps "PLEASE HELP ME!!!!"; such messages will be reflexively deleted). Don't try to impress us with the depth of your pain; instead, use that space to provide a super concise description of your question.

A good practice for subjects is the "Object—Deviation" format, which many technical support organizations use. In the "Object" part, specify which item or group of items is having a problem, and in the "Deviation" part, describe how it deviates from expected behavior.

Stupid:

Help! My laptop's video isn't working!

Smart:

X.org 6.8.1 distorts mouse cursor on a certain MV1005 chipset

Smarter:

Mouse cursor distorted on X.org 6.8.1 with a certain MV1005 chipset

The process of writing an "Object—Deviation" style description helps you organize your detailed thinking about the problem. What is affected? Is it just the mouse cursor or other graphics as well? Does it only occur in X.org? Or only in version 6.8.1? Is it specific to a certain chipset? Or just the MV1005 model? A hacker should be able to glance and immediately understand what your problem is and what your issue is.

More generally, imagine looking for something in a document index that only displays subjects. Making your subject better reflect the problem can help the next person searching for similar issues find clues directly in the document without needing to post again.

If you want to ask a question in a reply, be sure to change the subject to indicate you are asking a question; a subject like Re: Test or Re: New Bug is unlikely to attract enough attention. Also, try to delete quoted content in the reply that is not closely related to the new subject.

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

Just changing the subject is not enough. Mutt and some other email reading programs also check other information beyond the email header subject to assign it to a thread, so it’s better to send a completely new email.

In forums, because messages are closely tied to specific threads and are often not visible outside the thread, good questioning practices are slightly different; asking a question in a reply is not a problem. Not all forums allow separate subjects to appear in replies, and doing so generally means that no one will see it. However, asking a question in a reply is itself a questionable practice, as they will only be read by those currently viewing that thread. So unless you only want to ask a question among the currently active crowd in that thread, it’s better to start anew.

Make Questions Easy to Answer#

Ending a question with "Please reply to..." will likely result in no answer. If you think it’s a hassle to take a few seconds to set a reply address in your email client, we find it even more troublesome to spend a few seconds considering your question. If your email client does not support this, get a better one; if your operating system does not support all such email clients, get a better one.

In forums, requesting replies via email is completely rude unless you are sure the reply information may be sensitive (and someone will only let you know the answer for some unknown reason). If you just want to be notified by email when someone replies to the thread, you can request the forum to send notifications. Almost all forums support features like "Watch this thread" or "Email me when there are replies."

Write Clearly, with Correct Grammar and Spelling#

Experience shows that careless and hasty authors are usually careless and hasty thinkers and programmers (I dare bet). Answering questions for these careless and hasty thinkers is not beneficial; we would rather spend our time elsewhere.

Clearly and well expressing your question is very important. If you find this troublesome, we also find it troublesome to pay attention to (your question). Spend a little extra effort choosing your words; it doesn't have to be too stiff or formal—in fact, hacker culture values the accurate use of informal, colloquial, and humorous language. But it MUST be very accurate, and there should be signs that you are thinking and paying attention to the problem.

Spell correctly, use punctuation and capitalization properly; don't confuse its with it's, loose with lose, or turn "discrete" into "discreet." Don't use all caps; this will be seen as rude shouting (all lowercase is not much better, as it is hard to read. Alan Cox [Note: a famous hacker and important contributor to the Linux kernel] might get away with it, but you won't).

In general, if you write like a half-literate fool, you will likely not get a response. Also, do not use abbreviations from instant messaging, such as shortening you to u, as this will make you look like a half-literate fool trying to save a second keystroke. Worse, if you write like a child doodling, you are definitely asking for trouble; you can be sure no one will pay attention to you (or at most, they will give you a heap of criticism and ridicule).

If you are asking in a non-native language forum, your spelling and grammar mistakes will receive limited tolerance, but laziness will not be tolerated at all (yes, we can usually see the difference). Also, unless you know the language of the responders, please write in English. Busy hackers will generally delete messages written in languages they do not understand. English is the working language on the internet, and writing in English minimizes the chance that your question will be deleted unread.

If you write in English but it is your second language, it is best to remind potential responders of possible language difficulties to circumvent this issue, such as:

English is not my native language; please forgive any spelling mistakes.
If you speak [language], please email/DM me; I may need your help translating my question.
I am familiar with this technical term itself, but I am not clear on some of its slang or idiomatic expressions.
I have asked in both [language] and English; if you reply in either, I would be happy to translate.

Send Questions in an Easy-to-Read and Standard File Format#

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

Use plain text instead of HTML (turning off HTML is not hard).
Using MIME (Multipurpose Internet Mail Extensions) attachments is usually fine, provided they contain real content (e.g., accompanying source files or patches), not just a template generated by the email client (e.g., just a copy of the message content).
Do not send entire paragraphs of single-line sentences that wrap multiple times (this makes it very difficult to reply to parts of the content). Imagine your reader is reading the email on an 80-character-wide text terminal; set your line wrap points to less than 80 columns.
However, also DO NOT wrap data in any fixed column (e.g., log file copies or session records). Data should be included as-is, so that the responder can be sure they are seeing the same thing you are seeing.
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 it. When they break, the " =20 " symbols scattered throughout the text are both unsightly and distracting, and may even disrupt the semantic content.
Never expect hackers to read documents written in closed proprietary formats, such as Microsoft Word or Excel files. Most hackers will 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 the problematic Microsoft "smart quotes" feature (uncheck the smart quotes box in "Tools" -> "AutoCorrect Options" under "AutoFormat As You Type") to avoid scattering garbage characters throughout your email.
In forums, do not abuse "emoticons" and "HTML" features (when they are provided). One or two emoticons are usually fine, but flashy 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 are using a graphical user interface email client (like Netscape Messenger, Microsoft Outlook, or similar), be aware that their default configurations may not meet these requirements. Most of these programs have a menu-based View Source command; use it 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 Substantively#

Carefully and clearly describe the symptoms of the problem.
Describe the environment in which the problem occurs (host, operating system, application, anything relevant), providing the vendor's distribution and version number (e.g., "Fedora Core 7," "Slackware 9.1," etc.).
Describe the research and understanding you had before asking the question.
Describe the diagnostic steps you took to identify the problem before asking the question.
Describe any relevant changes made to the computer or software configuration recently.
If possible, provide a method to reproduce the problem in a controlled environment.
Do your best to anticipate the questions hackers might ask and prepare answers in advance.

If you think there is a problem with the code, providing a method to reproduce the problem in a controlled environment is especially important. When you do this, the likelihood of receiving useful and timely replies will greatly increase.

Simon Tatham has written an article titled "How to Report Bugs Effectively," which I strongly recommend everyone read.

Quality Over Quantity#

You should write concisely and substantively; simply listing a large chunk of code or data in a help message will not achieve your goal. If you have a large and complex test case that causes the program to crash, try to trim it down as much as possible.

There are at least three reasons to support this. First, showing others that you are making an effort to simplify the problem makes it more likely you will get a response. Second, simplifying the problem increases the chances of getting a "useful" reply. Third, in the process of refining the bug report, you may find the solution or a workaround yourself.

Don't Rush to Claim You've Found a Bug#

When you encounter a problem in software, unless you are extremely, extremely sure, do not hastily claim you have found a bug. Hint: unless you can provide a source code patch that solves the problem or demonstrate incorrect behavior in regression tests against a previous version, you are likely not completely certain. The same goes for web pages and documentation; if you claim to have found a "bug" in the documentation, you should be able to provide alternative text for the relevant location.

Remember, many other users have not experienced the problem you are encountering; otherwise, you would have noticed it while reading documentation or searching the web (you did do these before complaining, right?). This also means it is very likely that you are mistaken rather than the software itself being at fault.

The people who write software work very hard to make it as perfect as possible. If you claim to have found a bug, you are also questioning their abilities, and even if you are right, it may upset some of them. (Additionally, shouting "Bug" in the subject line is particularly ungracious.)

When asking questions, even if you are privately very sure you have discovered a real bug, it is best to write as if you made a mistake. If there is indeed a bug, you will see that in the replies. This way, if there is a bug, the maintainer will apologize to you, which is always better than you messing up and then owing someone an apology.

Being Submissive Doesn't Replace Doing Your Homework#

Some people understand they shouldn't act rudely or arrogantly and demand answers, but they retreat to the opposite extreme of being overly submissive: "I know I'm just a pathetic newbie, a loser, but...". This is both annoying and unhelpful, especially when accompanied by a vague description of the actual problem.

Don't waste your time and mine with low-level primate tactics; instead, describe the background and your problem as clearly as possible, which will better position you than being overly submissive.

Sometimes forums have separate beginner question sections; if you really think you have encountered a superficial problem, go there, but still, don't be overly submissive.

Describe Symptoms of the Problem, Not Speculation#

Telling hackers what caused the problem is useless (if your diagnostic theory is so brilliant, would you be asking for help?). So, make sure to only tell them the original symptoms of the problem, not your explanations and theories; let them explain and diagnose. If you think stating your guesses is important, clearly indicate that these are just your guesses and describe why they don't work.

Stupid:

I keep getting SIG11 errors while compiling the kernel; I suspect a circuit trace on the motherboard is broken. What's the best way to find them?

Smart:

My assembled computer (K6/233 CPU, FIC-PA2007 motherboard [VIA Apollo VP2 chipset], Corsair PC133 SDRAM 256Mb) frequently reports SIG11 errors about 20 minutes after startup while compiling the kernel, but it never has issues in the first 20 minutes. Restarting does not reset the clock, but it will after being off all night. Replacing all the memory did not resolve the issue; the typical compilation session log is attached.

Because many seem to struggle with this point, here's a saying 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, cockleburs, and Democrats, and I can tell you that eloquence neither convinces me nor satisfies me. I come from Missouri; you have to show me."). For diagnosticians, this is not skepticism but a genuine and useful need to see something as close to the original evidence as possible, rather than your guesses and summaries. (So,) let us see.

Chronologically List Symptoms of the Problem#

What happened just before the problem often contains the most effective clues for solving it. Therefore, the record should accurately describe what you, the computer, and the software were doing before the crash. In command-line situations, having a session log (such as one generated by a script tool) and quoting several relevant lines (like 20) will be very helpful.

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

If your log is long (e.g., over four paragraphs), summarizing the problem at the beginning and then chronologically listing the detailed process may be more useful. This way, hackers will know what to pay attention to as they read your record.

Describe Goals, Not Processes#

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

It often happens that those seeking technical help have a higher-level goal in mind; they get stuck on a specific path they think will lead to that goal, and then they come to ask how to proceed without realizing that the path itself is problematic, resulting in a lot of effort to get through.

Stupid:

How can I get a certain graphics program's color picker to get hexadecimal RGB values?

Smart:

I'm trying to replace a palette in an image with colors of my choosing; the only method I know is to edit each palette slot, but I can't get a certain graphics program's color picker to get hexadecimal RGB values.

The second phrasing is smart; it allows for the possibility of suggesting a more appropriate tool to accomplish the task.

Don't Request Private Email Replies#

Hackers believe that the process of solving problems should be public and transparent; if more capable people notice incomplete or inappropriate aspects, the initial reply can be corrected. At the same time, responders also receive some recognition for their abilities and knowledge from their peers.

When you request private replies, both the process and the recognition are interrupted. Don't do this; let the responders decide whether to reply privately—if they do, it is usually because they think the question was written too poorly or too superficially to be meaningful to others.

There is a limited exception to this rule; if you are sure that your question may attract a lot of similar replies, then "Email me; I will summarize these replies for the forum" will be a magical sentence. Trying to rescue the mailing list or newsgroup from a flood of identical replies is very polite—but you must keep your promise.

Questions Should Be Clear#

Vague questions are often seen as bottomless pits of time without clear limits. The people most likely to give you useful answers are usually the busiest (if only because they have too much work to do), and these people are extremely sensitive to endless time pits, so they tend to dislike vague questions.

If you clarify what you want the responder to do (like pointing you in the right direction, sending code, checking patches, or other), you are more likely to get a useful reply. (Because) this allows them to focus and indirectly sets a limit on the time and effort they need to spend to help you, which is good.

To understand the world of experts, think of it this way: there are abundant resources of expertise but scarce response time. The less time you secretly ask them to devote, the more likely you are to get answers from those who truly know their stuff and are genuinely busy.

So limit your questions to minimize the time experts need to spend answering—this is often not quite the same as simplifying the problem. For example, "Could you point me to a good explanation of X?" is usually smarter than "Please explain X." If your code isn't running, asking someone to take a look at what the problem is is usually wiser than asking them to fix it for you.

Questions About Code#

Don't ask others to debug your code without mentioning where to start. Posting hundreds of lines of code and then saying "It doesn't work" will get you ignored. Posting a few dozen lines of code and then saying "After line seven, it should display, but what appears is..." is much more likely to get you a reply.

The most precise way to describe a code problem is to provide a minimal test case that demonstrates the issue. What is a minimal test case? It is a demonstration of the problem that includes just enough code to reproduce the unexpected behavior. How do you generate a minimal test case? If you know which line or block of code is causing the problem, copy it and provide just enough surrounding support code to form a complete example (enough means the source code can be accepted by the compiler, interpreter, or any program processing it). If you cannot narrow the problem down to a specific section, copy the source code and remove the parts that are unrelated to the problem. The smaller the minimal test case you can provide, the better (see Quality Over Quantity).

Generating a very small minimal test case is not always possible, but trying to do so is a good exercise that may help you find the problem you need to solve yourself. Even if you can't find it, hackers appreciate seeing your effort, which will make them more cooperative.

If you just want someone to help review your code, state that at the very beginning, and be sure to mention which part you think needs special attention and why.

Don't Post Homework-Style Questions#

Hackers are good at spotting "homework" style questions. Most of us have done our homework; that is what YOU should do to learn something. Asking for hints is fine, but not for a complete solution.

If you suspect you have encountered a homework-style 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 seasoned users may still give you hints.

Eliminate Meaningless Requests#

Resist the temptation to add meaningless phrases at the end of your help message, such as "Can anyone help me?" or "Is there an answer?" First, if the problem description is incomplete, these additional phrases can only be redundant at best. Second, because they are redundant, hackers will find them annoying—leading to logically correct but dismissive replies like "Yes, you can get help" and "No, there is no help for you."

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

Don't Mark Questions as "Urgent," Even if They Are to You#

This is your problem, not ours. Declaring "urgent" is likely to backfire: most hackers will delete such messages outright, as they consider it rude and selfish to seek immediate and special attention. Moreover, "urgent" or other similar subjects may trigger spam filtering rules, and potential responders may never see your question!

There is a slight local exception; if you are using a program in a well-known place that excites hackers, it may be worth doing so. In that case, if you have a deadline, it is polite to mention that, and people may have enough interest to respond more quickly.

Of course, this is very risky, as hackers' standards for what is exciting often differ from yours. For example, posting from the International Space Station is fine, but doing so for feel-good charity or political reasons is almost certainly not. In fact, posting something like "Urgent: Help me save this fluffy little seal!" will definitely be avoided or anger hackers, even if they think fluffy little seals are important.

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

Politeness is Always Beneficial#

Be polite; use "please" and "thank you for your attention" or "thank you for your care" to let others know you appreciate their time spent helping you for free.

Frankly, this point is not as important as writing with correct grammar, clarity, accuracy, substance, and avoiding proprietary formats (and it cannot replace them). Hackers generally prefer to read somewhat brusque but technically sharp bug reports rather than polite but vague ones. (If this confuses you, remember we evaluate based on what the problem can teach us.)

However, if you have clearly articulated the technical issue, being polite will certainly increase your chances of receiving useful replies.

(We must point out that the only part of this article that has been seriously opposed by some old hackers is the previously recommended "Thanks in advance"; some hackers believe this 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 it differently, such as "Thank you for your attention" or "Thank you for your care.")

Add a Brief Note After the Problem is Resolved#

After the problem is resolved, add a message to everyone who helped to let them know how the problem was solved and thank them again. If the problem received widespread attention in the mailing list or newsgroup, it is appropriate to add this message there.

The ideal way is to reply to the original thread with this message and include an obvious marker in the subject like "Resolved," "Done," or other equivalent meanings. In a busy mailing list, a potential responder seeing threads like "Problem X" and "Problem X - Resolved" will understand not to waste time (unless they personally find "Problem X" interesting), allowing them to use that time to solve other issues.

The additional message does not need to be too long or complex; a simple "Hi—turns out the network cable was bad! Thanks everyone—Bill" is better than nothing. In fact, unless the technical solution is genuinely profound, a short and friendly summary is better than a lengthy dissertation. State what action resolved the problem without rehashing the entire debugging story.

For deeper issues, posting a summary of the debugging history is appropriate. Describe the final state of the problem, state what resolved it, and only then indicate the detours that could have been avoided. The detours should be placed after the correct solution and other summary materials, rather than turning this message into a detective novel. List the names of those who helped you, as that way you will make friends.

In addition to being polite and substantive, this type of follow-up will help others find the actual solution to your problem when searching the mailing list, newsgroup, or forum documentation, thus benefiting them as well.

Finally, such follow-ups also give each participant a sense of satisfaction from solving the problem. If you are not a technical expert or hacker yourself, trust us, this feeling is very important to the veterans and experts you are seeking help from. Leaving a problem narrative unresolved is always frustrating; hackers are itching to see them resolved. The "scratching itch" reputation you earn will be very helpful for your next post when you ask questions again.

Consider how you can prevent others from encountering similar problems in the future; ask yourself if compiling a document or FAQ patch would be helpful, and if so, send the patch to the maintainers.

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

How to Interpret Answers#

“Read the Fing Manual” (RTFM) and “Search the Fing Web” (STFW): How to Understand You've Completely Messed Up#

There is an old and sacred tradition: if you receive a reply to "Read the Fing Manual" (RTFM), the sender believes you should "read the fing manual." They are probably right; go read it.

"Read the Fing Manual" (RTFM) has a younger relative; if you receive a reply to "Search the Fing Web" (STFW), the sender believes you should "search the f***ing web." That person is likely also right; go search. (A gentler way to say this is "Google is your friend!")

In forums, you may also be asked to search the forum documentation. In fact, someone may even kindly provide you with previous solutions to this problem. But don't rely on this kindness; you should search the documentation before asking.

Typically, those who tell you to search have opened the manual or webpage that can solve your problem and are typing while looking at it. These replies mean they believe:

First, the information you need is easy to find.
Second, finding it yourself will teach you more than being spoon-fed.

You shouldn't feel offended by this; by hacker standards, the responder not ignoring you is a sign of respect, and you should be grateful for their eagerness to help you.

If You Still Don't Understand...#

If you don't understand the answer, don't immediately reply with a request for clarification; first, try using the same tools you used when you initially asked (like the manual, FAQ, webpage, knowledgeable friends, etc.) to try to understand the answer. If you still need clarification, show what you have understood.

For example, if I tell you, "It looks like there is a problem with some input; you need to clear it," a bad reply would be: "What is some input?" A good follow-up would be: "Yes, I read the manual; some input is only mentioned in the -z and -p switches, but neither explains how to clear them. Which one are you referring to, or did I misunderstand something?"

Dealing with Rudeness#

Many behaviors that seem rude in hacker circles are not meant to offend. Instead, they are a direct, blunt communication style that is natural for those more focused on solving problems than on making others feel comfortable and confused.

If you feel offended, try to respond calmly. If someone has truly crossed the line, the veterans in the mailing list, newsgroup, or forum will likely call them out. If this does NOT happen and you are still angry, then the words of the person who upset you may seem normal in the hacker community, and YOU will be seen as the one in the wrong, which will hurt your chances of getting information or help.

On the other hand, you may occasionally encounter truly rude and obnoxious behavior. In contrast to the above, it is acceptable to hit back hard at genuine offenders, using sharp language to thoroughly rebut them. However, be very, very sure before you act. Correcting rude comments and starting a pointless flame war is a fine line, and hackers themselves often overstep it. If you are a newcomer or outsider, the chances of avoiding such reckless opportunities are not high. If what you want is information rather than wasting time, it is best not to put your hands on the keyboard to avoid taking risks.

(Some people assert that many hackers have mild autism or Asperger's syndrome, lacking the brain circuits needed to lubricate "normal" social interactions. This may be true or false. If you are not a hacker, you might think we are crazy, but you can help deal with our quirky behavior. Just go ahead; we don't care. We like it this way and are generally skeptical of labels.)

In the next section, we will discuss another issue: the "offense" you will receive when YOU misbehave.

Don't React Like a Loser#

In hacker community forums, there may be times when you mess up—like in the way described in this article or similar. You will be publicly shown how you messed up, perhaps with some colorful language.

After such an event, the worst thing you can do is to wail about your fate, claim you are being verbally attacked, demand apologies, scream, sulk, threaten legal action, complain to their employer, forget to close the toilet lid, etc. Instead, you should do this:

Tough it out; it’s normal. In fact, it is healthy and appropriate.

Community standards do not maintain themselves; they are maintained through the active and PUBLIC enforcement by participants. Don't cry that all criticism should be conveyed through private emails; that is not how things work. When someone comments that something you said is incorrect or offers a different viewpoint, insisting that you are being personally attacked is also unhelpful; these are all loser attitudes.

There are also other hacker forums misled by high etiquette requirements that prohibit participants from posting any messages that critique others' posts, claiming "If you don't want to help users, shut up." The result of this is that thoughtful participants leave, turning them into meaningless chatter and useless technical forums.

Is exaggerated "friendliness" (in the above manner) useful? Choose one.

Remember: when a hacker says you messed up and (no matter how harshly) tells you not to do it again, they are acting out of concern for you and their community. For them, ignoring you and filtering you out of their lives is much easier. If you cannot manage to be thankful, at least have some dignity; don't wail loudly, and don't expect others to treat you like a fragile doll just because you are a dramatically sensitive soul who thinks you are entitled to special treatment.

Sometimes, even if you haven't messed up (or just others think you have), some people will attack you for no reason. In such cases, complaining will REALLY mess things up.

These troublemakers are either useless guys who think they are experts but are really clueless, or they are psychological experts testing whether you will truly mess up. Other readers will either ignore them or deal with them in their own way. You don't need to worry about these troublemakers getting themselves into trouble.

Also, don't let yourself get dragged into a flame war; most flame wars are best ignored—of course, only after you verify they are just flame wars, without pointing out where you messed up, and that they haven't cleverly hidden the real answer to the problem within.

Taboos in Asking Questions#

Here are some typical stupid questions and what hackers think when they don't answer them.

Q: Where can I find a certain program or X resource?

Q: How do I do Y with X?

Q: How do I configure my shell prompt?

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

Q: My {program, configuration, SQL statement} isn't working.

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

Q: My program isn't running; I think system tool X is the problem.

Q: I'm having trouble installing Linux or X; can you help?

Q: How can I crack the superuser password/steal channel operator privileges/view someone's email?

Where can I find a certain program or X resource?

Where I found it, dumbass—in a web search engine. Good grief, does anyone not know how to use Google?

How do I do Y with X?

If you want to solve Y, don't suggest a possibly inappropriate method when asking. This question indicates that the asker is not only completely ignorant of X but also confused about the Y problem they are trying to solve, and their thinking is constrained by specific circumstances. Wait until they get their question straightened out before proceeding.

How do I configure my shell prompt?

If you are wise enough to ask this question, you should also be wise enough to "Read the F***ing Manual" (RTFM) and figure it out yourself.

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

Try it and see. If you did, you would know the answer and wouldn't waste my time.

My {program, configuration, SQL statement} isn't working.

This is not a question; I have no interest in guessing what your problem is—I have more important things to do. My typical reaction to seeing this is:

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

My Windows computer has a problem; can you help?

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

Note: If the program has an official Windows version or interacts with Windows (like Samba), you CAN ask Windows-related questions; just don't be surprised if the response indicates that the problem is caused by the Windows operating system rather than the program itself, as Windows is generally so poor that this statement usually holds true.

My program isn't running; I think system tool X is the problem.

You could very well be the first person to notice a significant flaw in a system call or library that has been used by thousands of users; more likely, you are completely mistaken. Extraordinary claims require extraordinary evidence; when you make such claims, you must have a clear and detailed defect documentation to back it up.

I'm having trouble installing Linux or X; can you help?

No, I need to operate your computer hands-on to help you debug; seek convenient help 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 the mailing list, forum, or local user organization dedicated to it. In this case, describe the problem's exact details. Before doing so, carefully search using "linux" and all suspected hardware [as keywords].

How can I crack the superuser password/steal channel operator privileges/view someone's email?

Wanting to do such things indicates you are a despicable person; asking hackers to teach you how to do such things indicates you are an idiot.

Good Questions vs. Bad Questions#

Finally, I will illustrate the wisdom of asking questions by providing examples. The same question can be phrased in two ways: one foolish, the other wise.

Foolish: Where can I find something about the Foonly Flurbamatic device?

This question begs for a "Search the F***ing Web" (STFW) type of reply.

Wise: I searched Google for "Foonly Flurbamatic 2600," but found nothing useful; does anyone know where I can find programming information for this device?

This person has searched the web and sounds like they may have genuinely encountered a problem.

Foolish: I can't compile the source code for a certain project; why is it so broken?

The asker assumes someone else messed up; this is too arrogant.

Wise: The source code for a certain project won't compile under a certain version of Linux 6.2. I read the FAQ, but there was nothing related to Linux in it. Here is the log from the compilation; what did I do wrong?

The asker has indicated the operating environment, read the FAQ, listed the errors, and has not assumed the problem is someone else's fault; this person is worth noticing.

Foolish: My motherboard has a problem; who can help me?

A hacker's reaction might be: "Yes, do you need help with diaper changes too?" followed by hitting the delete key.

Wise: I tried X, Y, and Z on the S2464 motherboard, and after they all failed, I tried A, B, and C. Note the strange symptoms when I tried C; clearly, something is doing something unexpected, which is not the expected behavior. What are the usual causes of this on an Athlon MP motherboard? Is there anything else I can try to determine the problem?

In contrast, this person seems worth answering. He or she demonstrates the ability to solve the problem rather than waiting for a handout.

In the last question, note the subtle but important difference between "Give me an answer" and "Please help me see what else I can test to gain insight."

In fact, the last question is based on a real event from the Linux kernel mailing list (lkml) in August 2001, when I (Eric) asked that question; I discovered mysterious crashing issues with the Tyan S2462 motherboard, and members of the mailing list provided me with key information to resolve the issue.

By asking in this way, I provided something for others to chew on. I managed to make it both easy and engaging for participants while showing respect for their abilities and inviting them to collaborate with me. By telling them the detours I had taken, I also demonstrated respect for their valuable time.

Afterward, when I thanked everyone and commented on the good experience, a member of the Linux kernel mailing list mentioned that he thought I got an answer not because my name was on the list, but simply because of the way I asked the question.

Hackers are, in some ways, very unforgiving elites. I think he was right on this; if I had behaved like a parasitic freeloader, I would have been ignored or scolded, no matter who I was. He suggested using the entire event as guidance for others asking questions, which directly led to the writing of this article.

If You Don't Get an Answer#

If you don't get an answer, don't assume we don't want to help you; sometimes it is simply because the group members being asked genuinely do not know the answer. No reply does not equate to being ignored, though it must be acknowledged that it is difficult to see the difference from the outside.

In general, directly reposting the question is not a good idea; this will be seen as meaningless harassment. Be patient, knowing that the person who knows the answer to your question may live in a different time zone, may be asleep, or your question may not have been organized well from the start.

There are other resources to seek help, usually in some beginner-oriented resources.

There are many online and local user organizations that, while they do not write any software, are enthusiastic about it. These user groups are often formed out of mutual assistance and helping beginners.

Many small and large commercial companies also offer contracted support services; don't feel discouraged just because you have to pay a little for support! After all, if your car's head gasket is blown, you will likely have to pay a repair shop to fix it. Even if the software didn't cost you a penny, you can't expect all service support to be free.

For popular software like Linux, each developer has at least ten thousand users, and one person cannot handle the service requests of so many users. Remember, even if you have to pay for support, it is still less than you would have to pay to buy the software in the first place (and support for closed-source software is usually more expensive and less effective compared to open-source software).

How to Answer Better#

Be kind. The pressure from questions 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 made a mistake; a true newbie may not even know how to search or where to find the FAQ.

If you are unsure, be sure to say so! An authoritative-sounding incorrect reply is worse than none at all; don't 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 can't help, don't hinder. Don't joke about specific steps, as that may ruin the user's installation—some poor fool might take it as genuine instructions.

Exploratory questions can draw out more details. If you do well, the questioner can learn something—you can too. Try to turn a poor question into a good one; don't forget we were all newbies once.

While it is legitimate to complain to lazy people to "Read the F***ing Manual" (RTFM), it is better to point out where the documentation is (even if it is just suggesting a Google keyword search).

If you are determined to answer, provide good answers. Don't suggest clumsy workarounds when others are using the wrong tools or methods; recommend better tools and reorganize the question.

Please answer the actual question! If the questioner has done their homework and states they have tried X, Y, Z, A, B, and C without getting the desired result, then replying with "Try A or B" or providing a link that says "Try X, Y, Z, A, B, or C" will be extremely unhelpful!

Help your community learn from it. When replying to a good question, ask yourself, "How can I modify the relevant files or FAQ documentation to avoid answering the same question again?" Then send a patch to the documentation maintainers.

If you are answering after some research, showcase your skills rather than just handing over the results. After all, "teaching a man to fish is better than giving him a fish."

For basic knowledge of how personal computers, Unix, and the internet work, refer to Basic Principles of Unix and the Internet.

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

Acknowledgments#

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