The wisdom of asking questions

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 and Rick Moen.

Original website: www.catb.org/~esr/faqs/s…

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 of the version translated by Gasolin in 2010;

Help to point out translation problems, please send the Issue or directly send the Pull Request to me.

This article also has a traditional Chinese version.

Original version history

directory

  • The statement
  • Introduction to the
  • Before we ask any questions
  • When you ask questions
    • Choose your forum carefully
    • Stack Overflow
    • Website and IRC forum
    • Second, use the item mailing list
    • Use headings that are meaningful and clearly descriptive
    • Make the question easy to answer
    • Use clear, correct, precise, and grammatically correct sentences
    • Send the problem in an easy to read and standard file format
    • Describe the problem accurately and have something to say
    • Speak not in numbers but in fine words
    • Don’t claim to find bugs
    • Grovelling is no substitute for your lessons
    • Describe the symptoms of the problem, not your guess
    • List the symptoms of the problem by time of occurrence
    • Describe goals instead of processes
    • Don’t ask for a personal email response
    • Articulate your questions and needs clearly
    • When asking questions about the code
    • Don’t post your homework questions
    • Get rid of meaningless question sentences
    • Don’t write urgent in the headline even if you are in a hurry
    • Politeness is not strange, and sometimes helpful
    • After the problem is resolved, add a brief footnote
  • How to interpret the answer
    • RTFM and STFW: How do you know when you’ve totally screwed up
    • If you still don’t get it
    • Handle rude responses
  • How to avoid playing the loser
  • Questions not to ask
  • Good questions and stupid questions
  • If you don’t get an answer
  • How to better answer questions
  • The related resources
  • thanks

The statement

Many projects link to this guide in their help/instruction pages, which is great and we encourage everyone to do the same. But if you are the person responsible for managing the project page, please note in a prominent place near the hyperlink:

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

We have learned all too well how painful it can be to make less of these statements. Because of the lack of a statement, we are constantly being pestered by idiots. These idiots think that since we publish this guide, we are responsible for solving all the technical problems in the world.

If you read this guide for some kind of help and walk away thinking you can get direct help from this writer, you’re one of those idiots we talked about earlier. Don’t ask us questions. We’ll just ignore you. What we’re doing in this guide is showing you how to get help from someone who really understands the software or hardware problem you’re having, and 99% of the time that’s not us. Unless you are sure that one of the authors of this guide happens to be an expert in the problem area you are dealing with, please leave us alone and everyone will be happier.

Introduction to the

In the hacker world, whether you end up with a useful answer to a technical question often depends on how you ask and ask. This guide will show you how to ask the right questions to get the right answers.

It’s not just hackers. Now that Open Source software is so prevalent, you can often get good answers from other experienced users, which is a good thing; Users tend to be more tolerant of the problems that newcomers often encounter than hackers. However, treating experienced users as hackers and communicating with them in the ways described in this guide is also the most effective way to get a satisfactory answer from them.

The first thing you should understand is that hackers love challenging questions, or good questions that stimulate their thinking. If we weren’t, then we wouldn’t be the people you want to ask. If you give us a good question to chew on, we’ll be very grateful to you. A good question is the incentive. It’s the gift. Good questions improve our understanding and often reveal things we didn’t realize or think about before. To hackers, “Good question! It was a sincere and strong compliment.

Still, hackers have a bad reputation for being contemptuous or arrogant when it comes to simple questions, which sometimes makes us seem more hostile to the new and ignorant than we really are.

We make no secret of our contempt for those who will not think, or do not do what they should before asking. Those people are time killers — they only want to take, never give, and consume our time with more interesting questions or people more worthy of answers. We call such people losers (wankers) (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 better things to do. We know this, and we never expect everyone to be interested in the technical issues that fascinate us. Still, our style of answering questions is directed towards people who are genuinely interested and willing to take an active part in solving the problem, and that won’t change and shouldn’t. If even that changes, we’re less effective at doing what we do best.

We volunteer (for the most part), taking time out of our busy lives to answer questions, and are often inundated with questions. So we relentlessly filter out topics, especially those that look like losers, in order to spend our time more efficiently answering winners’ questions.

If you hate our attitude, patronizing, or arrogant, try putting yourself in our shoes. We’re not asking you to give in to us — in fact, most of us are more than happy to talk to you as equals and welcome you into our culture as long as you make a small effort to meet the basic requirements. But it’s not efficient for us to help people who aren’t willing to help themselves. It’s okay to be ignorant, but it’s not okay to be an idiot.

So, you don’t have to be technically savvy to get our attention, but you do have to show the traits that lead you to be so savvy, thoughtful, observant, and willing to take an active part in solving problems. If you can’t do these things that set you apart, we recommend spending some money on a technical support service contract with a commercial company, rather than asking individual hackers to help you for free.

If you decide to ask us for help, of course you don’t want to be seen as a loser, much less one of the losers. The best way to get quick, effective answers right away is to ask like winners — smart, confident, problem-solver, but occasionally needing a little help with a particular problem.

(Suggestions for improvements to this guide are welcome. You can email your suggestions to [email protected] or [email protected]. Please note, however, that this article is not a general guide to netithing, and we generally reject suggestions that don’t help us get useful answers in a technical forum).

Before we ask any questions

Before you send technical questions via email, news groups, or chat rooms, do the following:

  1. Try searching for an answer in an old article on the forum where you are going to ask a question.
  2. Try searching the Internet to find the answer.
  3. Try reading the manual to find out.
  4. Try reading the Frequently Asked Questions document (FAQ) to find out.
  5. Try checking or experimenting on your own to find out.
  6. Ask your strong friends to find out.
  7. If you’re a developer, try reading the source code to find out.

When you ask a question, show that you have done the above; This will help establish that you are not an unearned questioner who wastes other people’s time. It’s even better if you can also express what you’ve learned in the process, because we’re more likely to answer questions from people who show they can learn from their answers.

Using strategies such as first googling the various error messages you encounter (Google forums and web pages) will most likely lead you straight to a file or mailing list clue that will solve the problem. Even if it doesn’t, it’s a good thing to ask for help on a mailing list or newsgroup with a sentence that SAYS I googled the following and found nothing useful, even if it just shows what the search engine doesn’t offer. Doing so (plus the searched strings) also allows other people with similar problems to be directed to your question by the search engine.

Don’t worry. Don’t expect a complex problem to be solved in a few seconds of Google search. Read the FAQ again, relax, sit back, and spend some time thinking about the problem before reaching out to the experts for help. Trust us, they’ll tell you how much reading and thinking you’ve done, and if you’re prepared, you’re more likely to get an answer. Don’t ask all your questions because your first search didn’t find the answer (or too many).

Prepare your questions and think them over carefully, because a hasty question will lead to a hasty answer, or no answer at all. The more you can show how much effort you put into solving a problem before asking for help, the more likely you are to get real help.

Be careful not to ask the wrong question. If your questions are based on false assumptions, some J. Random Hacker will probably be thinking silly questions in his mind… “In the hope that you will learn from the answer to the question rather than the answer you want.

Never assume you are qualified to get the answer. You are not; You’re not. After all, you’re not paying anything for the service. You’ll earn an answer yourself by asking thoughtful, interesting, and intellectually stimulating questions — questions that have the potential to contribute to community experience, rather than passively taking knowledge from others.

On the other hand, showing that you’re willing to do something in the process is a great start. Can someone give me a hint? What is missing from my example? And where I should check it is easier to get a response than please post the exact process I need. Because you’ve shown that you have the ability and determination to get things done as long as someone can point you in the right direction.

When you ask questions

Choose your forum carefully

Choose your questions carefully. You are likely to be overlooked or seen as a failure if you do the following:

  • Post your question in a forum that doesn’t fit the topic.
  • Posting very primary issues in forums that explore advanced technical issues; And vice versa.
  • Cross-post the same question on too many different news groups.
  • Send a personal email to someone who is neither an acquaintance nor obligated to solve your problem.

Hackers weed out mis-occasion issues to protect their communication channels from being flooded with irrelevant stuff. You don’t want that to happen to you.

So the first step is to find the right forum. Again, Google and other search engines are still your friend. Use them to find the sites that are most relevant to the hardware and software issues you are experiencing. Usually there are faQs, mailing lists, and links to related documentation. If your efforts (including reading the FAQs) are fruitless, there may be a process or link to bug-reporting on the site, if so, link to it.

Sending emails to strangers or forums is probably the riskiest thing to do. For example, don’t assume that the author of a rich web page will want to be your free consultant. Don’t be too optimistic about how well your question will be received — if you’re not sure, send it elsewhere, or don’t send it at all.

When choosing a forum, news group, or mailing list, don’t put too much faith in the name. Read the FAQ or license to make sure your question is relevant. Scrolling through existing topics before Posting can give you a feel for the culture. In fact, it’s a great idea to search your newsgroup or mailing list history for keywords related to your question in advance, and maybe find the answer. Even if you don’t, it will help you generalize better questions.

Don’t machine-gun all the channels of help at once. It’s as unpleasant as Shouting. One at a time.

Know your subject! One of the most typical mistakes is to ask a question about the Unix or Windows operating system program interface in a forum dedicated to a cross-platform portable language, suite, or tool. If you don’t understand why this is a big mistake, it’s best not to ask anything until you know the difference.

In general, if you ask a question in a carefully selected public forum, you are more likely to get a useful answer than if you ask the same question in a private forum. There are several reasons to support this, based on the number of potential responders and the audience. Hackers are more likely to answer questions that can help a lot of people.

Understandably, sophisticated hackers and authors of popular software are receiving too many mismessages. Like the straw that broke the camel’s back, your inclusion can also push the situation to the extreme – several times, authors of popular software have pulled back from support for their own software because the accompanying flood of unwanted mail into their personal email inbox became unbearable.

Stack Overflow

Search and then ask on Stack Exchange.

In recent years, the Stack Exchange community has become a major conduit for answering technical and other questions, especially for open source projects.

Because The Google index is instant, do a Google search before looking at Stack Exchange. Chances are high that someone has already asked a similar question, and Stack Exchange sites tend to be among the top search results. If you can’t find any answers on Google, you can look at websites related to specific topics. Using tags allows you to narrow down your search results.

Stack Exchange has grown to over 100 sites, and here are the most commonly used:

  • Super User is asking general computer questions. If your question has nothing to do with code or writing programs, but something about connecting to the Internet, please go here.
  • Stack Overflow is asking questions about writing programs.
  • Server Fault is a question about the Server and network management.

Website and IRC forum

Local user groups, or your Linux distribution may be promoting their web forums or IRC channels and offering novice help (in some non-English speaking countries, novice forums are probably also mailing lists) are good places to start asking questions, Especially if you think the problem may be relatively simple or ordinary. The IRC channel, which is sponsored by advertising, is an open place to ask questions and usually gets an immediate response.

In fact, if a problem with a program only occurs in the version provided by a particular Linux distribution (which is common), it’s a good idea to go to that distribution’s forum or mailing list first and then to the program’s own forum or mailing list. The project’s hacker may simply reply, “Use our version.”

Before Posting on any forum, make sure it has a search function. If so, try searching for a few key words of the question. Maybe that will help. If you’ve done a general web search before (and you should), search the forum again. The search engine may not be able to index the entire forum.

There is a growing tendency to provide user support services via forums or IRC channels, and email is mostly reserved for communication between project developers. So it’s best to ask for help with the project in the forum or IRC first.

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

Second, use the item mailing list

When a project provides a developer mailing list, ask questions to the list and not to individual members, even if you’re sure they can best answer your questions. Check the project’s file and home page to find the project’s mailing list and use it. There are several good reasons for this approach:

  • Any questions that are good enough to ask individual developers will also benefit the entire project group. On the other hand, if you think your problem is stupid for the entire project group, that’s no reason to harass individual developers.
  • Asking questions from the list can be a distraction. Individual developers (especially project leaders) may be too busy to answer your questions.
  • Most mailing lists are archived and those that are archived are indexed by search engines. If you ask a question to the list and get an answer, someone else can find your question and answer through a web search in the future and never have to ask 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 the questions are asked in private, no one gets to 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 don’t touch the source code, ask questions to the “users” list or forums. Don’t assume you’re going to be popular with the list of developers who will probably see your questions as a distraction from their development.

However, if you are convinced that your question is unique and haven’t been answered in days on the “users” list or forum, try going to the “developers” list or forum to ask. It is recommended that you look in the background for a few days before Posting to see how things work (in fact this is a good idea to participate in any private or semi-private list)

If you can’t find a mailing list for a project and can only find the E-mail address of the project maintainer, send him a message. Even in that case, don’t assume the mailing list doesn’t exist. In your email, state that you’ve tried but couldn’t find a suitable mailing list. Also mention that you have no objection to forwarding your emails to others. (Many people believe that private emails shouldn’t be made public, even if they’re not secret. By allowing your email to be forwarded to others, you give the appropriate person the choice of what to do with your email.

Use headings that are meaningful and clearly descriptive

On mailing lists, news groups, or forums, a headline of around 50 words or less is a great opportunity to grab the attention of a senior expert. Don’t use chattering help, kneel beg, urgent (more don’t say help ！！！！ So offensive, the title is reflexively ignored) to squander the opportunity. Don’t try to impress us with your level of pain. Instead, use a very brief description to ask questions in this space.

A good example of a title is a target-differentiated description, which is what many tech support organizations do. The target section points out which thing or group of things are at fault, and the difference section describes the inconsistency with the expected behavior.

Stupid question: Help! My laptop doesn’t display properly!

Smart problem: mouse cursor of X.org 6.8.1 is distorted, certain card’s MV1005 chipset.

Smarter problem: the mouse cursor of X.org 6.8.1 is deformed in a certain card’s MV1005 chipset environment.

The process of writing objective – differential descriptions helps you organize careful thinking about the problem. What was affected? Is it just a mouse cursor or something? Only in version X of X.org? Or just in version 6.8.1? Is it for a certain card chip set? Or just one of these MV1005 models? A hacker can look at your environment and instantly understand your problems.

To summarize, imagine that you are searching through an archive Thread index that displays only titles. Make your title a better reflection of the question, so that the next person who searches for a similar question can focus on the discussion string without having to ask the same question again.

If you want to ask a question in your response, be sure to change the title to show that you are asking a question. A title that looks like Re: Test or Re: New Bug is not likely to get enough attention. In addition, using appropriate references and cutting back on previous passages without compromising continuity can leave clues for new readers.

For discussion threads, don’t just click reply to start a whole new discussion thread, this will limit your audience. Because some mail readers, such as Mutt, allow users to sort by discussion string and hide messages by folding the discussion string, the person doing so will never see your message.

Just changing the title is not enough. Mutt and other mailer programs also check for information beyond the subject line of a message to specify a discussion string for it. So instead send a brand new email.

On a web forum, a good way to ask questions is slightly different, because discussion strings are tied to a particular message, and often you can’t see the content outside the discussion string, so it’s acceptable to respond to the question rather than change the title. Not all forums allow separate headers in replies, and if they do, almost no one will read them. By responding to questions, however, this is itself ambiguous, since they will only be read by the person who is looking at the headline. So, unless you just want to ask questions among the people currently active in the discussion, it’s better to start from scratch.

Make the question easy to answer

Please send your reply to… To end your question will probably leave you unanswered. If it’s too much trouble to take a few seconds to set up a reply address on your email client, we think it’s even more trouble to take a few seconds to think about your question. If your email program doesn’t support this, get a better one; If your operating system doesn’t support it, get a better one.

In forums, it’s very rude to ask for an email response, unless you think the message might be sensitive (someone might, for some unknown reason, let you know and not the whole forum). If you just want to get an email alert when someone replies to a discussion string, ask the web forum to send it to you. Almost all forums support functions such as tracking this discussion string and sending email alerts when a reply is received.

Use clear, correct, precise, and grammatically correct sentences

We know from experience that sloppy questioners are also sloppy programmers and thinkers (I’m sure). It is not worth answering the questions of the unwary, we would rather spend our time elsewhere.

Correct spelling, punctuation and capitalization are important. In general, if you’re too bothered to care about it, we’re too bothered to care about it. Put extra effort into your words and don’t be too rigid and formal — in fact, hacker culture values the accurate use of informal, slang, and humor. But it has to be accurate and show signs that you are thinking and paying attention.

Spell, punctuate, and capitalization correctly. Do not confuse its for it’s, loose for lose, or discrete for discreet. Don’t use all caps, it’s considered rude to shout (all caps aren’t much better because they’re hard to read. Alan Cox may be able to do that, but not you).

To put it more bluntly, if you write as if you are semi-literate, chances are you won’t get any attention. Don’t use instant messaging abbreviations or jargon, either. Reducing “to” d “will make you look like a simpleton trying to skip a few keys. What’s worse, if you scrawl like a child, you’re looking for death, and you’re sure to get no attention (or, at best, plenty of criticism and sarcasm).

If you’re asking questions in a forum where you’re not speaking your native language, it’s ok to make a few spelling and grammar mistakes, but never sloppy thinking (and yes, we can usually tell the difference). Also, unless you know the language of the respondent, please write in English. Busy hackers tend to simply delete messages written in languages they don’t understand. English is the common language on the Internet, and writing in English minimizes the likelihood that your question will be deleted before it has been read.

If English is your Second language, it’s a good idea to hint potential responders that you have potential language difficulties:

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

  • English is not my native language, please forgive my typos or grammar.

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

  • If you speak a language, please send me a letter/private message. I need someone to help me translate my questions.

I am familiar with the technical terms, but some slang expressions and idioms are difficult for me.

  • I am familiar with the technical terms, but not with the colloquial expressions or the special ones.

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 write my questions in one language and in English, and if you answer in only one language, I will be happy to translate it into the other.

Send the problem in an easy to read and standard file format

If you make a question artificially difficult to read, it will probably be ignored and people will read more intelligible questions, so:

  • Use plain text instead of HTML (it’s not hard to turn off HTML).
  • Using MIME attachments is usually ok, provided there is actual content (such as the attached source code or patch) and not just a template generated by the mail program (such as just a copy of the letter content).
  • Don’t send an email with a single line of text that automatically wraps into multiple lines (making it difficult to respond to parts of the text). Assuming your readers are reading emails on 80-character wide terminals, it’s best to set your newline split point to less than 80 words.
  • However, do not set fixed widths for 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 what you are seeing.
  • In An English forum, do not useQuoted-PrintableMIME codes send messages. This encoding may be necessary for Posting non-ASCII languages, but many mail programs do not support it. When they deal with newlines, those that are scattered around in the text= 20Symbols are ugly and distracting, and may even undermine the meaning of the content.
  • Never, ever expect hackers to read a document written in a closed format, such as Microsoft Word or Excel. Most hackers react to this the way you would if someone dumped steaming pig manure on your doorstep. Even if they could handle it, they hated it.
  • If you send email from a Computer using Windows, turn off Microsoft stupidSmart quotesFrom [Options] > [Edit] > [Autocorrect Options], check it offSmart quotesRadio box) to avoid spamming your email with spam characters.
  • In the forum, do not abuseemoticonsandHTMLFeatures (as they are provided). An emoji or two is usually fine, but fancy coloured text tends to make people think you’re incompetent. Excessive use of emojis, colors and typography can make you look like a smirking little girl. This is usually not a good idea, unless you’re just interested in the sex and not the answer.

If you’re using a graphical user interface mail program (like Microsoft Outlook or something similar), be aware that their default Settings don’t necessarily meet these requirements. Most of these programs have a click-based view source code command that checks the mail in the send folder to make sure it’s a plain text file and there are no weird characters.

Describe the problem accurately and have something to say

  • Carefully and clearly describe the symptoms of your problem or Bug.
  • Describe the environment in which the problem occurred (machine configuration, operating system, application, and related information), and provide the distributor’s distribution and version number (e.g.Fedora Core 4,Slackware 9.1, etc.).
  • Describe how you researched and understood the problem before you asked it.
  • Describe the diagnostic steps taken to identify the problem prior to questioning.
  • Describe what hardware or software changes have been made recently that may be relevant.
  • If possible, provide one that canRecreate the controlled environment of the problemMethods.

Try to anticipate how a hacker might ask you back, and answer any questions the hacker might have before you ask them.

Of the above points, it is especially important to give the hacker an environment in which to reproduce your problem when you are reporting a problem that you think might be in the code. When you do this, your chances and speed of getting an effective response are greatly improved.

Simon Tatham wrote an excellent article called how to Report Bugs Effectively. I highly recommend you read it.

Speak not in numbers but in fine words

You need to provide accurate and informative information. This does not mean that you simply transcribe piles of error code or data into your questions. If you have a large, complex test sample that can reproduce a failure, tailor it as small as possible.

This would be useful in at least three ways. First, showing that you have made an effort to simplify the question increases your chances of getting an answer. Second, simplifying the question makes you more likely to get a useful answer; Third, in the process of refining your bug reports, you will most likely find a fix or a stopgap on your own.

Don’t claim to find bugs

When you have a problem with your software, don’t claim to have found a Bug unless you are very, very justified. Tip: Unless you can provide a source code patch to fix the problem, or provide regression tests to show that the behavior was incorrect in the previous release, you are probably not completely sure. The same applies to web pages and files. If you find a Bug in the file, you should be able to provide a fix or replacement file in the appropriate location.

Remember, there are plenty of other users who don’t have the same problems that you did, or you would have found them while reading documents or searching the web (you did that before you complained, right?). . This also means that it’s more likely that you’re wrong than the software itself.

People who write software work very hard to make it as perfect as possible. If you claim to have found a Bug, you are questioning their abilities, and even if you are right, you may offend some of them. This is especially true when you’re Shouting about bugs in the title.

When asking questions, even if you’re privately pretty 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 it in the replies. This way, if there is a Bug, the maintainer will apologize to you, which is better than annoying someone and then owe them an apology.

Grovelling is no substitute for your lessons

Some people understand that they shouldn’t ask rude or arrogant questions and demand answers, but they opt for the other extreme — groveling: I know I’m just a pathetic novice, a jerk, but… . This is confusing but useless, especially when 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 the situation in question as clearly as possible. This positions you better than groveling.

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, not your guess

It is not helpful to tell hackers how you think the problem was caused. (If your reasoning is so valid, why ask for help?) “, so make sure you’re telling them exactly the symptoms of the problem, not your explanations and theories; Let the hackers speculate and diagnose. If you think it’s important to state your guesses, be clear that it’s just your guesses and describe why they don’t work.

Stupid question

I am running into a series of SIG11 errors while compiling the kernel. I suspect that one of the flywires is on the motherboard route. How best to check this situation?

Smart question

My assembly computer is fIC-PA2007 mainframe board with AMD K6/233 CPU (Via Apollo VP2 chipset), 256MB Corsair PC133 SDRAM memory, when compiling the kernel, SIG11 errors occurred frequently after 20 minutes of startup, but the same problem never occurred in the first 20 minutes. Rebooting won’t help, but shutting it down overnight will work for another 20 minutes. All the memory has been changed. No effect. The standard compilation records for the relevant sections are as follows… .

Since this may seem difficult for many people to cooperate with, here’s a reminder: All the diagnosticians are from Missouri. The official motto of the State Department is “Let me see” (From Congressman Willard D. Vandiver in 1899: “I come from a nation of corn, cotton, burdock and Democrats, and I will neither be persuaded nor satisfied by eloquent words.” I’m from Missouri, you have to show me. For the diagnosist, this is not a doubt, but a real and useful need for them to see what is as consistent as possible with the original evidence you see, rather than your guesses and generalizations. So show us!

List the symptoms of the problem by time of occurrence

A series of operations before a problem occurs are often the most helpful clues to find out the problem. Therefore, your instructions should include the steps you took and how the machine and software reacted until the problem occurred. In the case of command line processing, it can be helpful to provide a record of an action, such as that generated by running a scripting tool, and to refer to a number of relevant lines, such as 20.

If the failed program has diagnostic options (such as the -v detail switch), try selecting these options to add debugging information to the record. Remember, more is not better. Try to choose the appropriate level of debugging to provide useful information rather than drown the reader in garbage.

If your explanation is long (say, more than four paragraphs), it helps to outline the problem at the beginning and then go into chronological detail later. So hackers will know what to look out for when they read your notes.

Describe goals instead of processes

If you want to figure out how to do something (other than report a Bug), describe your goal at the beginning, then state the specific steps to reproduce what you’re stuck on.

People who often turn to technology have a higher goal in mind, and they get stuck on a particular path that they think will lead to that goal, and then come asking how to get there without realizing that there is something wrong with that path. It turned out to be a lot of work.

Stupid question

How can I get the hexadecimal RGB value from the color selector of a drawing program?

Smart question

I’m trying to replace the color table of an image with a color code of my choice. The only way I know is to edit each table slot, but I can’t get the hexadecimal RGB value from the color picker of a drawing program.

The second way to ask a question is smarter, and you might get a response that suggests another, more appropriate tool.

Don’t ask for a personal email response

Hackers believe that the process of fixing problems should be open and transparent, and that the initial response can and should be corrected if someone with more experience notices incompleteness or improprieties. At the same time, the helper is rewarded by his ability and knowledge being seen by others in the profession.

When you request a private response, both the process and the reward are suspended. Don’t, leave it up to the respondent to decide whether to answer in private — if he does, it’s usually because he thinks the question is too poorly written or too shallow to be of interest to anyone else.

There is a limited exception to this rule. If you are convinced that your question will likely elicit a large number of similar responses, the magic question sentence is to email me, and I will summarize those responses for the forum. It’s very polite to try to save a mailing list or news group from a flood of identical responses — but you have to keep your word.

Articulate your questions and needs clearly

Endless questions are an almost endless black hole of time. The people most likely to give you useful answers are also often the busiest (they’re busy because they have to do most of the work themselves). Such people have a distaste for the unbridled black hole of time, so they tend to dislike open-ended questions as well.

You are most likely to get a useful answer if you state exactly what you want the respondent to do (provide a guide, send a piece of code, check your patch, etc.). Because this will set a limit of time and effort, so that the respondent can focus on helping you. That’s great.

To understand the world of experts, think of expertise as a resource in abundance and time to respond as a scarce one. The less time you ask for from them, the more likely you are to get answers from a truly professional and busy expert.

So, defining your question to minimize the amount of time it takes the expert to identify your question and answer is a technique that can help you with your useful answers — but it’s often different from simplifying the question. So, if I want to understand X better, can you give me a better explanation? It’s usually better than asking can you explain X? For the better. If your code doesn’t work, it’s usually smarter to ask someone else to see what’s wrong than to ask someone else to fix it for you.

When asking questions about the code

Don’t ask someone to help you debug broken code without 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 Posting a few dozen lines of code and saying: After line seven, I expect it to say

, but what actually appears is

is more likely to get you a response.

The most effective way to describe program problems is to provide the minimalist buggy presentation test case. What are the minimal test cases? That’s a microcosm of the problem; A small snippet of a program can be just enough to show the unusual behavior of the program without any other distractions. How to make test cases minimal? If you know which line or piece of code is causing the abnormal behavior, copy it and add enough code to reproduce the situation (for example, enough code to be compiled/rendered/processed by the application). If you can’t reduce the problem to a specific block, make a copy of the code and remove the parts that don’t affect the behavior causing the problem. In general, the smaller the test cases, the better (see the “Not too many, not too many” section).

In general, it is not easy to get a fairly concise set of test cases, but it is a good habit to always try to do so first. This will help you understand how to solve the problem on your own — and even if your attempt is unsuccessful, hackers will see that you put some effort into trying to get an answer, which will make them more willing to work with you.

If you simply want someone to Review the code, say so at the beginning of the letter, and be sure to mention which parts of the code you think need special attention and why.

Don’t post your homework questions

Hackers are good at telling which problems are homework problems; Because most of us have worked this out on our own. Again, it’s up to you to solve these problems, and you’ll learn from them. Ask for hints, but don’t ask for a complete solution.

If you suspect you have a homework problem but still can’t solve it, try asking in a user group, forum or (last resort) on the project’s user mailing list or forum. Although hackers will see it, some experienced users may still give you some hints.

Get rid of meaningless question sentences

Avoid ending your question with a nonsensical phrase such as can anyone help me? Or is there an answer? .

First of all: If your description of the problem is not very good, it will only add to the problem.

Second: Hackers get tired of asking questions like this because they’re adding to the cake — and often show their contempt with logically correct but meaningless answers, such as yes, someone can help you or no, there’s no answer.

In general, avoid yes or no, right or wrong, with or without type questions unless you want a yes or no type answer.

Don’t write in the headline even if you’re in a hurryemergency

This is your problem, not ours. Claims of urgency are most likely to backfire: most hackers simply remove issues that are offensive and seliciously intended to draw immediate attention to them. What’s more, the word “urgent” (or any other attention-seeking headline) usually gets picked up by spam filters — and the person you’re hoping to see your problem may never see it.

With half the exception, if you’re somewhere high profile that’s going to excite hackers, it’s probably worth it. In this case, if you are under time pressure and mention it politely, people may be interested in answering quickly.

Of course, that’s a big risk, because hackers are probably excited about something different than you are. It’s fine to send a headline from NASA’s International Space Station, for example, but not for feel-good charity or political reasons. In fact, posts like Urgent: Help me save this fluffy baby seal! Sure to get ignored or annoyed by hackers, even if they think furry seal pups are important.

If you find this surprising, it’s best to read the rest of the guide several times until you understand it before you post.

Politeness is not strange, and sometimes helpful

Thank you for your attention. Let everyone know that you appreciate their time and help for free.

Frankly, this isn’t as important (and can’t replace) as clear, correct, accurate, and legitimate grammar and avoiding proprietary formatting. Hackers would rather read an abrupt but technically clear Bug report than a polite but vague one. (If this puzzles you, remember that we value questions by what they can teach us.)

However, if you have a list of problems to solve, being polite will definitely increase your chances of getting a useful response.

(We’ve noticed that the only serious flaw feedback we’ve gotten from experienced hackers since this guide was published is the thank you in advance line. Some hackers think that thanks in advance means they don’t have to thank anyone for the hint later. Our advice is to either say thank you first and then thank the responder later, or to express gratitude in a different way, such as thanks for your attention or consideration.)

After the problem is resolved, add a brief footnote

When the problem is resolved, send a note to everyone who helped you to let them know how the problem was resolved and thank them again. If the problem is getting a lot of attention in a newsgroup or mailing list, it’s appropriate to post a note there.

Ideally, reply to this message to the topic on which the original question was asked, with a clear flag in the title indicating that it has been fixed, resolved, or some other equivalent. On a busy mailing list, a potential ringer who sees the discussion string problem X and problem X – solved understands that there is no time to waste (unless he personally finds problem X interesting) and can therefore use the time to solve other problems.

Add-ons don’t have to be long or deep; A simple hello, the original is a problem with the network cable! Thank you — Bill is better than coming without saying anything. In fact, unless the conclusion is really technical, a cute short summary is better than a long one. Explain how the problem was solved, but you don’t need to repeat how it was solved.

For in-depth questions, it is helpful to post a summary of the debug record. Describe the final state of the problem, what solved the problem, and only after that point can you identify the blind spots that can be avoided. The section on avoiding blind spots should be placed after the correct solution and other summary material, rather than the information in a detective story. Listing the names of those who have helped you will help you make more friends.

In addition to being polite and informative, this type of supplement can also benefit others who search mailing lists/newsgroups/forums for real solutions to your problems.

At the very least, this supplement helps everyone involved get satisfaction from solving the problem. If you’re not a technologist or hacker yourself, trust us, this feeling is very important to the gurus or experts you turn to for help. It can be frustrating to have questions unanswered; Hackers are eager to see the problem solved. Good people get rewarded, satisfy their desires, and you’ll enjoy it 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 it would be helpful to write a document or add a frequently Asked question (FAQ). If so, send them to the maintainer.

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

How to interpret the answer

RTFM and STFW: How do you know when you’ve totally screwed up

There is an old and sacred tradition that if you receive a response from RTFM (Read The Fucking Manual), The respondent thinks you should Read The Fucking Manual. Of course, he’s basically right, and you should read it.

RTFM has a young relative. If you get a response from STFW (Search The Fucking Web), The respondent thinks you should Search on The Fucking Web. He’s probably right, too. Go search. (A kinder way to put it is that Google is your friend!)

In the forum, you may also be asked to climb the forum’s old posts. In fact, someone might even be eager to provide you with a discussion strand of previous solutions to this problem. But don’t rely on this kind of attention. Do a research on old articles before asking questions.

Usually, the person who answers with one of these two sentences will give you a manual or a web address that contains what you need, and they are reading it when they type it. These responses imply that the respondents believe that

  • The information you need is readily available;
  • You can learn more by searching for this information on your own than by being fed it to you.

You shouldn’t feel bad about it; By the hacker’s standards, he has shown a degree of interest in you, rather than turning a blind eye to your demands. You should thank him for his grandmotherly kindness.

If you still don’t get it

If you don’t understand the response, don’t immediately ask for an explanation. Do what you’ve done before when you’re trying to solve a problem on your own (using manuals, FAQs, the Internet, the best people around you), and try to understand the responses first. If you really need an explanation, show that you’ve learned something.

For example, if I say to you: It looks like Zentry is stuck; You should clear it first. “And then, this is a bad response to a follow-up question: What is Zentry? A good question would be: Oh ~~~ I’ve read the instructions, but only zentries are mentioned in the -z and -p parameters, and there is no clear explanation of how to clear it. Do you mean either of the two? Or am I missing something?

Handle rude responses

Much of what seems offensive in the hacking community is not meant to be offensive. Instead, it’s a direct, point-to-point communication style that focuses more on solving problems, rather than making people feel comfortable but vague.

If you feel offended, try to react calmly. If someone does something outrageous, the older guys on mailing lists, news groups, or forums will probably greet them. If this doesn’t happen and you get angry, the person you’re angry with may seem normal in the hacker community, and you’ll be seen as the one at fault, which hurts your chances of getting information or help.

On the other hand, you will occasionally encounter real rudeness and boredom. On the contrary, it is acceptable to hit the real offender hard and tear him to pieces with sharp language. However, be very, very well founded before you do anything. There’s a fine line between correcting an offensive remark and starting a pointless war of words, and it’s not uncommon for hackers to foolishly cross the line themselves. If you’re new or an outsider, your chances of avoiding such a rash move are not high. If you want to get information, not kill time, it’s best not to risk putting your hands on the keyboard.

(Some assert that many hackers have a mild form of autism or Asperger’s syndrome, lacking the skills needed to lubricate human society. This may be true or false. If you’re not a hacker yourself, you might be able to cope with our wacky behavior by thinking we’re crazy. Just do it. We don’t care. We like the way we are, and often have a valid suspicion of patient markers).

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

In the next section, we’ll talk about another issue, the offense you can take when you misbehave.

How to avoid playing the loser

There are a few times in the hacker community’s forums where you might mess up — in the way described in this guide or something similar. You’ll be told in public how you messed up, perhaps with a little color in the attack.

When this happens, the worst thing you can do is moan about what happened to you, claim to have been verbally assaulted, demand an apology, scream loudly, choke, threaten legal action, complain to their employer, leave the toilet seat on, etc. Instead, here’s what you should do:

Get over it. That’s normal. In fact, it’s healthy and reasonable.

Community standards are not self-sustaining; they are maintained through active and public implementation by participants. Don’t cry. All criticism should be sent privately by email. It doesn’t work that way. It doesn’t help to insist that you are personally attacked when someone comments on a statement you’ve made or disagrees with you. These are the attitudes of a loser.

There are other hacker forums, too, that are misdirected by high etiquette requirements, prohibiting participants from Posting anything that is critical of other people’s posts, and stating that if you don’t want to help users, shut up. As a result, thoughtful participants are leaving, which only reduces them to meaningless chatter and useless tech forums.

Hyperbole: Do you want to be “nice” (in the above manner) or useful? Pick one out of two.

Remember: When a hacker says you screwed up and (no matter how stridently) tells you to stop doing it, he is 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 do that, at least act with some dignity, don’t whine, and don’t expect to be treated like a fragile doll just because you’re a theatrics super-sensitive soul and a self-entitled newcomer.

Sometimes, even if you don’t screw up (or just imagine you screw up), someone will attack you personally for no reason. In this case, complaining can really screw up the problem.

The people who come to the trouble are either incompetent buggers who think they’re experts, or psychologists testing whether you’re really going to screw up. Other readers either ignore them or have their own way with them. These troublemakers are making trouble for themselves, don’t worry about that.

Don’t get yourself involved in a war of words either, and it’s best to ignore most of them — until you check that they’re just words, don’t point out where you messed up, and don’t subtly hide the real answer behind them (which is possible).

Questions not to ask

Here are some classic silly questions and what the hacker is thinking when he doesn’t answer them:

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

Question: How do I do Y with X?

Question: How do I set my shell prompt?

Question: Can I convert an AcmeCorp file to TeX format using the Bass-O-Matic file conversion tool?

Problem: My program/setup /SQL statement is not working

Q: I have a problem with my Windows PC. Can you help me?

Problem: my program won’t move, I think there is a problem with system tool X

Q: I am having trouble installing Linux (or X), can you help me?

Question: How can I break root/steal OP privileges/read other people’s emails?

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

Answer: Right where I found it, idiot — at the end of the search engine. Oh my god! Is there anyone out there who doesn’t know how to Google?

Question: How do I do Y with X?

Answer: If you want to solve Y, don’t ask questions in a way that may 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 that he or she is imprisoned by the particular situation. It is best to ignore such people and wait for them to figure out the problem.

Question: how do I set my shell prompt?

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

Question: Can I convert an AcmeCorp file to TeX format using the Bass-O-Matic file conversion tool?

Answer: Just try and see. If you had, you’d know the answer, and you wouldn’t have wasted my time.

Problem: my {program/setup /SQL statement} is not working

Answer: It’s not really a question. I’m not interested in asking you twenty questions to find the real question — I’ve got better things to do. When I see this kind of question, I usually have one of three reactions

  • Do you have anything to add?
  • That’s too bad. I hope you can handle it.
  • What do I care?

Q: I have a problem with my Windows PC. Can you help me?

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

Note: If the program has an official Windows version or interacts with Windows (such as Samba), you can ask windows-related questions, just don’t be surprised if the response is that the problem is caused by the Windows operating system and not the program itself. Because Windows generally sucks, and that’s usually true.

Problem: my program won’t move, I think there is a problem with system tool X

Answer: It’s entirely possible that you’re the first to notice obvious flaws in the system calls and library files that are used repeatedly by thousands of users. It’s more likely that you have no basis at all. Extraordinary claims require extraordinary evidence, and when you make such claims you must back them up with clear and detailed documentation of the defects.

Q: I am having trouble installing Linux (or X), can you help me?

Answer: No, I can only find the problem by working on your computer myself. Go to your local Linux user group for practical guidance (you can find a list of user groups here).

Note: If installation issues are related to a Linux distribution, it may be appropriate to ask questions on its mailing list, forums, or local user groups. At this point, describe the exact details of the problem. Until then, do a careful keyword search using Linux and any suspected hardware.

Question: How can I break root/steal OP privileges/read other people’s emails?

Answer: If you want to do so, you are a despicable person. If you want a hacker to help you, you’re an idiot!

Good questions and stupid questions

Finally, I’ll show you how to ask smart questions by giving some examples; Two ways of asking the same question are put together, one is foolish and the other is wise.

Stupid question:

Where can I find information about Foonly Flurbamatic?

This is what STFW wants to say.

Smart question:

I googled “Foonly Flurbamatic 2600” but found nothing useful. Who knows where to find the information to program such a device?

This issue has been passed by STFW, it seems that he is really in trouble.

Stupid question:

The source code I got from the Foo project doesn’t compile. Why is it so bad?

He thinks it’s someone else’s fault, this arrogant, arrogant questioner.

Smart question:

The foo project code does not compile in Nulix 6.2. I’ve read the FAQ, but it doesn’t mention Nulix. This is a record of my compilation process. Did I do something wrong?

The questioner has pointed out the circumstances, read the FAQ, listed the errors, and he is not blaming anyone else for the problem. His problem deserves attention.

Stupid question:

I have a problem with my motherboard. Who’s going to help me?

A hacker’s usual response to such questions is: Ok, and a pat on the back and a diaper change? “And then press the delete key.

Smart question:

I tried X, Y and Z on the S2464 motherboard, but it didn’t work, so I tried A, B and C. Notice what happens when I try C. Apparently Florbish is grommicking, but with surprising results. What causes grommicking in general on Athlon MP motherboards? Does anyone know what tests I should run next to find out?

This guy, on the other hand, deserves an answer. He has shown an ability to solve problems rather than waiting for answers.

In the last question, note the subtle but important difference between telling me the answer and giving me a hint of what else I should be doing to diagnose.

In fact, the latter question arose from an actual question on the Linux kernel mailing list (LKML) in August 2001. I (Eric) was the one who asked the question. I have observed this unexplained locking on the Tyan S2464 board and the list members have provided important information on how to resolve the issue.

By the way I ask questions, I give people something to chew on; I try to make it easy for people to get involved and get involved. I showed that I was as capable as they were and invited them to discuss it with me. By telling them about the detours I’ve come to, so they don’t waste any more time, I show respect for their valuable time.

Afterwards, as I thanked everyone and appreciated the good discussion, one member of the Linux kernel mailing list said he thought my problem was solved not because I was famous on the list, but because I asked the question in the right way.

Hackers are, in a sense, knowledgeable but impersonal guys; I’m sure he’s right. If I ask questions like a beggar, no matter who I am, someone is going to piss me off or be ignored. He suggested that I write it down, which led directly to this guide.

If you don’t get an answer

If you do not receive an answer, please do not assume that we feel unable to help you. Sometimes it’s just that the person who sees your question doesn’t know the answer. Not responding doesn’t mean you’re being ignored, though admittedly the difference is hard to tell.

In general, simply reposting questions is a bad idea. This will be seen as meaningless noise. Be patient. The person who knows the answer to your question may live in a different time zone, may be sleeping, or may have been poorly organized in the first place.

You can get help from other sources, which are often more suited to the needs of beginners.

There are many online and local user groups made up of passionate software enthusiasts (even though they may never have written any software themselves). Usually people form such groups to help each other and to help newcomers.

In addition, there are many business companies, large and small, that you can turn to for help. Don’t feel bad about having to pay for help! After all, if your car’s cylinder seal bursts, which it probably does, you’ll still have to take it to a garage and pay for the repair. Even if the software doesn’t cost you a dime, you can’t insist that tech support is always free.

For mass-market software like Linux, there are at least tens of thousands of users per developer. It is impossible for one person to handle the calls from thousands of users. Keep in mind that even if you have to pay for this assistance, it will be a fraction of what you are paying for similar software (usually the cost of technical support for closed source software is much higher than for open source software, and the content is not as rich).

How to better answer questions

Be nice. The stress of questions often makes people seem rude or stupid when they are not.

Respond privately to first-time offenders. There is no need to publicly humiliate those who are honest about their mistakes. A true novice may not even know how to search or where to look for common questions.

If you’re not sure, say something! A false reply that sounds authoritative is worse than none. Don’t give people directions just because it’s fun to sound like an expert. Be humble and honest, setting a good example to questioners and peers alike.

If you can’t help, don’t stand in his way. Don’t joke about the actual steps, which might ruin the user’s setup – some poor nerd will take it as a real command.

A probing rhetorical question to elicit more details. If you do it well, the questioner can learn something — and so can you. Try to turn stupid questions into good ones. Remember we were all beginners at one time.

While it’s legitimate to complain about RTFM to those slackers, it’s better to be able to point out the location of a file (even if it’s just to suggest a Google search term).

If you decide to answer, give a good answer. Don’t suggest clumsy workaround when someone else is using the wrong tool or approach. Recommend better tools and redefine the problem.

Answer the question head-on! If the questioner has done A lot of research and shows that they have tried X, Y, Z, A, B, C and got no results, it doesn’t help to say try A or B or try X, Y, Z, A, B, C with A link.

Help your community learn from the problem. When answering a good question, ask yourself how can you modify the relevant file or FAQ file so that you don’t have to answer the same question again? , and then send a patch to the file maintainer.

If you’ve done some research to answer, 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.

The related resources

If you need a basic knowledge of how PCS, Unix systems, and networks work, see Unix Systems and Networks Fundamentals.

When you distribute software or patches, try to follow software distribution practices.

thanks

Evelyn Mitchel contributed some examples of silly questions that inspired the writing of the section on how to answer them better, and Mikhail Ramendik contributed some particularly valuable suggestions and improvements.