How To Ask Questions The Smart Way

How To Ask Questions The Smart Way
The English version of this guide is copyright Eric S. Raymond, Rick Moen.

How ​​To Ask Questions The Smart Way

Copyright © 2001, 2006, 2014 Eric S. Raymond, Rick Moen

The English version of this guide is copyrighted by Eric S. Raymond, 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 based on the original version 3.10 and the latest translation from the 2010 translation by Gasolin;

To assist in pointing out translation problems, please issue an issue, or directly issue a pull request to me.

declaration

It's great that many projects link to this guide in their usage assistance/instructions pages, and we encourage everyone to do the same. But if you are the person responsible for managing this project web page, please put this in a prominent place near the hyperlink:

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

We have learned so much about the pain caused by the above statement. For lack of this statement, we keep getting stalked by some idiots. These idiots think that since we've published this guide, it's our duty to solve all the technical problems in the world.

If you read this guide for some kind of help, and left feeling like you could get direct help from the author of this article, you're one of those idiots we said earlier. Don't ask us questions, we'll just ignore you. In this guide we want to teach you how to get help from someone who really understands the software or hardware problem you're having, and 99% of the time it won't be us. Unless you're sure that one of the authors of this guide happens to be an expert in your problem domain, please leave us alone and everyone will be happy.

Introduction

In the world of hackers, when you throw a technical question, whether or not you end up with a useful answer often depends on how you ask and pursue it. This guide will teach you how to ask the right questions to get a satisfactory answer.

Now that Open Source software is quite prevalent, you can often get answers from other more experienced users as good as a hacker, which is a good thing; users tend to be more rude to newbies than hackers Frequently encountered problems are more forgiving. Still, treating these experienced users the way we recommend here is often the most effective way to get useful answers from them.

First of all, you should understand that hackers love challenging questions, or good questions that stimulate their minds. If we weren't, then we wouldn't be the people you wanted to ask about. If you gave us a good question worth mulling over, we'd be grateful. A good question is an incentive, a gift. Good questions can improve our understanding and often expose problems we hadn't realized or thought about before. "Good question!" is a sincere compliment to a hacker.

Still, hackers have a bad reputation for being contemptuous or arrogant to face simple problems, which can sometimes make us seem more hostile to newbies and ignorant people, but that's not the case.

We don't shy away from our disdain for those who don't want to think, or don't do what they're supposed to do before asking a question. Those people are time killers—they just want to take, never give, consuming the time we could spend on more interesting questions or people worth answering. We call such people losers (for historical reasons, we sometimes spell it lusers).

We realized that many people just wanted to use the software we wrote and they had no interest in learning the technical details. For most people, a computer is just a tool, a means to an end. They have their own lives and have more pressing things to do. We understand this and never expect everyone to be interested in the technical issues that fascinate us. Nonetheless, our style of answering questions is directed towards those who are genuinely interested in it and willing to actively participate in the problem-solving process. If even this changes, we are reducing our effectiveness at doing what we do best.

We are (largely) voluntary, take time out of our busy lives to answer questions, and are often inundated with questions. So we filter out some topics ruthlessly, especially ditching guys who look like losers, in order to use our time more efficiently to answer 'winner' questions.

If you hate our attitude, being overbearing, or being too arrogant, put yourself in that position. We're not asking you to bow to us - in fact, most of us are more than happy to communicate with you on an equal footing, and as long as you make the little effort to meet the basics, we'll welcome you into our culture. But it is not efficient for us to help those who are unwilling to help themselves. Ignorance is okay, but pretending to be an idiot is not okay.

So, you don’t have to be technically proficient to get our attention, but you have to exhibit the qualities that lead you to become proficient — alert, thoughtful, observant, and willing to take the initiative to solve problems. If you can't do these things that set you apart, we recommend that you spend some money to sign a tech support service contract with a commercial company, rather than asking a hacker to help you out for free.

If you decide to turn to us, of course you don't want to be seen as a loser, much less one of the losers. The best way to get quick and effective answers right away is to ask like a winner—smart, confident, with a problem-solving mindset, just needing a little help on a specific issue once in a while.

(Suggestions for improvements to this guide are welcome. You can send your suggestions to [email protected] or [email protected]. Note, however, that this article is not a general guide to Internet etiquette, and we generally reject suggestions that do not lead to useful answers in technical forums).

before asking questions

Before you're ready to ask technical questions via email, newsgroups, or chat rooms, please do the following:

1. Try searching for answers in old posts in the forum you are about to ask.
2. Try searching the Internet to find the answer.
3. Try reading the manual to find the answer.
4. Try reading the Frequently Asked Questions (FAQ) document to find the answers.
5. Try checking or experimenting for yourself to find the answer.
6. Ask strong friends around you to find out.
7. If you are a program developer, try reading the source code to find out.

When you ask a question, show that you've done the above; this will help establish that you're not a free-spirited questioner who wastes other people's time. It would be better if you could also express what you learned in doing the above efforts, because we are more open to answering questions from people who show they can learn from the answers.

Use some tactics, such as first google the various error messages you encounter (search the Google Groups and web pages), and you will most likely find a solution straight away Question file or mailing list thread. Even with no results, it's a good thing to add I Googled the following sentence and found nothing useful when asking for help on a mailing list or newsgroup, even if it just shows what help a search engine can't provide. Doing this (plus the searched string) also allows other people with similar problems to be directed to your question by search engines.

Don't worry, don't expect a few seconds of Google searches to solve a complex problem. Before asking an expert for help, read the Frequently Asked Questions (FAQ), relax, sit comfortably, and take some time to think about the problem. Trust us, they can tell from your questions how much reading and thinking you've done, and if you come prepared, you'll be more likely to get an answer. Don't throw all the questions at once because your first search didn't turn up an answer (or found too many).

Prepare your questions and think through them carefully, because sloppy questions will only get sloppy answers, or no answers at all. The more you can show that you worked hard to solve the problem before asking for help, the more likely you are to get real help.

Be careful not to ask the wrong question. If your question is based on false assumptions, a common hacker (J. Random Hacker) will probably answer you with meaningless literal explanations while thinking stupid question... in the hope that you will get the answer from the question. Learn from the answers (not the answers you want).

Never assume you are qualified to get an answer, you don't; you don't. After all you are not paying anything for this service. You will earn an answer yourself by asking meaningful, interesting, thought-stimulating questions—one that has the potential to contribute to the experience of the community, not just passively from others seek knowledge.

On the other hand, showing that you are willing to do something in the process of finding an answer is a very good start. Can anyone give some hints? ,What am I missing in this example? and where should I check is easier to get an answer than please post the exact process I need. Because you've shown that as long as someone can point you in the right direction, you have the ability and determination to get it done.

When you ask questions

Choose forums for asking questions carefully

Carefully choose the occasion in which you ask questions. You are likely to be ignored or seen as a failure if you do the following:

• Post your question on off-topic forums.
• Post very rudimentary questions in forums discussing advanced technical issues; and vice versa.
• Repeatedly reposting the same question (cross-post) on too many different newsgroups.
• Send private emails to people who are neither acquaintances nor obligated to solve your problems.

Hackers weed out the wrong occasions to protect their channels of communication from being overwhelmed by irrelevant stuff. You don't want this to happen to yourself.

So the first step is to find the right forum. Again, Google and other search engines are your friends, use them to find the most relevant sites for the hardware and software issues you're having a hard time with. Often there are frequently asked questions (FAQs), mailing lists, and links to related documentation. If your efforts (including reading the FAQ) are fruitless, there may be a bug-reporting process or link on the site, if so, check it out.

Emailing strangers or forums is most likely the riskiest thing to do. For example, don't assume that the author of a rich web page wants to act as your free consultant. Don't be too optimistic about whether your question will be welcomed - if you're not sure, send it elsewhere, or don't send it at all.

When choosing a forum, newsgroup or mailing list, don't trust the name too much, look at the FAQ or license first to see if your question is relevant. Flip through existing topics before posting, so you can get a feel for the culture there. In fact, it's an excellent idea to search the history of newsgroups or mailing lists for keywords related to your question beforehand, and maybe find the answer. Even if it doesn't, it can help you generalize better questions.

Don't "strafe" all channels of help at once like a machine gun, it's as unpleasant as yelling. Come one by one.

Figure out your subject! One of the most typical mistakes is to ask a question about the programming interface of the Unix or Windows operating system in some forum dedicated to a language, suite or tool that is portable across platforms. If you don't understand why this is a big mistake, it's best not to ask anything until you understand the difference.

In general, asking a question in a carefully selected public forum is more likely to get useful answers than asking the same question in a private forum. There are several reasons to support this, one is to look at the number of potential respondents, and the other is to look at the size of the audience. Hackers are more willing to answer questions that help many people.

It is understandable that sophisticated hackers and authors of some popular software are receiving too much misinformation. Like the straw that broke the camel's back in the end, your inclusion can take the situation to an extreme - it's been several times that some authors of popular software have stopped because of the unbearable flood of useless emails flooding their private mailboxes. provide support.

Stack Overflow

Search, then ask on Stack Exchange.

In recent years, the Stack Exchange community has become The primary source for answering technical and other questions, especially those open source projects.

Because Google indexing is instant, do a Google search before looking at Stack Exchange. There's a high chance that someone has already asked a similar question, and Stack Exchange sites tend to be among the top search results. If you don't find any answers on Google, you go to a site on a specific related topic. Searching with tags allows you to narrow down your search results even more.

If you still can't find anything useful for your question, please post your question on the site most relevant to it. Make good use of formatting tools when asking questions, paying particular attention to formatting your code and adding relevant tags (especially the name of the programming language, operating system, or library/package). When someone asks you for more relevant information, please edit your post to supplement them [Annotation: not a reply or an answer! ]. If you find an answer helpful, click the up arrow to vote for it; if an answer provides the correct solution to the question, click the checkmark below the vote button to mark it as the correct solution.

Stack Exchange has grown to more than a hundred sites, here are the most commonly used ones:

• Super User is asking some general computer questions. If your question has nothing to do with code or writing programs, just some network connections, please go here.
• Stack Overflow is for questions about writing programs.
• Server Fault is a question related to server and network management.

Website and IRC Forum

A local user group, or maybe your Linux distribution is promoting their web forum or IRC channel and offering newbie help (in some non-English speaking countries, the newbie forum is probably still a mailing list), all of which It's a good place to start asking questions, especially if you think you may be dealing with a relatively simple or common question. Ad-sponsored IRC channels are a place where questions are openly welcome, often with immediate responses.

In fact, if a problem with a program occurs only in the version provided by a particular Linux distribution (which is quite common), it is best to ask questions on that distribution's forums or mailing lists before asking questions on the program's own forum or mailing list. (Otherwise) a hacker of the project might just reply "use our version".

Before posting on any forum, check to see if there is a search function. If so, try searching for a few keywords of the question, maybe this will help. If you've done a general web search before (and you should too), search the forum again, as search engines may not have time to index the full content of the forum.

There is a growing trend to provide user support services through forums or IRC channels, while email is mostly reserved for communication between project developers. So it's best to seek assistance with this project in the forums or IRC first.

When using IRC, it's best not to post long problem descriptions in the first place, which some people call channel flooding. It's best to start the chat with a one-sentence description of the problem.

Step 2, use the project mailing list

When a project offers a developer mailing list, ask questions to the list, not to an individual member, even if you are sure he can best answer your question. Check out the project's documentation and homepage, find the project's mailing list and use it. There are several good reasons for this approach:

• Any question that is good enough to ask 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's not a reason to harass individual developers.
• Asking questions to the list can spread the burden on developers, and individual developers (especially project leaders) may be too busy to answer your questions.
• Most mailing lists are archived, and those archived will be indexed by search engines. If you ask a question to the list and get an answer, in the future others can find your question and answer via web search without having to ask it again.
• If certain questions are frequently asked, developers can use this information to improve the documentation or the software itself to make it clearer. If it's just a private question, no one can see the full picture of the most common questions.

If a project has both "users" and "developers" (or "hackers") mailing lists or forums, and you won't touch those source code, ask questions on the "users" list or forum. Don't assume you'll be popular on developer lists, those people will most likely see your question as noise that interferes with their development.

However, if you are sure that your question is unique and you haven't gotten a response in the "Users" list or forum for several days, try asking it on the "Developers" list or forum. It is recommended that you do a good job of surreptitiously watching for a few days before posting to see how things work there (actually it's a good idea to participate in any private or semi-private listings)

If you can't find a project's mailing list, but only the email address of the project's maintainer, just send him a letter. Even in this case, don't assume the (project) mailing list doesn't exist. In your email, please state that you have tried but have not found a suitable mailing list, and mention that you have no objection to forwarding your email to others (many people believe that private emails should not be Public. By allowing your email to be forwarded to others, you give people the option to dispose of your email).

Use meaningful and descriptive titles

On mailing lists, newsgroups, or forums, headlines under about 50 words are a good opportunity to grab the attention of senior experts. Don't waste this with chattering 'help', 'kneeling', 'urgent' (not to mention 'help!!!!' if it's so offensive, the title will be reflexively ignored) Chance. Don't try to impress us with the level of your pain, but ask the question in a very simple and concise way in this space.

An example of a good title is the target - difference style description, which is what many technical support organizations do. In the goals section indicate which thing or group of things is at fault, and in the differences section describe the inconsistencies with the expected behavior.

Stupid Question: Help! My laptop doesn't display properly anymore!

Clever question: X.org 6.8.1 mouse pointer will be deformed, a certain brand of graphics card MV1005 chipset.

Smarter question: X.org 6.8.1 mouse pointer, under certain graphics card MV1005 chipset environment - will be deformed.

The process of writing an Objective-Difference description helps you organize your careful thinking about the problem. What was affected? Just the mouse pointer or something else? Only in the X version of X.org? Or is it just in version 6.8.1? Is it for a certain brand of graphics card chipset? Or just the MV1005 model in it? A hacker can instantly understand your environment and the problem you're having with just a glance.

To summarize, imagine that you're searching through an index of archived Threads that only show titles. Making your title better reflect the question will allow the next person searching for a similar question to follow the thread without having to ask the same question again.

If you want to ask a question in a reply, remember to revise the content title to indicate that you are asking a question, a title that looks like Re: Testing or Re: New bug is hard to get enough attention. In addition, without compromising coherence, appropriate citations and deletions from the previous text can leave clues for new readers.

For threads, don't just click Reply to start a whole new thread, this will limit your audience. Because some email readers, like mutt, allow users to sort by threads and hide messages by collapsing threads, people who do so will never see your messages.

Just changing the title is not enough. mutt and some other mail readers also check information other than mail headers in order to assign a thread to it. So would rather send a whole new email.

On web forums, good questioning is slightly different, because the thread is tightly coupled with specific information, and the content is usually not visible outside the thread, so replying to the question rather than changing the title is acceptable . Not all forums allow separate headers in replies, and if they do, almost no one will read it. However, by replying to the question, which is ambiguous in itself, as they will only be read by the person who is viewing the title. So unless you just want to ask questions in the group that's currently active on the thread, it's better to start over.

Make questions easy to answer

Closing your question with Please send your reply to... ​​will most likely leave you unanswered. If you think it's cumbersome to spend a few seconds setting up a reply-to address in your email client, we also think it's more cumbersome to spend a few seconds thinking about your question. If your mail program does not support this, change to a better one; if the operating system does not support this mail program, also change to a better one .

In forums, it's very rude to ask for a reply by email, unless you think the information in the reply may be sensitive (someone will, for some unknown reason, only let you, not the entire forum, know the answer). If you just want to get email alerts when someone replies to a thread, you can ask the web forum to send it to you. Almost all forums support features such as follow this thread, send email alerts when there are replies, etc.

Use clear, correct, precise, and grammatical statements

We've learned from experience that careless questioners are usually careless in programming and thinking too (I'll bet). It's not worth answering questions from the careless, and we'd rather spend our time elsewhere.

Correct spelling, punctuation, and capitalization are important. Generally speaking, if you think it's a hassle to do this and you don't want to care about it, then we also think it's a hassle and don't want to care about your question. Spend a little extra effort on your words, don't need to be rigid and formal - in fact, hacker culture values ​​the accurate use of informal, slang, and humorous sentences. But it has to be accurate, and there are signs that you are thinking and paying attention.

Spell, use punctuation and capitalization correctly, don't confuse its with it's, loose with lose, or discrete with discreet. Don't all caps, this will be seen as a rude shout (all lowercase is not much better because it's not easy to read. Alan Cox may be able to do so, but you can't).

To put it more vernacularly, if you write like a semi-literate Annotation: [Xiaobai], then most likely will not be ignored. Also don't use shorthand in instant messaging or Martian, e.g. shortening '' to d` will make you look like a A little white with a few keys and a few words. To make matters worse, it's definitely courting death if you're ghosting like a child, and you can be sure that no one will listen to you (or at most give you a lot of blame and sarcasm).

If you're asking a question in a non-native language forum, you can make small mistakes in spelling and grammar, but never be sloppy in your thinking (yes, we can usually tell the difference). Also, please write in English unless you know the language of the respondent. Busy hackers often simply delete messages written in languages ​​they don't understand. English is the lingua franca on the web, and writing in English minimizes the chance that your question will be deleted before it has been read.

If English is your second language, it is good to alert potential respondents that you have potential language difficulties:
[Annotation: The original text is attached below for use]

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

*English is not my first language, please forgive my typo or grammar.

If you speak $LANGUAGE, please email/PM me;
I may need assistance translating my question.

• If you speak a language, please email/DM 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 not very familiar with colloquialisms 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 wrote my question in a language and in English.
• If you answer in only one of these languages, I will be happy to translate the response into your language.

Send questions in an easy-to-read and standard file format

If you make a question artificially hard to read, it's more likely to be ignored, people prefer easy-to-read questions, so:

• Use plain text instead of HTML (closed HTML is not difficult).
• Using MIME attachments is usually ok, provided it is true There is content (such as accompanying source code or patches), not just templates generated by the mailer (such as just a copy of the content of the letter).
• Don't send emails where a piece of text is just one sentence but wraps into multiple lines (this makes replying to parts very difficult). Assuming your reader is reading email on a terminal that is 80 characters wide, it's best to set your newline breakpoint to less than 80 characters.
• However, DO NOT set a fixed width for some special files (such as log file copies or session records). The data should be included as-is to give respondents confidence that they are seeing the same thing as you.
• Do not send messages using the Quoted-Printable MIME encoding in English forums. This encoding may be necessary for posting in non-ASCII languages, but is not supported by many mail programs. When they deal with line breaks, those =20 symbols scattered all over the text are unsightly and distracting, and may even break the semantics of the content.
  *Absolutely, never do not expect hackers to read documents written in closed formats, like Microsoft Word or Excel files. Most hackers react to this like you would when someone dumped steaming pig manure on your doorstep. Even if they could handle it, they resented it.
• If you're sending emails from a Windows computer, turn off Microsoft's stupid smart quotes feature (from [Options] > [Editing] > [AutoCorrect Options], uncheck the Smart quotes radio box) to avoid Spread junk characters all over your mail.
• Do not abuse the emoji and HTML features (when they are available) in the forum. An emoji or two is usually fine, but fancy colored text tends to make people think you're incompetent. Overuse of emojis, colors, and fonts can make you look like a giggling little girl. It's usually not a good idea unless you're just interested in sex and not answers.

If you use a graphical user interface mail program (such as Microsoft's 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, which is used to check the mail in the sent folder to make sure that it is sending a plain text file without some strange characters.

Describe the problem precisely and make sense of it

• Carefully and clearly describe the symptoms of your problem or bug.
• Describe the environment in which the problem occurred (machine configuration, operating system, applications, and related information), and provide the distributor's release and version number (eg: Fedora Core 4, Slackware 9.1, etc.).
• Describe how you researched and understood the question before asking the question.
• Describe the diagnostic steps taken to identify the problem before asking the question.
• Describe any recent hardware or software changes that may be relevant.
• Provide a way to reproduce the problem in a controlled environment as much as possible.

Try to guess how a hacker will ask you back, and answer any questions that hackers might ask before you ask.

Of the above points, it's especially important to give hackers an environment in which to reproduce your problem when you're reporting a problem you think might be in your code. When you do this, your chances and speed of getting a valid answer are greatly improved.

Simon Tatham wrote an article titled "How to Report Bugs Effectively" excellent article. Strongly recommend that you read it too.

The words are not too much, but the essence

You need to provide precise and informative information. This doesn't require you to simply transcribe piles of buggy code or data into your question. If you have a large and complex test case that reproduces the crash, try to trim it as small as possible.

This is useful for at least three points.
First, show that you made an effort to simplify the question, which can increase your chances of getting an answer;
Second, simplifying the question makes you more likely to get a helpful answer;
Third, in the process of refining your bug report, you will likely find workarounds or workarounds on your own.

Don't claim to have found a bug

When you run into problems with the software, don't claim to have found a bug unless you are very, very well-founded. Hint: Unless you can provide a source code patch to fix the problem, or a regression test to show that the behavior was incorrect in the previous version, you're probably not entirely sure. The same applies to web pages and documentation, if you (claim to) find a bug in the documentation, you should be able to provide a fix or replacement in the corresponding location.

Remember, there are many other users who didn't encounter the problem you found, or you should have found it while reading a file or searching the web (you did this before complaining, right? ). It also means that it's more likely that you got it wrong rather than the software itself.

People who write software always work very hard to make it as perfect as possible. If you claim to have found a bug, you are questioning their competence, and even if you are right, you may offend some of them. This is especially serious when you're ranting about a 'Bug' in the title.

When asking a question, even if you're privately sure you've found a real bug, it's best to write as if you did something wrong. If there is a bug, you will see this in the reply. Doing this, the maintainer will apologize to you if there is a bug, which is better than pissing someone off and owing them an apology.

humming is not a substitute for your homework

Some people understand that they shouldn't be rude or arrogant to ask questions and demand answers, but they choose the other extreme - humbly: 'I know I'm just a sad newbie, a jerk, but...'. This is both disturbing and unhelpful, especially when it is accompanied by vague descriptions of the actual problem.

Don't waste your time or mine with primitive primate tricks. Instead, describe the background conditions and your problem situation as clearly as possible. This pinpoints your position better than whispering.

Sometimes web forums have a section for beginners to ask questions, if you really think you have a beginner's question, go there, but don't be so humble.

Describe the symptoms of the problem rather than your guesses

Telling hackers what you think is causing the problem doesn't help. (If your inferences are so valid, do you still need to ask others for help?), so make sure you tell them the symptoms of the problem in the first place, not your explanations and theories; let the hackers speculate and diagnose. If you think it's important to state your guesses, make it clear that it's just your guesses and describe why they didn't work.

stupid question

I get SIG11 errors one after another while compiling the kernel,
I suspect that a certain flying lead is on the trace of the motherboard. What should be the best way to check this situation?

Smart question

My build computer is a FIC-PA2007 motherboard with AMD K6/233 CPU (VIA Apollo VP2 chipset),
256MB Corsair PC133 SDRAM memory, when compiling the kernel, SIG11 errors frequently occur 20 minutes after booting,
But the same problem never happened in the first 20 minutes. Rebooting didn't help either, but shutting down overnight worked again for 20 minutes.
All memory has been replaced with no effect. The standard compilation records for the relevant parts are as follows...

Since this seems like a lot of people find it difficult to cooperate, here's a quote to remind you: 'All diagnostic specialists are from Missouri. The official motto of the U.S. State Department is: Let me see' (from a speech by Congressman Willard D. Vandiver in 1899: I come from a country of corn, cotton, burdock, and Convince me, and it won't satisfy me either. I'm from Missouri, you have to show me.) For the diagnosed, this is not a skepticism, but a real and useful need in order for them to What you see is as consistent as possible with the original evidence you see, not your guesses and generalizations. So, show it to us generously!

List problem symptoms in chronological order

A series of operations before the problem occurs is often the most helpful clue to identify the problem. Therefore, your instructions should contain your steps, as well as the response of the machine and software, until the problem occurs. In the case of command-line processing, it can be helpful to provide a record of an operation (such as that generated by running a script tool), with references to the relevant several lines (such as line 20) of the record.

If the program that crashes has diagnostic options (such as the - v verbose switch), try selecting those options that add debugging information to the log. Remember, more does not equal good. Try picking an appropriate debug level to provide useful information instead of drowning the reader in junk.

If your statement is long (such as more than four paragraphs), it can be helpful to briefly state the problem at the beginning, followed by a chronological detail. That way hackers know what to look out for when they read your records.

Describe the goal rather than the process

If you're trying to figure out how to do something (rather than reporting a bug), describe your goals at the beginning, and only then state the specific steps to reproduce where you're stuck.

People who often seek technical help have a higher purpose in mind, they get stuck on a particular path they think will get there, and they come to ask how to get there, not realizing that the path itself is something wrong. It turns out that it takes a lot of effort to get it right.

stupid question

How can I get hex RGB values ​​from a paint program's color picker?

Smart question

I'm trying to replace an image's color table with a color code of my own choosing, the only way I know of now is to edit each color code block (table slot),
But can't get the hex RGB value from a paint program's color picker.

The second method of questioning is smarter, and you may get responses like `suggesting another more appropriate tool`.

Don't ask for a private email reply

Hackers believe that the problem-solving process should be open and transparent, where the initial response can and should be corrected if someone more experienced in the process notices incompletion or inappropriateness. At the same time, as a helper, you can get some rewards, and the reward is that his ability and knowledge are seen by other peers.

When you request a private reply, both the process and the reward are aborted. Don't do this, let the responder decide whether to answer privately - if he does, it's usually because he thinks the question is too poorly written or too shallow to be of interest to others.

There is a limited exception to this rule, if you are sure that the question is likely to get a lot of identical responses, then the magic question sentence would be 'email me and I will summarize the responses for the forum'. It's very polite to try to rescue a mailing list or newsgroup from a flood of identical replies - - but you have to keep your word.

Express your questions and needs clearly and clearly

The rambling questioning is a near-endless black hole of time. The people most likely to give you useful answers are also usually the busiest people (who are busy doing most of the work themselves). Such people are quite disgusted with uncontrolled time black holes, so they also tend to dislike those rambling questions.

You are most likely to get useful answers if you clearly state what you need the answerer to do (eg provide pointers, send a piece of code, check your patch, etc.). Because this will set an upper limit of time and effort so that the respondent can focus on helping you. It's great to do this.

To understand the world experts live in, think of expertise as an abundant resource and response time as a scarce resource. The less time you ask them to dedicate, the more likely you are to get answers from experts who are truly professional and busy.

So, defining your question so that the time spent identifying your question and answering it to a minimum is a technique that can go a long way toward giving you a useful answer—but it's usually a different technique than simplifying the question. So, ask I want to understand X better, can you point me to a better explanation? Usually than asking Can you explain X? Better. If your code doesn't work, it's often wiser to ask someone to see what's wrong than to ask someone to fix it for you.

When asking questions about code

Don't ask others to help you debug problematic code or give you a hint of where to start. Posting a few hundred lines of code and saying: it doesn't work will get you completely ignored. Just post a few dozen lines of code and say: After the seventh line, I expected it to show <x>, but <y> is more likely to get you a response.

The most effective way to describe program problems is to provide the most concise bug-demonstrating test case. What is the most compact test case? That's the epitome of the problem; a small program fragment can just show the abnormal behavior of the program without other distracting content. How to make the most streamlined test cases? If you know which line or piece of code is causing the unexpected behavior, copy it and add enough code to reproduce the situation (eg, enough for the code to be compiled/translated/handled by the application). If you can't narrow the problem down to a specific block, make a copy of the code and remove the part that doesn't affect the behavior in question. In short, the smaller the test case, the better (see the section No more but more precise section).

In general, it's not easy to get a fairly condensed test case, but it's a good habit to always try to do this first. This approach can help you understand how to solve the problem on your own - and even if your attempts are unsuccessful, hackers will see your efforts in trying to get an answer, which can make them more willing to work with you.

If you just want someone to help you review the code, say so at the beginning of the letter, and be sure to mention to which part you think needs special attention and why.

Don't post your own homework questions

Hackers are good at telling which problems are homework-style problems; because most of us have solved these kinds of problems on our own. Again, these problems are up to you, and you'll learn from them. You can ask for hints, but don't ask for a complete solution.

If you suspect you've run into a homework-style problem and still can't solve it, try asking in a user group, forum, or (as a last resort) the project's Users mailing list or forum. Although hackers will see it, some experienced users may still give you some hints.

Remove meaningless question sentences

Avoid ending the question with meaningless words such as Can someone help me? Or does this have an answer? .

First of all: if your description of the problem is not very good, asking this is superfluous.

Second: Hackers will tire of you because it's superfluous to ask - - and will usually show their disdain with logically correct, but meaningless answers, such as: 'Yes, someone can help you' or 'No , no answer`.

In general, avoid yes or no, true or false, yes or no type questions unless you want a yes or no type of answer.

Don't write Urgent in the title even if you are in a hurry

This is your problem, not ours. Declaring 'urgent' will most likely backfire: most hackers will simply delete the question in a rude and selfish attempt to get instant attention. What's more, the word 'urgent' (or other headlines that try to get attention) is often filtered out by spam filters - - the people you wish to see your question might never see.

With half the exception, if you're in some high profile place that excites hackers, it might be worth it. In this case, if you're under time pressure, mention it politely and people might be interested in answering faster.

Of course, it's risky because hackers are probably not as excited about it as you are. It’s fine to post headlines like this from NASA’s International Space Station, but certainly not for feel-good philanthropy or political reasons. In fact, posts like `Urgent: Help me save this furry baby seal! ‘Definitely get you ignored by hackers or annoy them, even if they think furry seal pups are important.

If this seems weird to you, it's best to read the rest of this guide a few more times until you figure it out before posting.

Courtesy many people do not blame, and sometimes very helpful

Be polite and use please and thank you for your attention, or thank you for your concern. Let everyone know you appreciate them taking the time to help for free.

Frankly, this is no more important (and not a substitute for) than using clarity, correctness, precision, and grammar and avoiding proprietary formats. Hackers generally prefer to read slightly abrupt but technically distinct bug reports rather than polite but vague reports. (If this confuses you, remember that we value questions in terms of what they teach us)

However, if you have a string of questions to answer, being polite will definitely increase your chances of getting a useful response.

(We've noticed that since the publication of this guide, the only serious bug feedback we've gotten from veteran hackers has been for the "Thanks Up Front" item. Some hackers feel that 'thank you in advance' means you don't have to thank anyone for hints afterwards. We My suggestion is to either say 'Thanks in advance', then thank the respondent afterwards, or express gratitude in a different way, such as 'Thank you for your attention' or 'Thank you for your concern'.)

After the problem is solved, add a short supplementary explanation

After the problem is solved, send a note to all who helped you, let them know how the problem was solved, and thank them again. If an issue has attracted widespread attention on a newsgroup or mailing list, it would be appropriate to post a note there.

Ideally, reply to this message to the thread on which the question was originally asked, and include a 'fixed', 'resolved' or other obvious sign of the equivalent in the title. A potential responder who sees the discussion threads Question X and Question X - resolved on a mailing list of people will know that there is no need to waste time (unless he personally finds Question X interesting), So you can use this time to solve other problems.

The supplementary explanation does not have to be very long or in-depth; a simple sentence Hello, it turns out that there is a problem with the network cable! Thank you all – Bill is better than saying nothing to come. In fact, unless the conclusion is really technical, a short and lovely summary is better than a long one. Explain how the problem was solved, but it is not necessary to repeat the process of solving the problem.

For in-depth questions, it is helpful to post a summary of the debug log. Describe the final state of the problem, state what solved the problem, and only after this point identify avoidable blind spots. The blind spot avoidance section should be placed after the correct solution and other summary material, rather than turning this information into a detective mystery. Listing names that have helped you will make you more friends.

In addition to being polite and meaningful, this type of supplementation also helps others benefit from searching for a real solution to your problem on mailing lists/newsgroups/forums.

At the very least, this supplement helps give everyone involved in the problem-solving satisfaction that comes with it. If you're not a technologist or hacker yourself, trust us, that feeling is very important to the gurus or experts you turn to for help. Unsolved problems can be frustrating; hackers are eager to see problems solved. Good people are rewarded, satisfy their cravings, and you'll taste the sweetness the next time you ask a question.

Think about how you can prevent others from having similar problems in the future, and ask yourself if writing a document or adding a Frequently Asked Questions (FAQ) would help. If so send them to the maintainer.

In hacking, this good follow-up is actually more important than traditional etiquette and how you earn your reputation by being kind to others is a very valuable asset.

How to interpret the answer

RTFM and STFW: How to know you're totally screwed

There's an ancient and sacred tradition: if you get a RTFM (Read The Fucking Manual) response, the respondent thinks you should read the fucking manual. Of course, basically he's right, and you should read it.

RTFM has a young relative. If you get a STFW (Search The Fucking Web) response, the respondent thinks you should search the fucking web. That person is probably right, so go search. (A milder version would be Google is your friend!)

In forums, you may also be asked to crawl old forum posts. In fact, someone might even be kind enough to provide you with a thread that previously addressed this issue. But don't rely on this kind of care, and you should search old texts before asking questions.

Usually, the person who answers you with one of these two sentences will give you a manual or a web address with the content you need, and they are reading it as they type. These replies imply that the respondents believed that

The information you need is very easy to get;
Searching for this information on your own will teach you more than it will be given to you.

You shouldn't be upset about it; By the hacker's standards, he's already shown a certain level of concern for you without turning a blind eye to your demands. You should thank him for his grandmother's kindness.

If you still don't understand

If you don't understand the response, don't ask for an explanation right away. As you did when you tried to solve the problem yourself (using manuals, FAQs, the Internet, the experts around you), try to understand his response first. If you really need an explanation, remember to show that you have learned something from it.

For example, if I answer you: It looks like zentry is stuck; you should clear it first. , then, a bad follow-up question response: What is a zentry? Good the question should be like this: Oh~~~ I read the instructions but only the - z and - p parameters mentioned zentries, and neither of them clearly explained how to clear it. Which of these two are you referring to? Or am I missing something?

Handling offensive responses

Seemingly offensive behavior in many hacker circles is not intended to be offensive. Instead, it's a straight-forward, to-the-point communication style that's more focused on problem-solving than making people feel comfortable and vague.

If you feel offended, try to react calmly. If someone really does something outrageous, the seniors on the mailing list, newsgroup, or forum will probably greet him. If this doesn't happen and you get mad, the words of the person you are mad at may seem normal in the hacker community, and you will be seen as the wrong one, which will hurt Your access to information or help.

On the other hand, you do occasionally come across rude and boring words and deeds. Contrary to the above, it is acceptable to smack the real offender hard and use sharp language to refute him to the fullest. However, be very, very grounded before acting. Correcting rude remarks is a fine line from starting a pointless war of words, and it's not uncommon for hackers to cross the line recklessly on their own. If you are a novice or outsider, the chances of avoiding this recklessness are not high. If you want to get information rather than kill time, it's best not to put your hands on the keyboard at this time to avoid risk.

(Some people assert that many hackers have mild autism or Asperger's syndrome, lacking the nerves needed to lubricate normal interactions in human society. This may be true or false. If You're not a hacker yourself, maybe you think we have a problem with our heads and help you with our odd behavior. Just do it, we don't care. We love the way we are, and usually have patient markers A justifiable doubt.)

Jeff Bigler's summary of observations related to this is also worth reading (tact filters).

In the next section, we'll touch on another issue, the 'offensive' you get when you misbehave.

How to avoid playing the loser

In the forums of the hacker community, you probably screwed up a few times in the manner described in this guide or similar. And you'll be told in public how you screwed up, maybe with a bit of a slap in the face of the attack.

After something like this happens, the worst thing you can do is wailing what happened to you, claiming to be verbally attacked, demanding an apology, screaming, holding your breath, threatening legal action, complaining to your employer, not shutting down Toilet lids, etc. Instead, you should do this:

Get over it, it's normal. In fact, it is wholesome and reasonable.

Community standards do not maintain themselves, they are maintained through active and public enforcement by participants. Don't cry all criticism should be sent via private mail, it doesn't work that way. There's no benefit in insisting that you've been personally attacked when someone comments that one of your claims is wrong or disagrees, these are the attitudes of a loser.

There are other hacking forums, misled by high etiquette requirements, that prohibit participants from posting any messages that criticize other people's posts, and claim to 'shut up if you don't want to help users. ` As a result, thoughtful participants left, and doing so only reduced them to pointless nagging and useless tech forums.

The hyperbole is: do you want to be "friendly" (in the way described above) or useful? Pick one of the two.

Remember: when a hacker says you screwed up, and (no matter how harsh) tells you to stop doing it, he's acting out of concern for you and his community. It's easier for him to ignore you and filter you out of his life. If you can't thank you, at least show some dignity, don't whine, and don't expect others to treat you like a fragile doll just because you're a dramatic hypersensitive soul and self-qualified newcomer .

Sometimes, even if you didn't screw up (or just in his imagination you screwed up), someone will attack you personally for no reason. In this case, complaining is really screwed up.

The people who come in for trouble are either no-brainers who think they're experts at nothing, or psychologists who test if you can really screw up. Other readers either ignore them or deal with them in their own way. These troublemakers are making trouble for themselves, don't worry about that.

And don't get yourself involved in a spat, it's best to ignore most spats - - of course, when you test that they're just spam and don't point out where you screwed up, and don't subtly bring the problem to the real world. The answer is hidden behind it (which is also possible).

Questions not to ask

Here are a few classic stupid questions, and what hackers have in mind when they don't answer:

Question: Where can I find X programs or X resources?

Question: How do I use X to do Y?

Question: How do I set my shell prompt?

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

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

Question: I have a problem with my Windows computer, can you help me?

Question: My program won't work, I think there is something wrong with system tool X

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

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

Question: Where can I find X programs or X resources?

Answer: Right where I found it, idiot—— On the other end of the search engine. OMG! Is there anyone who can't use Google?

Question: How do I use X to do Y?

Answer: If what you are trying to solve is Y, don't ask the question in a way that might not be appropriate. This kind of question shows that the questioner is not only completely ignorant of X, but also confused about the problem Y is trying to solve, and his thinking is imprisoned by the specific situation. It's best to ignore such people and wait until they figure out the problem.

Question: How do I set my shell prompt? ?

Answer: If you are smart enough to ask this question, you should also be smart enough to RTFM and find out for yourself.

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

Answer: Try it and see. If you try it, you know the answer and don't waste my time.

Problem: My {Program/Setup/SQL Statement} doesn't work

Answer: It's not really a question, I'm not interested in questions that require me to ask you twenty questions to find out your real problem - I have more interesting things to do. When I see this kind of problem, my reaction is usually no more than the following three

• Do you have anything else to add?
• That sucks, hope you can handle it.
• It's none of my business?

Question: I have a problem with my Windows computer, can you help me?

Answer: Yes, throw away the Microsoft junk and switch to an open source operating system like Linux or BSD.

NOTE: If the program has an official version of Windows or interacts with Windows (like Samba), you can ask questions related to Windows, just don't be surprised by the replies that the problem is caused by the Windows operating system and not the program itself, Because Windows in general sucks, this statement is usually true.

Problem: My program doesn't work anymore, I think there is something wrong with System Tools X

Answer: It's entirely possible that you were the first to notice obvious flaws in system calls and library files that are used repeatedly by thousands of users, and it's more likely that you have absolutely no basis. Extraordinary claims require extraordinary evidence, and when you make such a claim, you must back it up with clear and detailed defect documentation.

Question: I'm having trouble installing Linux (or X), can you help me?

Answer: No, I can only find the fault by doing it myself on your computer. Or go to your local Linux user group for practical guidance (you can find a list of user groups here).

Note: If the installation question is related to a Linux distribution, it may be appropriate to ask it on its mailing list, forum, or local user group. At this point, the exact details of the problem should be described. Before doing so, do a careful keyword search using Linux and all of the suspected hardware.

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

Answer: If you want to do this, it shows that you are a despicable person; if you want to find a hacker to help you, it shows that you are an idiot!

Good questions and stupid questions

Finally, I'll give some examples of how to ask wisely; two ways of asking the same question are put together, one is stupid and the other is wise.

Stupid question:

Where can I find information about Foonly Flurbamatic?

This kind of question is nothing more than wanting an answer like STFW.

Smart question:

I googled "Foonly Flurbamatic 2600" but found no useful results. Does anyone know where to find information on programming such a device?

This question has been STFW over and it looks like he's really in trouble.

Stupid question:

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

He thinks it's all someone else's fault, the arrogant questioner.

Smart question:

The foo project code fails to compile under Nulix version 6.2. I've read the FAQ, but it doesn't mention Nulix-related issues. This is a log of my compilation process, am I doing something wrong?

The questioner has indicated the environment, read the FAQ, listed errors, and he didn't put the blame on others, his question deserves attention.

Stupid question:

I have a problem with my motherboard, who can help me?

A hacker's answer to this type of question is usually: 'Okay, do you want a pat on the back and a diaper change for you? `, and then press the delete key.

Smart question:

I tried X , Y and Z on the S2464 board but nothing worked, I tried A , B and C again. Notice the weirdness when I try C . Apparently the florbish was grommicking, but the results were unexpected. What usually causes grommicking on Athlon MP motherboards? Does anyone know what tests I should do next to find the problem?

This guy, from another angle, deserves to answer him. He has shown the ability to solve problems rather than wait for answers.

In the last question, note the subtle but important difference between 'tell me the answer' and 'show me what else I should do to diagnose'.

In fact, the latter question stems from a real question on the Linux kernel mailing list (lkml) in August 2001. I (Eric) was the one who asked the question. I observed this unexplained lockup on a Tyan S2464 motherboard, and the list members provided important information on how to fix it.

Through my questioning method, I give others something to chew on; I manage to make it easy for people to engage and be drawn in. I showed that I had the same ability as them and invited them to discuss it with me. I also show respect for their precious time by telling them about the detours I've taken so that they don't waste any more time.

Afterwards, when I thanked everyone and appreciated the good discussion experience, a member of the Linux kernel mailing list stated that he felt that my problem was not solved because I was the name on the list people, but because I asked the question the right way.

A hacker is in a way a knowledgeable but impersonal guy; I'm sure he's right, if I ask like a beggar, whoever I am, is bound to annoy someone or get caught They ignore. He suggested that I take note of it, which led directly to this guide.

If no answer

If you still don't get an answer, please don't think we feel we can't help you. Sometimes it's just that the person who sees your question doesn't know the answer. No response doesn't mean you're being ignored, although admittedly the difference is hard to tell.

In general, simply reposting the question is a bad idea. This would be seen as pointless noise. Be 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 in the first place.

You can get help through other channels, which are usually better suited to the needs of beginners.

There are many online and local user groups made up of enthusiastic software enthusiasts (even though they may never have written any software themselves). Often people form groups like this to help each other and help newbies.

Also, there are many commercial companies you can turn to for help, big or small. Don't get frustrated with paying for help! After all, if your car's engine cylinder seal blows - - which is entirely possible - - you'll have to take it to a garage and pay for the repair. Even if the software doesn't cost you a cent, you can't insist that technical support is always free.

For popular software like Linux, each developer corresponds to at least tens of thousands of users. It is simply impossible for one person to handle calls for help from tens of thousands of users. Be aware that even if you pay for this assistance, it's trivial compared to what you're paying for similar software (usually closed-source software costs much more for technical support than open-source software, and the content is also not so rich).

How to better answer questions

Be kind. The stress of questions often makes people appear rude or stupid, which is not the case.

Private reply to first-time offenders. There's no need for public shaming for those who are honestly wrong, a true novice may not even know how to search or where to find FAQs.

If you're not sure, be sure to speak up! An authoritative-sounding wrong reply is worse than none, don't give people the wrong way because it's fun to sound like an expert. Be humble and honest, and set a good example for the questioner and your peers.

If you can't help, don't get in his way. Don't joke about the actual steps, that might ruin the questioner's setup - some poor idiots will take it for a real command.

Tentative rhetorical questions to elicit more details. If you do it well, the questioner can learn something - and so can you. Try turning stupid questions into good ones, and don't forget we're all newbies.

While it's legitimate to complain about RTFM to those slackers, a link to the documentation (even if it's just a Google search keyword suggestion) would be better.

If you decide to answer, please give a good answer. Don't suggest clumsy workarounds when others are using the wrong tool or method, suggest better tools and redefine the problem.

Answer the question head-on! If the questioner has done a lot of research and also shows that X, Y, Z, A, B, C have been tried and no results, answer Try A or B or Try X, Y, Z , A , B , C and attaching a link won't help at all.

Help your community learn from problems. When replying to a good question, ask yourself How can I revise the relevant document or FAQ document so as not to answer the same question again? , followed by a patch to the file maintainer.

If you do some research before answering, show your skills instead of giving the results. After all, it is better to teach a man to fish than to give him a fish.

related resources

If you need basic knowledge of how personal computers, Unix systems, and networks work, see Unix System and Network Fundamentals.

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

Thanks

Evelyn Mitchel contributed some silly question examples and inspired the 'How to better answer questions' section, and Mikhail Ramendik contributed some particularly valuable suggestions and improvements.