I found "How To Ask Questions The Smart Way". Everyone is welcome to browse it.
How To Ask Questions The Smart Way
D.H.Grand 2001
In the world of hackers, what kind of answer you get when you ask a technical question depends on the difficulty of digging out the answer, and also on the way you ask. This guide is intended to help you improve your questioning skills so you can get the answers you most want.
First you must understand that hackers only favor difficult tasks, or good questions that can stimulate their thinking. Otherwise, why would we be here? If you have a good question worth chewing over repeatedly, we will naturally be very grateful to you. Good questions are a stimulus, a gift; they can improve our understanding, and usually expose problems we had never realized or thought about before. To hackers, "Good question!" is heartfelt high praise.
Although hackers have a bad reputation for despising simple questions and being unfriendly, and sometimes it may seem that we are hostile toward newbies and toward the poorly informed, that is actually not the case.
We do not want to conceal our contempt for people who are unwilling to think, or who do not do what they should before asking. Such people only murder time--they only take and never give, consuming our time for no reason, time we could have spent on more interesting questions or on people more worth answering. We call such people "losers" (for historical reasons, we sometimes spell it "lusers"
.
To a large extent we are volunteers, taking time out of busy lives to answer questions, and we are often flooded with questions. So we mercilessly filter out some topics, especially abandoning those fellows who look like losers, in order to use time more efficiently to answer the questions of winners.
If you feel that our overly arrogant attitude makes you unhappy or wronged, you might as well put yourself in our position. We are not asking you to submit to us--in fact, most of us like fair exchange best of all. As long as you make a small effort to meet the minimum requirements, we will welcome you into our culture. But it makes no sense for us to help people who are unwilling to help themselves. If you cannot accept this kind of "discrimination", we suggest you spend some money and sign a technical support agreement with a commercial company instead; do not beg hackers for help.
If you decide to ask us for help, of course you do not want to be seen as a loser, much less become one of the losers. The best way to get an effective answer quickly is to ask like a winner -- smart, confident, with ideas for solving the problem, and only occasionally needing a little help on a specific issue.
(Comments for improving this guide are welcome. Please E-mail any suggestions to esr@thyrsus.com, however please note that this article is not a general guide to netiquette, and I usually reject suggestions that do not help obtain useful answers in technical forums.) (Of course, if you write Chinese, it is best to send it to DHGrand@hotmail.com;-)
= Before Asking =
Before asking a technical question by email, newsgroup, or chat room, check whether you have done the following:
1. Read through the manual and try to find the answer yourself.
2. Look for the answer in the FAQ (a well-maintained FAQ can include everything
.
3. Search the web (I personally recommend google~~~).
4. Ask friends around you who are skilled in this area.
When you ask your question, first explain what you have done before this; this will help establish your image: you are not a beggar trying to get something for nothing, and you are not willing to waste other people's time. If the questioner can learn something from the answer, we are more willing to answer his question.
Think it through and prepare your question. A hasty question can only get a hasty answer, or no answer at all. The more you show the effort you have put into solving the problem before seeking help, the more substantial help you can get.
Be careful not to ask the wrong question. If your question is based on a false assumption, J. Random Hacker will usually answer you with a meaningless literal interpretation, thinking "stupid question...", hoping that you will learn a lesson from the answer to the question (rather than the answer you wanted).
Never think you are entitled to an answer. You are not. After all, you have not paid anything for this service. You must "earn" an answer yourself, by asking a question with substance, an interesting question that stimulates thought--a question that makes a potential contribution to the community's experience, rather than merely passively demanding knowledge from others.
On the other hand, showing that you are willing to do something in the process of finding an answer is a very good start. "Who can give me a hint?", "What is missing in my example?", and "Where should I check?" are more likely to get replies than "Please post the exact procedure." Because you appear to have the ability and determination to complete it as long as someone points you in the right direction.
= How to Ask =
- Choose the forum carefully
Choose the place to ask carefully. If it is like the following, you are very likely to be ignored or regarded as a loser:
1. Posting your question in a completely unrelated forum
2. Posting very elementary questions in a forum that discusses advanced techniques; and vice versa
3. Cross-posting to too many different newsgroups
- Use precise wording, correct grammar, and correct spelling
We have found from experience that careless writers are usually also careless thinkers (I dare guarantee it). Answering careless people's questions is not worth it; we would rather spend our time elsewhere.
Correct spelling, punctuation, and capitalization are important.
More generally, if your question is written like you are semi-literate, you are very likely to be ignored.
If you ask in a forum using a language that is not your mother tongue, you may make minor spelling and grammar mistakes--but you must never be sloppy in thinking (that's right, we can tell the difference between the two)
- Use a meaningful and accurate subject title
In mailing lists or newsgroups, a subject title within about 50 characters is a golden opportunity to catch the attention of senior experts. Do not waste this opportunity with endless "help me" (let alone disgusting words like "save me!!!!!"
. Do not imagine you can move us with the degree of your pain. Do not use spaces instead of a description of the problem, even an extremely brief description.
Stupid question: Help! My laptop display is not working properly!
Smart question: Mouse cursor deformed under XFree86 4.1, Fooware MV1005 display chip.
If you raise a question in a reply, remember to modify the subject line to indicate that there is a question inside. A question that looks like "Re: test" or "Re: new bug" is hard to get enough attention. Also, quote and trim the previous text, leaving clues for new readers.
- Describe precisely, with plenty of information
1. Describe the symptoms carefully and clearly.
2. Provide the environment in which the problem occurs (machine configuration, operating system, application program, and anything else).
3. Explain how you researched and understood the problem before asking.
4. Explain what steps you took to solve it before asking.
5. List any recent hardware or software changes that may have an impact.
Try to imagine how a hacker would question you back, and give him the answers in advance when you ask.
Simon Tatham wrote an excellent short essay titled "How to Report Bugs Effectively". I strongly recommend that you read it too.
- More words are not the point
You need to provide precise and effective information. This does not mean simply dumping tons of error code or data completely into your question. If you have huge and complex test conditions, try to cut them down as small as possible.
Doing this has at least three uses. First, it shows that you have made an effort to simplify the problem, which can increase your chance of getting an answer; second, simplifying the problem increases your chance of getting a useful answer; third, in the process of refining your bug report, you may find the problem yourself or make a correction.
- State symptoms, not guesses
Telling hackers what you think caused the problem is not much help. (If your inference is so effective, would you still need to ask others for help?) Therefore, be sure you tell them the original symptoms, and do not add your own understanding and inferences. Let the hackers diagnose it.
Stupid question: I keep encountering SIG11 errors during kernel compilation. I suspect some flying wire is touching a trace on the motherboard. What is the best way to check this situation?
Smart question: My self-built K6/233 system, motherboard FIC-PA2007 (VIA Apollo VP2 chipset), 256MB Corsair PC133 SDRAM, repeatedly produces SIG11 errors during kernel compilation. This happens after 20 minutes from power-on; it has never happened within the first 20 minutes after power-on. Rebooting does not help, but shutting down for a night lets it work another 20 minutes. All memory has been replaced, with no effect. The typical compile log for the relevant part is as follows...。
- List symptoms in chronological order
The clues most helpful for finding the problem are often the series of operations before the problem occurs. Therefore your description should include the steps of operation and the computer's responses, until the problem appears.
If your description is long (more than four paragraphs), it helps to briefly describe the problem at the beginning, then describe it in chronological order. This way hackers will know what to look for in your description.
- Understand what you want to ask
Open-ended questions are nearly endless time black holes. The people most capable of giving you useful answers are also the busiest people (they are busy because they do most of the work themselves). Such people are not very interested in uncontrolled time black holes, so it can also be said that they are not very interested in open-ended questions.
If you clearly state what you need the respondent to do (provide suggestions, send a piece of code, check your patch, or something else), you are most likely to get a useful answer. This sets an upper limit on time and effort, making it easier for the respondent to concentrate on helping you, and it is very effective. To understand the world experts live in, think of professional skill as an abundant resource, while reply time is a scarce resource. The less time it takes to solve your problem, the more likely you are to pry an answer from busy experts.
Therefore, optimizing the structure of the question and minimizing the time experts need to solve it will help a great deal--this is usually different from simplifying the question. Therefore, asking "I want to understand X better, can you give me some hints?" is usually better than asking "Can you explain X?" If your code does not work, it is much wiser to ask what is wrong with it than to ask someone else to modify it for you.
- Do not ask questions you should solve yourself
Hackers are always good at distinguishing which problems should be solved by you yourself; because most of us have solved such problems ourselves. Likewise, these problems must be handled by you, and you will learn from them. You may ask for hints, but do not ask for a complete solution.
- Remove meaningless questions
Do not end a question with meaningless words such as "Can anyone help me?" or "Is there an answer?". First: if your description of the problem is not very suitable, asking this is even more superfluous. Second: because asking this is superfluous, hackers will be very annoyed with you--and usually express their contempt with a logically correct answer, such as: "Yes, someone can help you" or "No, there is no answer".
- Humility never hurts, and often helps a lot
Be polite, and use "please" and "thanks in advance" more. Let everyone know that you are grateful for the time they spend providing help voluntarily. However, if you have many problems that cannot be solved, politeness will increase your chance of getting useful answers.
(We noticed that since this guide was published, the only serious defect feedback received from senior hackers was about thanking in advance. Some hackers feel that the implication of "thanks in advance" is that you will not thank anyone afterwards. Our suggestion is: thank them both times.)
- After the problem is solved, add a brief explanation
After the problem is solved, send a note to everyone who helped you, letting them know how the problem was solved and thanking them again. If the problem attracted wide attention in a newsgroup or mailing list, you should post a follow-up note there. The follow-up note does not need to be long or deep; a simple sentence like "Hello, it turned out to be a network cable problem! Thanks everyone--Bill" is better than saying nothing. In fact, unless the conclusion is really technically substantial, a short and cute summary is better than a long academic paper. Explain how the problem was solved, but there is no need to retell the process of solving the problem. Besides showing courtesy and giving feedback, this kind of follow-up helps others search the mailing list/newsgroup/forum for the complete solution that helped you, which may also be useful to them. Finally (at least?), this follow-up helps everyone who provided help gain a sense of satisfaction from it. If you are not an old hand or a hacker yourself, then believe us: this feeling is very important to the mentors or experts you asked for help. Problems left unresolved for a long time are discouraging; hackers long to see problems solved. Good people get good returns. Satisfy their longing, and you will taste the sweetness the next time you post a new question.
- Still don't understand
If you do not really understand the answer, do not immediately ask the other person to explain. Just as when you previously tried to solve the problem yourself (using the manual, FAQ, the web, experts around you), try to understand it. If you really need the other person to explain, remember to show that you have already learned something. For example, if I answer you: "It looks like zEntry is blocked; you should clear it first.", then: a very bad follow-up question: "What is zEntry?" A smart way to ask would be: "Oh~~~ I read the help, but zEntry is mentioned only in the -z and -p parameters, and neither explains it clearly :< do you mean one of these two? Or did I miss something?"
= Think Twice Before Asking =
The following are several classic stupid questions, and what hackers are thinking when they refuse to answer:
Question: Where can I find program X?
Question: My program/configuration/SQL statement does not work
Question: My Windows has a problem, can you help me?
Question: I have a problem installing Linux (or X), can you help me?
Question: How can I crack the root account/steal OP privileges/read other people's mail?
Question: Where can I find program X?
Answer: In the same place I found it, idiot--at the other end of a search engine. God! Are there still people who can't use Google?
Question: My program (configuration, SQL statement) does not work
Answer: This does not count as a question. I am not interested in finding out what your real problem is--if I have to ask you twenty questions to find it--I have more interesting things to do.
When I see this kind of question, my reaction is usually one of the following three:
1. Do you have anything else to add?
2. Too bad, hope you can handle it.
3. What the hell does this have to do with me?
Question: My Windows has a problem, can you help me?
Answer: Sure, throw away that Micro$oft garbage and switch to Linux.
Question: I have a problem installing Linux (or X), can you help me?
Answer: No, I can only find the fault by working on your computer in person. Go find your local Linux user group for hand-holding guidance (you can find a list of user groups here).
Question: How can I crack the root account/steal OP privileges/read other people's mail?
Answer: Wanting to do that shows you are a despicable person; wanting to find a hacker to help you shows you are an idiot!
= Good Questions, Bad Questions =
Finally, I will give some examples to show how to ask questions smartly; two ways of asking the same question are placed together, one stupid, and the other wise.
Stupid question: Where can I find information about Foonly Flurbamatic?
// This way of asking just wants an answer like "STFW".
Smart question: I searched Google for "Foonly Flurbamatic 2600", but did not find useful results. Who knows where to find information on programming this device?
// This question has already STFWed; it looks like he has really run into trouble.
Stupid question: The source code I got from the FOO project cannot compile. Why is it so lousy?
// He thinks it is all someone else's fault, this arrogant fellow
Smart question: The FOO project code cannot compile under Nulix 6.2. I have read the FAQ, but it does not mention Nulix-related issues. Here is the log of my compile process. Is there something I am doing wrong?
// He explained the environment, read the FAQ, pointed out the error, and did not put the responsibility for the problem on others. This fellow is worth paying attention to.
Stupid question: My motherboard has a problem, who will help me?
// The average hacker's answer to this sort of question is usually: "Okay, do you want me to pat your back and change your diaper too?", and then press the delete key.
Smart question: I tried X, Y, and Z on the S2464 motherboard, but they had no effect, and I also tried A, B, and C. Please note the strange phenomenon when I tried C. Obviously shrinkage occurred in sideband transmission, but the result is unexpected. What are the usual causes of sideband leakage on multiprocessor motherboards? Who has a good idea what tests I should do next to find the problem?
// This fellow, looked at from another angle, is worth answering. He has shown the ability to solve problems, rather than sitting and waiting for answers to fall from the sky.
In the last question, note the subtle but important difference between "tell me the answer" and "give me insight and point out what diagnostic work I should do next". In fact, the latter question comes from a real question on the Linux kernel mailing list in August 2001. I (Eric) was the person who asked the question. I observed this unexplained lockup phenomenon on a Tyan S2464 motherboard, and list members provided important information for solving that problem.
Through the way I asked, I gave everyone something worth pondering; I made it easy for people to participate and be drawn in. I showed that I had ability equal to theirs and invited them to discuss it with me. I told them the wrong paths I had taken to avoid them wasting time again, which is a kind of respect for the value of other people's time. Later, when I thanked everyone and praised the way this procedure (referring to the discussion on the mailing list -- translator's note) worked very well, a Linux kernel mailing list (lkml) member said that the problem was solved not because I was a "celebrity" on the list, but because I asked in the right way. We hackers, from a certain angle, are fellows rich in knowledge but lacking a human touch; I believe he was right. If I had asked like a beggar, no matter who I was, I would certainly have annoyed some people or been ignored by them. He suggested that I write down this matter and give some guidance to the people writing this guide.
= What If You Cannot Find an Answer =
If you still do not get an answer, please do not think we feel unable to help you. Sometimes it is just that the people who see your question do not know the answer. No response does not mean you are being ignored, although it is undeniable that this difference is hard to distinguish.
Generally speaking, simply posting the question repeatedly is a very bad idea. This will be seen as meaningless noise.
You can obtain help through other channels, and these channels are usually more suitable for beginners' needs. There are many online and local user groups, made up of enthusiastic software lovers (even if they may never have personally written any software). Usually people form such groups to help each other and help newcomers.
In addition, you can seek help from many commercial companies, whether large or small (Red Hat and LinuxCare are two of the most common examples). Do not be frustrated that you have to pay for help! After all, if the cylinder gasket in your car engine blows--which is entirely possible--you still have to send it to a repair shop and pay for repairs. Even if the software did not cost you a penny, you cannot demand that technical support always be free.
For popular software, such as Linux, every developer will have at least tens of thousands of users. It is simply impossible for one person to handle support calls from tens of thousands of users. You should know that even if you have to pay for help, what you pay is insignificant compared with having to buy similar software (usually technical support for closed-source software is much more expensive than for open-source software, and the content is not as rich).
Copyright (C) 2001 by Eric S. Raymond
Chinese edition Copyleft 2001 by D.H.Grand(nOBODY/Ginux)
English edition: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Thanks to Eric's patient guidance and permission, this article was able to be completed and published,
The copyright of the English edition of this guide belongs to Eric Steven Raymond,
The copyright of the Chinese edition belongs to D.H.Grand
--------------------------------------------------------------------------------
"If we could search for information more properly, we would truly have already changed the world."
DigestI
StickyII
