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

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

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

To help point out translation issues, please file an issue, or directly submit a pull request to me.

There is also a simplified Chinese version of this article: https://github.com/FredWe/How-To-Ask-Questions-The-Smart-Way/blob/master/README-zh_CN.md

Original Version History #

Declaration#

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

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

We have deeply experienced the pain caused by the absence of the above statement. Without this statement, we are constantly harassed by some idiots. These idiots 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 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 encounter, and in 99% of cases, that will not be us. Unless you are sure that one of the authors of this guide happens to be an expert in the area of the problem you are facing, 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, now that open source software has become quite popular, 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 beginners encounter than hackers. However, treating experienced users as hackers and communicating with them using the methods outlined in this guide is also the most effective way to get satisfactory answers from them.

First, you should understand that hackers love challenging questions or good questions that stimulate our thinking. If we were not like that, we would not 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 inspiration, 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 beginners and the ignorant, but that is not the case.

We do not shy away from our contempt for those who are unwilling to think or who do not do their homework 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 losers (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 are not interested 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 do not 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 look like losers, in order to use our time more efficiently to answer winners questions.

If you dislike our attitude, feel superior, or think we are too arrogant, 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 put in a little 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 proficient to attract our attention, but you must demonstrate qualities that show you can guide yourself to proficiency—intelligence, thoughtfulness, good observation, and a willingness to actively participate in problem-solving. 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, just occasionally needing a little help on specific issues.

(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 Questions#

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

Try searching the old articles in the forum where you are preparing to ask.
Try searching online to find the answer.
Try reading the manual to find the answer.
Try reading the FAQ to find the answer.
Try checking or experimenting on your own to find the answer.
Ask strong friends around you for answers.
If you are a developer, try reading the source code to find the answer.

When you ask a question, please first indicate that you have made the above efforts; this will help establish that you are not a time-wasting asker. It would be even better if you could express what you have learned during 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 the various error messages you encounter (searching both Google Groups and web pages), as this is likely to lead you directly to documents or mailing list clues that can solve the 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 provide. Doing this (along with the searched strings) also allows others encountering 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 a response. Do not throw all your questions out at once just because your first search did not yield answers (or found too many answers).

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

Be careful not to ask the wrong questions. 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 have not paid for this service. You will have to earn an answer by asking meaningful, interesting, and thought-provoking questions—a question that has 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 someone give me a hint? or What am I missing in this example? and What should I check? are more likely to get a response 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 Questions#

Choose the Right Forum for Your Questions#

Be careful in selecting the occasion to ask your questions. If you do any of the following, you are likely to be ignored or seen as a loser:

Posting your question in a forum that is off-topic.
Posting very basic questions in forums discussing advanced technical issues; and vice versa.
Cross-posting the same question in too many different newsgroups.
Sending private emails to people who are neither acquaintances nor obligated to solve your problem.

Hackers will filter out questions that are in the wrong venue to protect their communication channels from being flooded with irrelevant content. You do not want this to happen to you.

Therefore, the first step is to find the right forum. Again, Google and other search engines are your friends; use them to find the websites most relevant to the software or hardware problems you are encountering. Usually, there are links to FAQs, mailing lists, and related documentation there. If your efforts (including reading the FAQ) yield no results, there may be a bug-reporting process or link on the website; if so, check it out.

Sending emails to strangers or forums is often the riskiest thing to do. For example, do not assume that an author of a content-rich website will want to act as your free consultant. Do not be overly optimistic about whether your question will be welcomed—if you are unsure, send it elsewhere or do not send it at all.

When choosing forums, newsgroups, or mailing lists, do not trust the names too much; first, check the FAQ or charter to clarify whether your question is on-topic. Before posting, skim through existing topics to get a feel for the culture there. In fact, it is an excellent idea to search the history of the newsgroup or mailing list for keywords related to your question; you might find the answer that way. Even if you do not, it can help you formulate a better question.

Do not "spray and pray" by blasting all help channels at once; this is like shouting and will annoy people. Take it one at a time.

Clarify your topic! One of the most typical mistakes is to ask about Unix or Windows programming interfaces in a forum dedicated to cross-platform portable languages, suites, or tools. If you do not understand why this is a big mistake, it is best not to ask anything until you figure out the differences.

In general, asking questions in carefully chosen public forums will yield more useful answers than asking the same questions in private forums. Several reasons support this: one is the number of potential responders, and the other is the size of the audience. Hackers are more willing to answer questions that can help many people.

It is understandable that seasoned hackers and authors of some popular software are overwhelmed by too many misdirected messages. Just like the last straw that broke the camel's back, your addition could push the situation to extremes—several authors of popular software have withdrawn from supporting their software because the flood of useless emails pouring into their private inboxes became unbearable.

Stack Overflow#

Search, then ask on Stack Exchange.

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

Because Google indexing is instantaneous, search on Google before looking at Stack Exchange. There is a high chance someone has already asked a similar question, and the Stack Exchange sites often appear among the top search results. If you do not find any answers on Google, then look at the specific relevant topic sites. Searching by tags can help narrow down your search results.

Stack Exchange has grown to over a hundred sites, and here are some of the most commonly used ones:

Super User is for asking general computer questions; if your question is not related to coding or programming, but rather about network connections, come here.
Stack Overflow is for asking programming-related questions.
Server Fault is for asking server and network management-related questions.

Websites and IRC Forums#

Local user groups or the Linux distribution you are using may be promoting their web forums or IRC channels, providing help for beginners (in some non-English 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 and welcoming places for questions, and you can usually get responses immediately.

In fact, if the problems with the program only occur in the version provided by a specific Linux distribution (which is quite common), it is best to ask in that distribution's forum or mailing list first before asking in the program's own forum or mailing list. (Otherwise) the hackers of that project may simply reply, "Use our version."

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; this might help. If you have done a general web search beforehand (which you should), search the forum again; the search engine may not have indexed all the content of that forum yet.

There is a growing trend of providing user support via forums or IRC channels, while email is mostly reserved for communication among project developers. So it is best to seek assistance related to the project in forums or IRC first.

Step Two: Use Project Mailing Lists#

When a project provides a developer mailing list, ask questions to the list rather than to 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 to adopt this approach:

Any question good enough to be directed to an individual developer 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 questions to 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 archived contents will be indexed by search engines. If you ask a question to the list and get an answer, others can find your question and answer through web searches in the future, thus avoiding asking 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 touching the source code, then ask in the "user" list or forum. Do not assume you will be welcomed in the developer list; those people will likely see your question as noise interrupting their development.

However, if you are sure your question is very special and there have been no replies in the "user" list or forum for several days, you can try asking in the "developer" list or forum. It is advisable to observe quietly for a few days before posting to understand the way things work 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 email address of the project maintainer, feel free to email them. Even in this case, do not assume that (the project) mailing lists do 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 nothing secret, private emails should not be made public. By allowing your email to be forwarded, you give the relevant personnel the option to handle your email).

Use Meaningful and Descriptive Titles#

In mailing lists, newsgroups, or forums, a title of about 50 words is a good opportunity to catch the attention of seasoned experts. Do not waste this opportunity with verbose titles like Help!, Please!, Urgent (let alone Help me!!!! which is off-putting; such titles will be reflexively ignored). Do not expect to impress us with the degree of your pain; instead, use that space to present a very simple and concise description of your question.

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 does not match expectations.

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

Smart Question: Mouse cursor distorts in X.org 6.8.1 with MV1005 chipset graphics card.

Even Smarter Question: Mouse cursor distorts in X.org 6.8.1 environment with MV1005 chipset graphics card.

Writing a Goal -- Difference 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 the X version of X.org? Or just in version 6.8.1? Is it specific to a certain graphics card chipset? Or just the MV1005 model? A hacker can glance at it and immediately understand your environment and the problem you are encountering.

In summary, imagine you are searching an archive discussion thread that only shows titles. Making your title better reflect the problem can help the next person searching for similar issues to focus on that discussion 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 simply click reply to start a whole new discussion 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, and 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 cannot be seen outside the thread, so asking by replying rather than changing the title is acceptable. Not all forums allow separate titles in replies, and doing so will generally mean that no one will look at it. However, asking 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 of the current active participants in that discussion thread, it is better to start a new thread.

Make Questions Easy to Reply#

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

In forums, requesting replies via email is very rude unless you believe the information in the reply may be sensitive (and someone may only want to 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 web forum to send you notifications. Almost all forums support features like Track this thread or Email me when there are replies.

Use Clear, Correct, Precise, and Proper Grammar Statements#

From experience, we find that careless askers are often careless in writing programs and thinking (I can bet on it). 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 troublesome to do so and do not care about these, we also find it troublesome and do not care about your question. Spend a little extra effort to consider your wording; it does not 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 accurate and show signs that you are thinking and paying attention to the problem.

Spell correctly, use punctuation and capitalization properly; do not confuse its with it's, loose with lose, or discrete with discreet. Do not use all caps, as this will be seen as shouting (all lowercase is not much better, as it is hard to read. Alan Cox might be able to do this, but you cannot).

In simpler terms, if you write like a semi-literate translator's note: 小白, you will likely not get a response. Also, do not use instant messaging abbreviations or leet speak, such as simplifying 的 to ㄉ will make you look like a newbie trying to save a few keystrokes. Worse, if you write like a child scribbling, you are definitely asking for trouble; you can be sure no one will pay attention to you (or at most give you a lot of criticism and ridicule).

If you are asking questions in a forum where English is not your native language, you may make some spelling and grammar 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 universal 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 indicate to potential responders that you may have language difficulties:
[Translator's note: The following is the original text 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 am not very familiar with slang or special usages.

I've posted my question in $LANGUAGE and English.
I'll be glad to translate responses, if you only use one or the other.

I have written my question in a certain language and English; if you answer in only one language, I will be happy to translate it into the other.

Send Questions in Easy-to-Read and Standard File Formats#

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 (turning off HTML is not hard).
Using MIME attachments is usually acceptable, provided they contain real content (e.g., attached 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 block of text that is just a single-line sentence but broken into multiple lines (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 data (e.g., log file copies or session records). The files should be left intact so that the responder can be confident that what they see is the same as what 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 that text are both unsightly and distracting, and may even disrupt the content's semantics.
Absolutely, never expect hackers to read documents written in closed formats, such as Microsoft Word or Excel files. Most hackers react to this like someone dumping 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 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 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 are using a graphical user interface 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; use it to check messages in your sent folder to ensure you are sending a clean plain text file without extra impurities.

Describe Problems 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 determine 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 the answers when they ask.

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

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

Quality Over Quantity#

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 can reproduce 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.

Don't Claim to Have Found a Bug Too Easily#

When you encounter a problem using software, unless you are very, very sure, do not claim to 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 sure. This also applies to web pages and documents; if you (claim to) find a bug in a document, you should be able to provide a fix or alternative document for the relevant location.

Remember, many other users have not encountered the problem you discovered; otherwise, you would have found it while reading the document or searching the web (you did those before complaining, right? #before-asking-questions). 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 questioning their abilities; even if you are right, it could offend some of them. This is especially serious when you shout about a bug in the title.

When asking questions, even if you are privately very sure you have discovered a genuine bug, it is best to write as if you did something wrong. If there is indeed a bug, you will see this in the replies. By doing this, if there is a bug, the maintainers will apologize to you, which is always better than annoying others and then owing them an apology.

Be Humble, But Do Your Homework First#

Some people understand 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 loser, but.... This is both annoying and unhelpful, especially when accompanied by vague descriptions of the actual problem.

Do not waste your time and 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 encountered a beginner's problem, go there, but do not be overly humble.

Describe Symptoms of the Problem, Not Speculations#

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

Stupid Question

I keep getting SIG11 errors when compiling the kernel; I suspect a wire is touching the motherboard's traces. 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. I frequently get SIG11 errors when compiling the kernel after about 20 minutes of booting, but the same problem has never occurred 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 relevant part of the standard compile log is as follows...

Since the above seems difficult for many to cooperate with, 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. (This comes from Congressman Willard D. Vandiver's speech in 1899: I come from a state that produces corn, cotton, ginseng, and Democrats; eloquence neither convinces me 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 as closely aligned with the original evidence you see as possible, rather than your guesses and inductive conclusions. So, show us generously!

List Symptoms in Chronological Order#

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 (e.g., generated by running a script tool) and quoting relevant lines (like 20 lines) will be very helpful.

If the crashing program has diagnostic options (like the -v verbose switch), try selecting those options that add debugging information to the logs. 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 long (e.g., more than four paragraphs), summarizing the problem at the beginning and then detailing it chronologically afterward will be helpful. This way, hackers will know what to pay attention to when reading your logs.

Describe Goals, Not Processes#

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 that have you 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 get it done.

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 selected color codes. The only method I know is to edit each color code block, but I cannot obtain the hexadecimal RGB value from the color picker of a certain drawing program.

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

Don't Request Private Email Replies#

Hackers believe that the process of solving problems should be public and transparent; if more experienced people notice incompleteness or impropriety during this process, the initial response can and should be corrected. At the same time, helpers can gain some recognition for their abilities and knowledge from their peers.

When you request private replies, both the process and the reward are interrupted. Do not do this; let the responder decide whether to reply privately—if they do, it is usually because they think the question is poorly written or too superficial to interest others.

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

Clearly and Explicitly Express Your Questions and Needs#

Vague questions are nearly endless time black holes. The people most likely to give you useful answers are usually the busiest (they are busy because they have to do most of the work themselves). Such people are quite averse to unrestrained time black holes, so they 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 get useful answers. This sets a time and energy limit, allowing the responder to focus their efforts 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 truly professional and busy experts.

So, define your question in a way that minimizes the time experts spend identifying your problem and the time needed to answer; this technique is very helpful in getting you useful answers—but this technique is usually different from simplifying the problem. Therefore, asking I want to better understand X; could you point me to some good documentation? 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 lies than to ask them to fix it for you.

When Asking About Code#

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

The most effective way to describe program problems is to provide the smallest possible bug-demonstrating test case. What is the smallest test case? It is a snapshot of the problem; a small piece of code that just demonstrates the abnormal behavior of the program without containing other distracting content. How to create the smallest test case? If you know which line or block of code causes the abnormal behavior, copy it and add enough code to reproduce the situation (for example, enough to allow this code to be compiled/interpreted/processed by the application). 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 Quality Over Quantity section).

In general, obtaining a reasonably small test case is not too 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 attempts are unsuccessful, hackers will see that you have made an effort to obtain answers, which can make them more willing to collaborate 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 Your Homework Questions#

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

If you suspect you have encountered a homework-style problem 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 give you some hints.

Remove Meaningless Questions#

Avoid ending your 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 this is superfluous.

Second: Since asking this is superfluous, hackers will be very annoyed with you—and they 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-or-no, true-or-false, or have-or-have-not type questions unless you want a yes-or-no type answer.

Even If You're Urgent, Don't Write Urgent in the Title#

This is your problem, not ours. Declaring something as urgent is likely to backfire: most hackers will delete rude and selfish attempts to grab immediate attention. More seriously, the word urgent (or other attention-seeking titles) is often filtered out by spam filters—those who would want to see your problem may never see it.

There is a half exception; if you are in a very high-profile place that excites hackers, it may be worth doing so. In that case, if you have time pressure, it is also polite to mention it, and people may be interested in answering quickly.

Of course, this is risky because what excites hackers is often different from your concerns. For example, posting such a title from the NASA International Space Station (International Space Station) is fine, but doing so for self-satisfied charitable actions or political reasons is definitely not. In fact, posting something like Urgent: Help me save this fluffy little seal! will definitely get you ignored or annoy hackers, even if they think the fluffy little seal is important.

If you find this point unbelievable, it is best to read the rest of this guide a few more times until you understand it before posting.

Politeness is Appreciated and Sometimes Helpful#

Be polite, and use please and thank you for your attention or thank you for your help often. Let everyone know you appreciate their time and effort in providing help for free.

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

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

(We have noticed that since the publication of this guide, the only significant feedback from seasoned hackers has been about the preemptive thanks point. 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 help.)

After Solving the Problem, Add a Brief Follow-Up#

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

The ideal way is to reply to the original thread with this message and include a clear marker in the title like Resolved, Solved, or other equivalent indications. In busy mailing lists, a potential responder seeing the discussion thread Problem X and Problem X - Resolved will understand that they do not need to waste time (unless they personally find Problem X interesting), thus freeing up time to solve other issues.

The follow-up does not need to be long or in-depth; a simple Hi, it turned out to be a problem with the network cable! Thanks everyone – Bill is better than saying nothing. In fact, unless the conclusion is genuinely technical, a short and sweet summary is better than a lengthy discourse. Explain how the problem was solved, but there is no need to recount the entire process of solving the problem.

For deeper issues, summarizing the debugging logs 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 be placed 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 meaningful, this type of follow-up also helps others searching the mailing list/newsgroup/forum to find the solution that truly resolved your problem, allowing them to benefit as well.

At the very least, this follow-up helps each 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 for those masters or experts you sought help from. An unresolved problem can be disheartening; hackers are eager to see problems resolved. Good people are rewarded; satisfying their desires will pay off when you ask questions next time.

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 damn 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 damn web. That person is likely also right; go search for it. (A gentler way of saying 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.

Usually, the person answering you 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 having it spoon-fed to you.

You should not be upset by this; by hacker standards, they have shown a certain degree of concern for you without ignoring 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 other person to explain. Like when you previously tried to solve the problem (using manuals, FAQs, the web, and knowledgeable friends), first try to understand their response. If you really need the other person to explain, remember to show that you have learned something from it.

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

Dealing with Rude Responses#

Many behaviors that seem rude in hacker circles are not meant to offend. Instead, they are direct, straightforward communication styles that prioritize problem-solving over making people feel comfortable and vague.

If you feel offended, try to respond calmly. If someone has genuinely crossed a line, the elders in the mailing list, newsgroup, or forum will likely call them out. If this does not happen and you get angry, then the words of your target may appear normal in hacker culture, and you will be seen as the one at fault, which will hurt your chances of obtaining information or help.

On the other hand, you may occasionally encounter genuinely rude and annoying 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 acting. Correcting rude remarks and starting a pointless flame war is a fine line, and hackers often cross it themselves. If you are a newcomer or an outsider, the chances of avoiding such reckless opportunities are not high. If you want information rather than to waste 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 nerves needed to lubricate normal human social interactions. This may be true or false. If you are not a hacker, you may think we are crazy and can help you cope with our quirky behavior. Just go ahead; we do not care. We like the way we are now and are usually skeptical of labels.)

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

How to Avoid Playing the Loser#

In hacker community forums, there may be times when you mess up—either in the ways described in this guide or similar ways. And you may be told publicly how you messed up, perhaps with some colorful language mixed in.

After such an event, the worst thing you can do is to wail about your experience, claim to be verbally attacked, demand an apology, scream, sulk, threaten legal action, complain to their employer, forget to close the toilet lid, and so on. Instead, you should:

Get through it; it is normal. In fact, it is healthy and reasonable.

Community standards do not maintain themselves; they are upheld by participants actively and publicly enforcing them. Do not cry that all criticism should be sent privately; it does not work that way. When someone comments that your statement is incorrect or offers a different opinion, insisting that you are being personally attacked is of no use; these are all loser attitudes.

There are also other hacker forums misled by excessive politeness that prohibit participants from posting any messages that criticize others' posts and claim If you do not want to help users, just shut up. This results in thoughtful participants leaving in droves, and it only turns into meaningless chatter and useless technical forums.

Exaggerating, you have to choose between friendliness (in the above manner) or usefulness. Pick one.

Remember: when a hacker tells you that 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, it is easier to ignore you and filter you out of their lives. If you cannot manage to be thankful, at least show a little dignity; do not wail loudly, and do not expect others to treat you like a fragile doll just because you are a dramatic, super-sensitive soul and think you are entitled to special treatment.

Sometimes, even if you did not mess up (or only messed up in their imagination), some people will attack you for no reason. In such cases, complaining will really mess things up.

These troublemakers are either incompetent people who think they are experts or psychological experts testing whether you will mess up. Other readers will either ignore them or deal with them in their own way. You do not need to worry about these troublemakers getting themselves into trouble.

Also, do not let yourself get drawn into a flame war; it is best to ignore most flame wars—of course, as long as you verify they are just flame wars and do not point out where you messed up, nor cleverly hide the actual answer to the problem within them (which is also possible).

Questions You Shouldn't 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 the Bass-o-matic file converter?

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

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

Question: My program is not 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—on the other end of the search engine. Goodness! Is there 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 completely ignorant of X and confused about the problem Y aims to solve, and has their thinking constrained by a specific situation. It is best to ignore such people until they figure out their problems.

Question: How do I set my shell prompt?

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

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

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

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

Answer: This is not 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. My usual response when seeing such questions is one of the following three:

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 Windows-related questions; just do not be surprised if the problem is due to the Windows operating system rather than the program itself, as Windows is generally so bad that this statement is usually true.

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

Answer: You might be the first person to notice a significant flaw in a system call or library file that has been repeatedly used by thousands of users; more likely, you are completely unfounded. Extraordinary claims require extraordinary evidence; when you make such claims, you must have a clear and detailed defect documentation 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 problem relates 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 problem in detail. Before doing so, carefully search 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 this shows you are a despicable person; seeking a hacker's help shows you are an idiot!

Good Questions vs. Stupid Questions#

Finally, I will illustrate how to ask smart questions by providing examples; two ways of asking the same question are placed together, one is stupid, and the other is 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 does not compile. Why is it so bad?

This arrogant asker 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 asker has indicated the environment, read the FAQ, listed the errors, and has not pushed the responsibility for the problem onto others; their question deserves attention.

Stupid Question

My motherboard has a problem; who can help me?

A hacker's typical response to this kind of question is: Sure, 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 guy, from another perspective, is worth answering. He shows the ability to solve problems rather than waiting for answers to fall from the sky.

In the last question, note the subtle yet important difference between Tell me the answer and Give me insights on what further diagnostic work I should do.

In fact, the latter question originated from a real inquiry on 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 participate and be engaged. I demonstrated that I had the same capabilities as them and invited them to explore with me. By telling them the detours I had taken to avoid wasting their time, I also showed 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 are, in some ways, knowledgeable but lack warmth; I believe he was right. If I had asked like a beggar, regardless of 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.

If You Don't Get an Answer#

If you still do not get an answer, do not assume we think we cannot help you. Sometimes, it is just that the person who sees your question does not know the answer. No response does not mean you have been ignored, although it is undeniable that this difference is hard to distinguish.

In general, simply reposting the question is a very bad idea. This will be seen as meaningless noise. Be a little patient; the person who knows the answer to your question may live in a different time zone, may be sleeping, or your question may not have been organized well from the start.

You can seek help through other channels, which are often more suitable for beginners' needs.

There are many online and local user groups composed of enthusiastic software enthusiasts (even if they may never have personally written any software). People often form such groups to help each other and assist newcomers.

Additionally, you can seek help from many commercial companies, regardless of their size. Do not feel frustrated that you have to pay for help! After all, if your car's engine cylinder head gasket blew—completely possible—you would still have to take it to a repair shop and pay for the repairs. Even if the software did not cost you a penny, you cannot expect technical support to always be free.

For widely used software like Linux, each developer corresponds to at least thousands of users. It is simply impossible for one person to handle help requests from thousands of users. Remember, even if you have to pay for this assistance, compared to similar software you have purchased, what you pay is negligible (usually, the technical support costs for closed-source software are much higher than for open-source software and are not as rich in content).

How to Answer Questions Better#

Be Kind. The stress 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 sincerely 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 reply is worse than nothing; do not give others misleading directions just because it is fun to sound like an expert. Be humble and honest, setting a good example for both the asker and your peers.

If you cannot help, do not hinder them. Do not joke about actual steps, as this may ruin the user's setup—some poor fool may take it as a real command.

Ask probing questions to elicit more details. If you do well, the asker can learn something—you can too. Try to turn stupid questions into good questions; do not forget we were all newbies once.

While it is legitimate to complain about lazy people with an RTFM, it is better to point out where the documentation 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 asker has already researched deeply and indicated they have tried X, Y, Z, A, B, C but have not succeeded, responding 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 the problems. When replying to a good question, ask yourself, How can I modify the relevant documentation or FAQ to avoid answering the same question again? Then send a patch to the documentation maintainers.

If you are answering after doing some research, show your work instead of just handing out the results. After all, Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime.

If you need basic knowledge about how personal computers, Unix systems, and networks work, refer to Unix System and Network Fundamentals.

When you release 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 Answer Questions Better, while Mikhail Ramendik provided some particularly valuable suggestions and improvements.