DigestI
StickyII
### How To Ask Questions The Smart Way
Asking Questions Wisely (Part 1)
Copyright (C) 2001 by Eric S. Raymond
Chinese version Copyleft 2001 by D.H.Grand(nOBODY/Ginux)
English version: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Thanks to Eric's patient guidance and permission, this article was completed and published. The English version of this guide is copyrighted by Eric Steven Raymond,
and the Chinese version is copyrighted by D.H.Grand.
Table of Contents
Introduction
Before Asking Questions
How to Ask Questions
Choose the Forum Cautiously
Try to Use Mailing Lists
Use Appropriate Words, Correct Grammar, and No Spelling Errors
Send Questions in a Readable Format
Use a Descriptive and Accurate Title
Describe Precisely and Provide Abundant Information
Don't Talk Too Much
Only State Symptoms, Not Guesses
List Symptoms in Chronological Order
Don't Ask for Private Responses
Know What You Want to Ask
Don't Ask Questions That Should Be Solved by Yourself
Remove Meaningless Questions
Humility Never Does Harm and Often Helps a Lot
Add a Brief Explanation After the Problem is Solved
How to Understand Answers
RTFM and STFW: Don't Bother Me
Still Don't Understand
Facing Rudeness
Never Be Like a Loser
Think Twice Before Asking
Good Questions, Bad Questions
What to Do If You Can't Find the Answer
====
Introduction
====
In the hacker world, what kind of answer can you get when you ask a technical question? It depends on the difficulty of digging out the answer, and also on the way you ask the question. This guide is designed to help you improve your questioning skills to get the answer you most want.
First of all, you must understand that hackers only prefer difficult tasks or good questions that can stimulate their thinking. If not, why are we here? If you have a good question worth our repeated pondering, we will be very grateful to you. A good question is an inspiration, a generous gift, which can improve our understanding and usually expose problems we never realized or thought about before. For hackers, "Good question!" is a heartfelt great compliment.
Although hackers have a bad reputation for despising simple questions and being unfriendly, sometimes it may seem that we are hostile to novices and those with poor knowledge, but that's not the case.
We don't want to hide our contempt for such people - those who are unwilling to think or don't do what they should do before asking questions. Such people will only kill time - they only want to take, never give, and waste our time needlessly, while we could have spent the time on more interesting questions or more worthy people. We call such people "lusers" (due to historical reasons, we sometimes spell it as "lusers"
.
We also know that many people just want to use the software we write and are not interested in technical details. For most people, the computer is just a tool, a means to an end; they have more important things to do and a more important life to live. We understand this and don't expect everyone to be interested in the technical questions that drive us crazy. However, our style of answering questions is aimed at such a group of people - those who are interested and willing to actively participate in solving the problem. This will not change and should not change; if it changes, we will lose the efficiency we are proud of.
We are largely volunteers, taking time out of our busy lives to answer questions, and are often overwhelmed by questions. So we ruthlessly filter out some topics, especially those that seem 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 uncomfortable and wronged, you might as well put yourself in our shoes. We didn't ask you to submit to us - in fact, most of us like fair deals the most. As long as you make a little effort to meet the minimum requirements, we will welcome you into our culture. But it's meaningless to let us help those who are not willing to help themselves. If you can't accept this "discrimination", we suggest that you spend some money to find a commercial company to sign a technical support agreement, don't beg hackers for help.
If you decide to ask us for help, of course, you don't want to be regarded as a loser, and even less want to be a member of losers. The best way to get an effective answer immediately is to ask like a winner - smart, confident, with ideas for solving the problem, just occasionally needing a little help on a specific question.
(Welcome to put forward improvement suggestions for this guide. Any suggestions please send an email to esr@thyrsus.com, however, please note that this article is not a general guide to netiquette, and I usually refuse suggestions that are not helpful for getting useful answers in technical forums.)
(Of course, if you write in Chinese, it's better to send it to DHGrand@hotmail.com;-)
========
Before Asking Questions
========
Before asking a technical question via email, newsgroup, or chat room, check if you have done:
1. Read the manual thoroughly and try to find the answer by yourself.
2. Find the answer in the FAQ (a well-maintained FAQ can cover everything
.
3. Search on the Internet (personally recommend google~~~).
4. Ask your friends who are good at this around you.
When you ask a question, first explain what you have done before; this will help establish your image: you are not a beggar who wants to get something for nothing and is not willing to waste others' time. It's even better if you can explain what you have learned from these operations. If the questioner can learn something from the answer, we are more willing to answer his question.
Thoughtfully prepare your question. Hasty questioning can only get hasty answers or no answers at all. The more you show the efforts you have made to solve the problem before seeking help, the more substantial help you will get.
Be careful not to ask the wrong question. If your question is based on a wrong assumption, an ordinary hacker (J. Random Hacker) will usually answer you with a meaningless literal explanation, thinking "stupid question...", hoping that you will learn a lesson from the answer to the question (rather than the answer you want).
Never think you are entitled to an answer, you don't have this entitlement. After all, you haven't paid any remuneration for this service. You have to "earn" an answer by asking a meaningful, interesting, and thought-stimulating question - a question that has a potential contribution to the community's experience, rather than just passively asking for knowledge from others - to earn this answer.
On the other hand, showing that you are willing to do something in the process of finding the answer is a very good start. "Can anyone give some hints?" "What's missing in my example?" and "What should I check?" are easier to get a response than "Please post the exact process". Because you seem to have the ability and determination to complete it as long as someone points out the correct direction.
========
How to Ask Questions
========
------------
Choose the Forum Cautiously
------------
Be careful to choose the place to ask questions. If it's described as follows, you are likely to be ignored or regarded as a loser:
1. Post your question in an irrelevant forum
2. Post a very basic question in a forum discussing advanced skills; and vice versa
3. Post cross in too many different newsgroups
Hackers usually cut off questions asked in the wrong place to protect their community from being flooded with a large number of irrelevant posts. You don't want your post to be cut off like this.
In general, it's easier to get useful answers by sending the question to a carefully selected public forum than to a closed small circle. There are several reasons for this phenomenon, one of which is that there are more potential question answerers in the public forum; another reason is that there are more listeners in the public forum. Hackers are more willing to let as many people as possible - rather than a limited one or two - benefit from the answer.
----------------
Try to Use Mailing Lists
----------------
If a project has its own development mailing list, send the question to this mailing list instead of a certain developer, even if you know very well who can answer your question best. Carefully check the project documentation and project homepage to find the email list address of this project. The reasons for doing this are fourfold:
1. Any good question worth asking a certain developer is worth asking the entire development community. Conversely, if you think this question is not worth mentioning in the mailing list, there is no reason to harass any developer with it.
2. Asking questions in the mailing list can share the workload of developers. A certain developer (especially when he is the project leader) may be too busy to answer your question.
3. Most mailing lists have historical archives and can be retrieved in search engines. People can find your question and answer from them without asking again and again in the list.
4. If a certain question is often asked, developers can improve the documentation or software accordingly to reduce users' confusion. But if the question is always asked privately, no one will have an overall grasp of it.
If you can't find the email list address of the project and can only see the maintainer of the project, then write to the maintainer. In this case, don't think that the mailing list doesn't exist. Write in your letter that you have tried your best to find it and still can't find the mailing list. Also indicate that you don't mind transferring this message to others. (Most people think that private letters should be private, even if there is nothing to keep secret. Allowing your message to be forwarded to others gives the recipient a choice in handling your email.)
----------------------------
Use Appropriate Words, Correct Grammar, and No Spelling Errors
----------------------------
We have found from experience that careless writers are usually also sloppy thinkers (I bet). It's not worth answering the questions of careless people, and we would rather spend time elsewhere.
Therefore, it's very important to clearly and fully express your question. If you find it troublesome to do so, we will be lazy to pay attention to you. Pay attention to refining your words. You don't have to use rigid and formal language - in fact, the values of hacker culture are informal. Use slang and humorous language accurately, but don't misuse them; you must show that you are thinking and paying attention.
Correct spelling, punctuation, and capitalization are important. Don't confuse "its" and "it''s" or "loose" and "lose". Don't use all uppercase forms, which is regarded as rude shouting (all lowercase is not much better either, because it will make reading difficult. Alan Cox can use all lowercase, but you can't).
More generally, if your question is written like a semi-literate, you are very likely to be ignored. If it's written like a pj enthusiast or a script kiddie (someone who only uses ready-made tools to make trouble), it's definitely asking for trouble, and you can be sure that you will get nothing but ruthless resistance (or, the best result is to get a lot of sarcastic "help".
If you are asking questions in a forum in a non-native language, you can make some small mistakes in spelling and grammar - but never be sloppy in thinking (yes, we can distinguish the two). In addition, unless you are exactly sure what language your answerer will use, please use English. Hurried hackers usually simply skip questions they can't understand, and English is the working language on the Internet. Using English can reduce the risk that your question is discarded without being read.
------------------
Send Questions in a Readable Format
------------------
If you make your question difficult to read and understand artificially, it will be easier to be ignored. Therefore, you should:
1. Use plain text email and don't use HTML (it's not difficult to turn off HTML).
2. Usually, you can attach MIME attachments, but there must be real content (such as attached source files or patches), not just the file template generated by your email client (such as a copy of your email).
3. Don't put all the questions in one long paragraph that keeps wrapping lines. (This will make it difficult for the person replying to answer part of the questions. Even if all questions can be answered, I would rather have them one by one in an orderly manner. It's very possible that the recipient can only read the letter on a text display with a width of 80 characters, so set the line wrapping mode accordingly within 80 characters.
4. Don't send in MIME Quoted-Printable encoding in an English forum; this encoding format is very necessary for languages that cannot be expressed in ASCII code, but many email agents don't support it. At this time, full of "=20" symbols split the text, which is not only ugly but also distracting.
5. Never expect hackers to be willing to read files in closed proprietary formats, such as Microsoft Word format. Most hackers' reaction to this is like you piling up hot pig manure on the doorstep steps (meaning no one will step into your door - translator's note).
6. If you send an email through a computer installed with Windows, turn off Microsoft's stupid "smart quotes" function. This can save you from having garbage characters in your email.
----------------------------
Use a Descriptive and Accurate Title
----------------------------
In the mailing list or newsgroup, the subject title within about 50 words is the golden opportunity to catch the attention of senior experts. Don't waste this opportunity with wordy "Help me" (let alone the annoying words like "Help!!!". Don't try to move us with the degree of your pain, and don't use spaces instead of the description of the question, even if it's extremely short.
Stupid question:
Help! My laptop can't display normally!
Smart question:
Mouse cursor distorted under XFree86 4.1, display chip of Fooware MV1005.
If you raise a question in the reply, remember to modify the content title to indicate that there is a question in it. A question that looks like "Re: Test" or "Re: New bug" is difficult to attract enough attention. In addition, quote and cut the previous content to leave clues for new readers.
------------------
Describe Precisely and Provide Abundant Information
------------------
1. Describe the symptoms carefully and clearly.
2. Provide the environment where the problem occurs (machine configuration, operating system, application program and anything else).
3. Explain how you studied and understood this problem before asking the question.
4. Explain what steps you took to solve it before asking the question.
5. List the recent hardware and software changes that may have an impact.
Try to imagine how a hacker would ask you back and pre-answer him when asking the question.
Simon Tatham has written an excellent short article titled "How to Report Bugs Effectively". It's highly recommended that you also read it.
--------
Don't Talk Too Much
--------
You need to provide precise and effective information. This doesn't mean that you simply dump tons of error codes or data completely into your question. If you have a huge and complex test condition, try to cut it as small as possible.
There are at least three uses of doing this. First, it shows that you have made efforts 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, maybe you can find the problem or make a correction by yourself.
------------------
Only State Symptoms, Not Guesses
------------------
It's not helpful to tell hackers how you think the problem is caused. (If your inference is so effective, why do you need to ask others for help?) Therefore, make sure you tell them the symptoms of the problem exactly, without adding your own understanding and inference. Let hackers diagnose it.
Stupid question:
I keep encountering SIG11 errors in kernel compilation. I suspect that a flying wire is connected to the trace on the mainboard. What's the best way to check this situation?
Smart question:
I have a self-made K6/233 system, the mainboard is FIC-PA2007 (VIA Apollo VP2 chipset), 256MB Corsair PC133 SDRAM. I keep getting SIG11 errors in kernel compilation. This situation occurs frequently after 20 minutes of booting, and never occurs within the first 20 minutes after booting. Restarting doesn't help, but shutting down for a night and then it can work for 20 minutes again. All memories have been replaced, but it's of no effect. The typical compilation record of the relevant part is as follows...
------------------
List Symptoms in Chronological Order
------------------
The most helpful clue for finding the problem is often a series of operations before the problem occurs. Therefore, your description should include the operation steps and the computer's reaction until the problem occurs. In the case of command line operations, saving an operation record (for example, using a script tool) and citing about 20 relevant commands will be very helpful.
If the crashing program has a diagnostic option (for example, use -v to switch to detailed mode), try to carefully consider choosing the option to add useful debugging information in the operation record.
If your description is long (more than four paragraphs), it will be helpful to briefly describe the problem at the beginning and then elaborate in chronological order. Then hackers know what to look for in your description.
--------------
Don't Ask for Private Responses
--------------
Hackers think that the process of solving the problem should be open and transparent. As long as any more insightful person notices that the answer is imperfect or incorrect, this initial answer can and should be corrected. At the same time, the answerer is rewarded as he is noticed and accepted by everyone through his ability and knowledge.
If you ask for a private answer from the other party, this not only disrupts the entire process but also the reward system. Don't mention this requirement. It's the right of the answerer to choose whether to answer privately - if he chooses to do so, it's usually because he thinks the answer is too obvious or has a bad public impact and others won't be interested.
There is only a limited exception: if you expect to receive a large number of similar responses, you can say: "Send the answer to me, and I will summarize it." Rescuing the mailing list or newsgroup from a large number of repeated posts is very gentlemanly - but please remember to fulfill your promise about summarizing.
Asking Questions Wisely (Part 1)
Copyright (C) 2001 by Eric S. Raymond
Chinese version Copyleft 2001 by D.H.Grand(nOBODY/Ginux)
English version: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Thanks to Eric's patient guidance and permission, this article was completed and published. The English version of this guide is copyrighted by Eric Steven Raymond,
and the Chinese version is copyrighted by D.H.Grand.
Table of Contents
Introduction
Before Asking Questions
How to Ask Questions
Choose the Forum Cautiously
Try to Use Mailing Lists
Use Appropriate Words, Correct Grammar, and No Spelling Errors
Send Questions in a Readable Format
Use a Descriptive and Accurate Title
Describe Precisely and Provide Abundant Information
Don't Talk Too Much
Only State Symptoms, Not Guesses
List Symptoms in Chronological Order
Don't Ask for Private Responses
Know What You Want to Ask
Don't Ask Questions That Should Be Solved by Yourself
Remove Meaningless Questions
Humility Never Does Harm and Often Helps a Lot
Add a Brief Explanation After the Problem is Solved
How to Understand Answers
RTFM and STFW: Don't Bother Me
Still Don't Understand
Facing Rudeness
Never Be Like a Loser
Think Twice Before Asking
Good Questions, Bad Questions
What to Do If You Can't Find the Answer
====
Introduction
====
In the hacker world, what kind of answer can you get when you ask a technical question? It depends on the difficulty of digging out the answer, and also on the way you ask the question. This guide is designed to help you improve your questioning skills to get the answer you most want.
First of all, you must understand that hackers only prefer difficult tasks or good questions that can stimulate their thinking. If not, why are we here? If you have a good question worth our repeated pondering, we will be very grateful to you. A good question is an inspiration, a generous gift, which can improve our understanding and usually expose problems we never realized or thought about before. For hackers, "Good question!" is a heartfelt great compliment.
Although hackers have a bad reputation for despising simple questions and being unfriendly, sometimes it may seem that we are hostile to novices and those with poor knowledge, but that's not the case.
We don't want to hide our contempt for such people - those who are unwilling to think or don't do what they should do before asking questions. Such people will only kill time - they only want to take, never give, and waste our time needlessly, while we could have spent the time on more interesting questions or more worthy people. We call such people "lusers" (due to historical reasons, we sometimes spell it as "lusers"
. We also know that many people just want to use the software we write and are not interested in technical details. For most people, the computer is just a tool, a means to an end; they have more important things to do and a more important life to live. We understand this and don't expect everyone to be interested in the technical questions that drive us crazy. However, our style of answering questions is aimed at such a group of people - those who are interested and willing to actively participate in solving the problem. This will not change and should not change; if it changes, we will lose the efficiency we are proud of.
We are largely volunteers, taking time out of our busy lives to answer questions, and are often overwhelmed by questions. So we ruthlessly filter out some topics, especially those that seem 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 uncomfortable and wronged, you might as well put yourself in our shoes. We didn't ask you to submit to us - in fact, most of us like fair deals the most. As long as you make a little effort to meet the minimum requirements, we will welcome you into our culture. But it's meaningless to let us help those who are not willing to help themselves. If you can't accept this "discrimination", we suggest that you spend some money to find a commercial company to sign a technical support agreement, don't beg hackers for help.
If you decide to ask us for help, of course, you don't want to be regarded as a loser, and even less want to be a member of losers. The best way to get an effective answer immediately is to ask like a winner - smart, confident, with ideas for solving the problem, just occasionally needing a little help on a specific question.
(Welcome to put forward improvement suggestions for this guide. Any suggestions please send an email to esr@thyrsus.com, however, please note that this article is not a general guide to netiquette, and I usually refuse suggestions that are not helpful for getting useful answers in technical forums.)
(Of course, if you write in Chinese, it's better to send it to DHGrand@hotmail.com;-)
========
Before Asking Questions
========
Before asking a technical question via email, newsgroup, or chat room, check if you have done:
1. Read the manual thoroughly and try to find the answer by yourself.
2. Find the answer in the FAQ (a well-maintained FAQ can cover everything
. 3. Search on the Internet (personally recommend google~~~).
4. Ask your friends who are good at this around you.
When you ask a question, first explain what you have done before; this will help establish your image: you are not a beggar who wants to get something for nothing and is not willing to waste others' time. It's even better if you can explain what you have learned from these operations. If the questioner can learn something from the answer, we are more willing to answer his question.
Thoughtfully prepare your question. Hasty questioning can only get hasty answers or no answers at all. The more you show the efforts you have made to solve the problem before seeking help, the more substantial help you will get.
Be careful not to ask the wrong question. If your question is based on a wrong assumption, an ordinary hacker (J. Random Hacker) will usually answer you with a meaningless literal explanation, thinking "stupid question...", hoping that you will learn a lesson from the answer to the question (rather than the answer you want).
Never think you are entitled to an answer, you don't have this entitlement. After all, you haven't paid any remuneration for this service. You have to "earn" an answer by asking a meaningful, interesting, and thought-stimulating question - a question that has a potential contribution to the community's experience, rather than just passively asking for knowledge from others - to earn this answer.
On the other hand, showing that you are willing to do something in the process of finding the answer is a very good start. "Can anyone give some hints?" "What's missing in my example?" and "What should I check?" are easier to get a response than "Please post the exact process". Because you seem to have the ability and determination to complete it as long as someone points out the correct direction.
========
How to Ask Questions
========
------------
Choose the Forum Cautiously
------------
Be careful to choose the place to ask questions. If it's described as follows, you are likely to be ignored or regarded as a loser:
1. Post your question in an irrelevant forum
2. Post a very basic question in a forum discussing advanced skills; and vice versa
3. Post cross in too many different newsgroups
Hackers usually cut off questions asked in the wrong place to protect their community from being flooded with a large number of irrelevant posts. You don't want your post to be cut off like this.
In general, it's easier to get useful answers by sending the question to a carefully selected public forum than to a closed small circle. There are several reasons for this phenomenon, one of which is that there are more potential question answerers in the public forum; another reason is that there are more listeners in the public forum. Hackers are more willing to let as many people as possible - rather than a limited one or two - benefit from the answer.
----------------
Try to Use Mailing Lists
----------------
If a project has its own development mailing list, send the question to this mailing list instead of a certain developer, even if you know very well who can answer your question best. Carefully check the project documentation and project homepage to find the email list address of this project. The reasons for doing this are fourfold:
1. Any good question worth asking a certain developer is worth asking the entire development community. Conversely, if you think this question is not worth mentioning in the mailing list, there is no reason to harass any developer with it.
2. Asking questions in the mailing list can share the workload of developers. A certain developer (especially when he is the project leader) may be too busy to answer your question.
3. Most mailing lists have historical archives and can be retrieved in search engines. People can find your question and answer from them without asking again and again in the list.
4. If a certain question is often asked, developers can improve the documentation or software accordingly to reduce users' confusion. But if the question is always asked privately, no one will have an overall grasp of it.
If you can't find the email list address of the project and can only see the maintainer of the project, then write to the maintainer. In this case, don't think that the mailing list doesn't exist. Write in your letter that you have tried your best to find it and still can't find the mailing list. Also indicate that you don't mind transferring this message to others. (Most people think that private letters should be private, even if there is nothing to keep secret. Allowing your message to be forwarded to others gives the recipient a choice in handling your email.)
----------------------------
Use Appropriate Words, Correct Grammar, and No Spelling Errors
----------------------------
We have found from experience that careless writers are usually also sloppy thinkers (I bet). It's not worth answering the questions of careless people, and we would rather spend time elsewhere.
Therefore, it's very important to clearly and fully express your question. If you find it troublesome to do so, we will be lazy to pay attention to you. Pay attention to refining your words. You don't have to use rigid and formal language - in fact, the values of hacker culture are informal. Use slang and humorous language accurately, but don't misuse them; you must show that you are thinking and paying attention.
Correct spelling, punctuation, and capitalization are important. Don't confuse "its" and "it''s" or "loose" and "lose". Don't use all uppercase forms, which is regarded as rude shouting (all lowercase is not much better either, because it will make reading difficult. Alan Cox can use all lowercase, but you can't).
More generally, if your question is written like a semi-literate, you are very likely to be ignored. If it's written like a pj enthusiast or a script kiddie (someone who only uses ready-made tools to make trouble), it's definitely asking for trouble, and you can be sure that you will get nothing but ruthless resistance (or, the best result is to get a lot of sarcastic "help"
. If you are asking questions in a forum in a non-native language, you can make some small mistakes in spelling and grammar - but never be sloppy in thinking (yes, we can distinguish the two). In addition, unless you are exactly sure what language your answerer will use, please use English. Hurried hackers usually simply skip questions they can't understand, and English is the working language on the Internet. Using English can reduce the risk that your question is discarded without being read.
------------------
Send Questions in a Readable Format
------------------
If you make your question difficult to read and understand artificially, it will be easier to be ignored. Therefore, you should:
1. Use plain text email and don't use HTML (it's not difficult to turn off HTML).
2. Usually, you can attach MIME attachments, but there must be real content (such as attached source files or patches), not just the file template generated by your email client (such as a copy of your email).
3. Don't put all the questions in one long paragraph that keeps wrapping lines. (This will make it difficult for the person replying to answer part of the questions. Even if all questions can be answered, I would rather have them one by one in an orderly manner
. It's very possible that the recipient can only read the letter on a text display with a width of 80 characters, so set the line wrapping mode accordingly within 80 characters. 4. Don't send in MIME Quoted-Printable encoding in an English forum; this encoding format is very necessary for languages that cannot be expressed in ASCII code, but many email agents don't support it. At this time, full of "=20" symbols split the text, which is not only ugly but also distracting.
5. Never expect hackers to be willing to read files in closed proprietary formats, such as Microsoft Word format. Most hackers' reaction to this is like you piling up hot pig manure on the doorstep steps (meaning no one will step into your door - translator's note).
6. If you send an email through a computer installed with Windows, turn off Microsoft's stupid "smart quotes" function. This can save you from having garbage characters in your email.
----------------------------
Use a Descriptive and Accurate Title
----------------------------
In the mailing list or newsgroup, the subject title within about 50 words is the golden opportunity to catch the attention of senior experts. Don't waste this opportunity with wordy "Help me" (let alone the annoying words like "Help!!!"
. Don't try to move us with the degree of your pain, and don't use spaces instead of the description of the question, even if it's extremely short. Stupid question:
Help! My laptop can't display normally!
Smart question:
Mouse cursor distorted under XFree86 4.1, display chip of Fooware MV1005.
If you raise a question in the reply, remember to modify the content title to indicate that there is a question in it. A question that looks like "Re: Test" or "Re: New bug" is difficult to attract enough attention. In addition, quote and cut the previous content to leave clues for new readers.
------------------
Describe Precisely and Provide Abundant Information
------------------
1. Describe the symptoms carefully and clearly.
2. Provide the environment where the problem occurs (machine configuration, operating system, application program and anything else).
3. Explain how you studied and understood this problem before asking the question.
4. Explain what steps you took to solve it before asking the question.
5. List the recent hardware and software changes that may have an impact.
Try to imagine how a hacker would ask you back and pre-answer him when asking the question.
Simon Tatham has written an excellent short article titled "How to Report Bugs Effectively". It's highly recommended that you also read it.
--------
Don't Talk Too Much
--------
You need to provide precise and effective information. This doesn't mean that you simply dump tons of error codes or data completely into your question. If you have a huge and complex test condition, try to cut it as small as possible.
There are at least three uses of doing this. First, it shows that you have made efforts 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, maybe you can find the problem or make a correction by yourself.
------------------
Only State Symptoms, Not Guesses
------------------
It's not helpful to tell hackers how you think the problem is caused. (If your inference is so effective, why do you need to ask others for help?) Therefore, make sure you tell them the symptoms of the problem exactly, without adding your own understanding and inference. Let hackers diagnose it.
Stupid question:
I keep encountering SIG11 errors in kernel compilation. I suspect that a flying wire is connected to the trace on the mainboard. What's the best way to check this situation?
Smart question:
I have a self-made K6/233 system, the mainboard is FIC-PA2007 (VIA Apollo VP2 chipset), 256MB Corsair PC133 SDRAM. I keep getting SIG11 errors in kernel compilation. This situation occurs frequently after 20 minutes of booting, and never occurs within the first 20 minutes after booting. Restarting doesn't help, but shutting down for a night and then it can work for 20 minutes again. All memories have been replaced, but it's of no effect. The typical compilation record of the relevant part is as follows...
------------------
List Symptoms in Chronological Order
------------------
The most helpful clue for finding the problem is often a series of operations before the problem occurs. Therefore, your description should include the operation steps and the computer's reaction until the problem occurs. In the case of command line operations, saving an operation record (for example, using a script tool) and citing about 20 relevant commands will be very helpful.
If the crashing program has a diagnostic option (for example, use -v to switch to detailed mode), try to carefully consider choosing the option to add useful debugging information in the operation record.
If your description is long (more than four paragraphs), it will be helpful to briefly describe the problem at the beginning and then elaborate in chronological order. Then hackers know what to look for in your description.
--------------
Don't Ask for Private Responses
--------------
Hackers think that the process of solving the problem should be open and transparent. As long as any more insightful person notices that the answer is imperfect or incorrect, this initial answer can and should be corrected. At the same time, the answerer is rewarded as he is noticed and accepted by everyone through his ability and knowledge.
If you ask for a private answer from the other party, this not only disrupts the entire process but also the reward system. Don't mention this requirement. It's the right of the answerer to choose whether to answer privately - if he chooses to do so, it's usually because he thinks the answer is too obvious or has a bad public impact and others won't be interested.
There is only a limited exception: if you expect to receive a large number of similar responses, you can say: "Send the answer to me, and I will summarize it." Rescuing the mailing list or newsgroup from a large number of repeated posts is very gentlemanly - but please remember to fulfill your promise about summarizing.
ko20010214
=================================
大功告成，打个Kiss!
ko20010214@MSN.com
神州优雅Q300C
Intel CeleronM 370处理器 | 256MbDDR内存
40G硬盘 | USB2.0 | IEEE 1394
13.3 ' WXGA 宽屏(16:10) | COMBO光驱
10/100M网卡 | 四合一读卡器
=================================
大功告成，打个Kiss!
ko20010214@MSN.com
神州优雅Q300C
Intel CeleronM 370处理器 | 256MbDDR内存
40G硬盘 | USB2.0 | IEEE 1394
13.3 ' WXGA 宽屏(16:10) | COMBO光驱
10/100M网卡 | 四合一读卡器
