This page has been robot translated, sorry for typos if any. Original content here.

How to ask questions

(This is a cached copy; the original was at If you notice the obsolescence of this copy, or restored the original source, please write to the webmaster of this site.)

Eric Steven Raymond Thyrsus Enterprises < >

Rick Moen < >

Copyright © 2001 Eric S. Raymond

Translation into Russian: Copyright © 2002-2005 Valery Kravchuk

Chronology of versions:

  • Version 3.1 - October 28, 2004 (Added: 'Google is your friend!')
  • Version 3.0 - February 2, 2004 (Substantial addition of discourse on the etiquette of communication in web forums.)

Translations of this document are available in Chinese , Czech , Danish , Estonian , French , German , Hebrew , Hungarian , Italian , Japanese , Polish , Russian , Spanish , Swedish and Turkish . If you want to copy, maintain a mirror, translate or quote this document, please read my copying rules .


On the sites of many projects in the sections on how to seek help, links are provided to this document. This is good, it is for this purpose that it is intended, but if you are a webmaster intending to add such a link on the page of your project, please indicate beside the link in a prominent place that we are not a support service for your project!

We have learned by bitter experience that, in the absence of such a warning, we will be constantly harassed by idiots who believe that the publication of this document obliges us to solve all the technical problems in the world.

If you are reading this document because you need help, and in the end it seems to you that you can get it directly from the authors, then you are one of these idiots. Do not ask us questions. We will simply ignore them. Our goal is to show you how to get help from those who understand the software or hardware with which you work, but in 99% of cases, we will not be those who understand. If you don’t know for sure that one of the authors is an expert in what you are dealing with, leave us alone and this will make everyone better.


In the world of hackers , the style of the answers you get to the technical questions asked depends on how you ask questions no less than on their complexity. This guide will teach you to ask questions in ways that increase the likelihood of a satisfactory answer.

Now that open source software has become widespread, you can often get answers from other, more experienced users, rather than hackers. It's good; Users are usually a little more tolerant of mistakes that beginners often make. But, if you turn to experienced users as hackers, in accordance with the recommendations presented here, this will be the most effective way to get useful answers from them.

First of all, it is necessary to understand that hackers really like difficult problems and good, capable of stirring up brains, questions about these problems. If we didn't like it, we would not be hackers. If you ask us an interesting question that requires prolonged reflection, we will be grateful for it; good questions are an incentive and a gift. Good questions help to better understand the subject and often reveal problems that have not previously been noticed or that have not been thought of. From the mouth of a hacker: "Good question!" - This is a big and sincere compliment.

Despite this, it is believed that hackers relate to simple questions rather hostile or arrogant. Sometimes it seems that we are rude enough to newbies and ignore them. But actually it is not.

We are, without a doubt, hostile to people who are supposedly unwilling to think or learn before asking questions. Such people kill time - they take, without giving anything in return, they take time, which we could devote to another question, more interesting, and another person, more worthy of an answer. We call such people "losers" (for historical reasons this word is sometimes written as "lusers" - users-losers).

We understand that many people just want to use the software we are creating, and are not going to learn the technical details at all. For most, a computer is just a tool, a means to an end; they have more interesting activities and other problems in life. We recognize this and do not expect that everyone will be interested in technical nuances that are so attractive to us. Nevertheless, our style of answering questions is suitable for people who are really interested in this and who want to be active participants in the problem-solving process. This will not change. Yes, and should not change; otherwise, we cannot effectively do what we are best at.

We (mostly) are volunteers. We devote time to our hard life to answering questions, and at times we do not cope with a flurry of questions. Therefore, we have to ruthlessly "filter the market." In particular, discard the questions of potential losers in order to spend the time allotted for answers more effectively, devoting it to the winners.

If this position seems funny, arrogant or arrogant, you are mistaken. We do not ask you to pray for us - in fact, most of us would like to communicate with you on an equal footing and accept you in our culture if you make the necessary efforts to do so. But for us it is simply ineffective to try to help people who do not want to help themselves. Being rude is normal, but pretending to be an idiot is not.

So, although it is not at all necessary to be technically competent, in order to qualify for our attention, it is necessary to demonstrate the qualities that enable one to become competent - attentiveness, thoughtfulness, observation, and a desire to actively participate in the development of a solution. If you cannot accept this kind of discrimination, it makes sense to pay someone for commercial support, rather than asking the hackers to help you personally with the gift.

If you decide to ask us for help, do not become a loser. And do not behave like a loser. The best way to get a quick and sensitive answer is to ask how a person is intelligent, confident and knowledgeable, who just needed help in solving one particular problem.

(Additions to this manual are welcome. Suggestions can be sent to . Please note, however, that this document was not created as a general guide to netiquette , and I usually ignore suggestions that are not directly related to obtaining useful answers in a technical forum .)

Before asking ...

Before asking a technical question via e-mail or discussion group, chat or forum, do the following:

  1. Try to find the answer by searching the web.

  2. Try to find the answer in the manual.

  3. Try to find the answer in the list of frequently asked questions (FAQ).

  4. Try to find the answer by checking or experimenting.

  5. Ask an experienced friend.

  6. If you are a programmer, try to find the answer by analyzing the source code.

When asking a question, indicate from the very beginning that you have already done all this; it will help you to understand that you are not some kind of lazy, devouring someone else's time. Better yet, show what you learned as a result of your searches. We like to respond to people who have demonstrated their ability to perceive answers.

Use tricks like Google search in the text of the received error message (look also in discussion groups - Google groups, and not only on Web pages). This can lead either directly to the documentation on how to eliminate this error, or to a discussion on the mailing list where you can find the answer. Even if the answer is not found, the phrase: “I searched Google for the following query, but I didn’t find anything useful,” will come in handy when I ask for help via email or a discussion group.

Prepare a question. Think it over. On superficial questions, you will receive superficial answers, or you will not receive answers at all. The more you do to demonstrate your thoughts and efforts to solve a problem before asking for help, the more likely you are to get this help.

Do not ask the wrong questions. If the question is based on erroneous assumptions, any hacker (most likely J. Random Hacker, approx. Translator ) will most likely give a useless literal answer, thinking "Stupid question ...", and hoping that getting what you asked for, instead of what you really need, will teach you something.

Do not think that you should answer. No one owes you anything; you ultimately did not pay for these services. You will get an answer if you deserve it by asking a substantial, interesting and thought-provoking question - a question implicitly giving the community new experience, and not just passively demanding that others share their knowledge.

On the other hand, it’s nice to immediately make it clear that you can and want to help in the decision-making process. For questions like "Can someone suggest?", "What is not taken into account in my example?" and "Is there a site that is worth a look at this topic?" more likely to get an answer than to demand sending an exact sequence of actions to solve a problem, since you have clearly shown that you will solve the problem yourself if someone tells you the right course of action.

When asking ...

Choose the right forum

Carefully consider exactly where to ask the question. You are likely to be ignored or written off as a loser if you:

  • send the question to the forum that does not correspond to the topic (off topic)

  • send the most basic question to the forum where complex technical issues are discussed, or vice versa

  • send the question at the same time (cross-post) to many different discussion groups

  • send a personal message by e-mail to a stranger who is not personally responsible for solving your problems

Hackers ignore questions sent to the wrong address, in order not to load their irrelevant information channels. Do not fall into this category of questions.

Therefore, you must first find the appropriate forum. This will again help you Google search engine and other search tools on the Web. Use them to search for the project page that is most closely associated with the hardware or software that is having difficulty. Usually on this page there will be links to a list of frequently asked questions (FAQ, Frequently Asked Questions), project mailing lists and their archives. It is there that we should ask for help if your own efforts (including reading these, which you discovered, FAQ) were unsuccessful. The project page can also describe the procedure for reporting an error or provide a link to it. In this case, use the recommended procedure.

Sending the same message to a person or to a forum with which you are not familiar is an enterprise, at least a risky one. For example, do not think that the author of an informative web-page wants to become your free consultant. Do not make optimistic assumptions that your question will be welcome - if you are not sure, send it to another address or refuse to send it at all.

When choosing a web forum, discussion group, or mailing list, do not make decisions based only on the name; Read the list of frequently asked questions (FAQ) or rules to make sure that the question is relevant to the topic. Read messages for a while before sending questions to get a feel for how things are done here. In fact, before sending a question, it will not hurt to search for keywords related to your problem in the archives of a discussion group or mailing list. As a result, you can find the answer, and if not, such a search will help to better formulate the question.

Do not use all available help channels at the same time. It looks like a scream and outraged people. Refer to them one by one.

Correctly determine the topic! One of the classic mistakes is to ask a question about the Unix or Windows programming interface in a forum dedicated to a language, library, or tool running on both platforms. If you do not understand why this is a blunder, it is better not to ask questions at all until you understand.

In general, the probability of getting answers to questions in a properly chosen public forum is higher than in a private one. There are several reasons for this. One of them is the number of potential responders. The other is the size of the audience that knows the answer; hackers take great pleasure in answering questions that may be of interest to many than to questions that are useful only to a few.

It is clear that experienced hackers and creators of popular programs already get a lot more irrelevant issues than they would like. By increasing this flow, you can in some cases become the last straw - occasionally participants in popular projects stop supporting them, because they cannot endure any more related problems as a stream of useless email messages to their personal addresses.

Beginner Web and IRC forums often get an answer as quickly as possible.

Your local user group or your Linux distribution can support a web-based forum or IRC channel designed to help beginners. (In non-English-speaking countries, beginner forums are still most likely organized as mailing lists.) These are suitable places for the initial asking of questions, especially if it is assumed that you are faced with a relatively uncomplicated or typical problem. An openly advertised IRC channel is a clear invitation to ask questions, and, often, the opportunity to receive answers in real time.

In fact, if the program you are having problems with is taken from the distribution kit (which is typical today), it may be better to first ask the forum / mailing list for the corresponding distribution before contacting the program forum / mailing list. Hackers working on a project can simply reply: "Use our build."

Before asking a question in any Web-forum, check if it has search capabilities. And if it is, look a couple of times for a keyword discussion of a problem like yours; this can help. If before you did a general search on the Web (what should have been done), still search the forum; Your search engine may not have re-indexed this forum.

There is an interesting tendency to support users of projects via a web-forum or IRC channel, leaving email for communication between developers. Therefore, if you need assistance with a project, first refer to these sources of information.

As a second step, use the project mailing lists.

If the project has a mailing list for developers, send questions to this mailing list, and not to individual developers, even if you are sure that you know who exactly can answer your question. Find the address of the project mailing list in the documentation or on the project website, and send a question to this address. There are several good reasons for doing this:

  • Any question that is good enough to contact one developer will be valuable for the whole group. On the contrary, if it seems that the question is too primitive for a mailing list, this is still no reason to fool the head of individual developers.

  • If a question is asked on the mailing list, the load is distributed among all developers. The specific developer (especially if he is the project manager) may be too busy to answer your questions.

  • Most mailing lists are archived, and archives are indexed by search engines. Someone will be able to find your question and answers online, and will not ask it again on the mailing list.

  • If certain questions are asked frequently, developers can use this information to improve the documentation or the software itself to make it more understandable. But if these questions are asked personally, no one has a general picture - what is most often asked.

If the project has separate mailing lists or Web-forums for "users" and for "developers" (or "hackers"), and you are not engaged in hacking the code, ask a question in the list / forum for "users". Do not count on a warm welcome on the developer mailing list, where your question is likely to be classified as a “noise” that prevents the exchange of information on the progress of development.

However, if you are sure that your question is non-trivial and did not receive an answer on the mailing list / forum for "users" within a few days, contact the developers. It makes sense to follow the appropriate mailing list or forum for a few days before this to learn its traditions (in fact, it makes sense to do this before contacting any private or semi-closed mailing list).

If you cannot find the address of the project mailing list, but the address of the person leading the project is known, send your question to the moderator. But in this case, do not think that there is no mailing list. In your message, indicate that you tried, but could not find the appropriate mailing list. Also mention that you are not against sending your message to other recipients. (Many people believe that personal correspondence should remain personal, even if there is nothing secret in it. By allowing you to send your message, you give people a choice.)

Ask meaningful, specific message topics.

When sending a message to a mailing list or discussion group, the subject of the message is a great opportunity to attract the attention of qualified experts with a string of up to 50 characters. Do not waste them on babbling like "Help me, please" (not to mention the topics "PLEASE HELP ME !!!!"; messages with such topics are thrown off reflexively). Do not try to hit us with the depth of your suffering; better use the space provided for a brief description of the problem.

A good agreement on the design of the message topics used by many technical support services is the use of the object-rejection template. The “object” part defines what exactly the problem arose with, and the “deviation” part describes the deviation from the expected behavior.


HELP! The video card on my laptop is not working properly!


The wrong shape of the mouse cursor in XFree86 4.1, video on the Fooware MV1005 chipset

Even better:

XFree86 4.1 mouse cursor over the Fooware MV1005 chipset - irregular shape

The process of writing a theme using the object-deviation pattern will help to understand the problem in more detail. What exactly is wrong? Only the mouse cursor or with other graphics also have problems? Problem only in XFree86? Only in version 4.1? Does this problem occur only on video cards with a Fooware chipset? Only in model MV1005? A hacker, having received a message with a similar topic, will be able, in general terms, to understand what exactly you had a problem with and what the problem was.

In general, imagine viewing a list of questions in an archive in which only the subject lines are presented. Make sure that the subject line reflects the essence of the question well enough and the next one looking through the archive in search of an answer to such a question could find a discussion leading to the answer, rather than send the question again.

If you ask a question in response, do not forget to change the subject line so that it is understandable - the question is asked. A subject line like "Re: test" or "Re: new bug" will not attract enough attention. In addition, keep quoting previous messages to a minimum sufficient for new users to understand what was being said.

Do not send just a reply to a mailing list message if you are going to discuss a new topic (start a discussion thread). This will narrow the circle of responders. Some mail readers, for example, mutt , allow the user to sort messages by topic, and then hide messages by topic by folding the discussion thread. Those who use this opportunity will never see your message.

Changing the topic is not enough. Mutt, and possibly other e-mail readers, take into account not only the subject line, but also other information in the message headers when binding them to the discussion thread. Create a brand new message.

In web forums, discussion rules are slightly different, since messages are usually more closely related to specific discussion threads and are often invisible outside of those threads. Changing the topic when asking a question in response is not essential (not all forums even allow you to specify topics in the answers, and if they can be set, almost no one reads them). But, asking a counter question in response is in itself a dubious practice, since this question will be seen only by those who follow the relevant thread of discussion. Therefore, if you are not sure that you want to appeal specifically to those who participate in the discussion of a topic, start a new topic.

Simplify the response

Completion of the question with the phrase "Answer, please send to the address ..." makes getting an answer very unlikely. If you do not have a couple of seconds to correctly set the Reply-To header in your email program, then we don’t have a couple of seconds to think about your problem. If your email program does not allow you to do this - drop it. If your operating system does not support email programs that allow you to do this, look for a better operating system.

Asking to reply by e-mail in web-forums is extremely impolite, unless you are sure that the information may be confidential (and someone, for some unknown reason, wants to communicate it to you personally, and not to the entire forum). If you want to be notified by mail that someone responded to a topic in the forum, request this notification in the interface of the Web forum; This feature is supported almost everywhere in the form of “watch this thread” options (“follow the discussion”), “send email on answers”, etc.

Write in plain language, following the rules of grammar and vocabulary

It was established experimentally that people who write carelessly and carelessly are usually just as careless and careless in the thoughts and in the code of the programs created (at least, often enough to confidently assert this). To answer the questions of inattentive and careless-minded people is a thankless task; we better spend our time on something else.

Therefore, the clarity and accuracy of the wording of the question is important. If you do not want to fool yourself with this, we do not want to fool yourself, paying attention to such issues. Try to formulate the question in the right language. It should not be ponderous and formal - in fact, the informal, full of slang and humor used correctly in hacker culture. But thoughts must be clearly expressed; it is necessary to demonstrate at least some signs of thoughtfulness and attention.

Follow the rules for syntax, punctuation, and capitalization. Do not confuse "its" with "it's", "loose" with "lose" or "discrete" with "discreet". DO NOT WRITE ALL IN THE UPPER REGISTER - this is perceived as a scream and is considered rude. (If everything is written in lower case, not much better, because it is so difficult to read. Alan Cox is forgiven, but you are not.)

In general, if you are writing at the level of childish babbling or delirium of a madman, your question will most likely be ignored. Scribbling in the style of juvenile “hackers” (absolutely - l33t script kiddie hax0r - approx. Translator ) - is absolutely hopeless, and guarantees in return - silence (or, at best, a portion of neglect and sarcasm).

If you ask questions in a forum that uses a language other than your own, then some lexical and grammatical errors will forgive you - but do not wait for any forgiveness for elementary laziness (yes, we are usually able to understand the difference). In addition, if you do not know exactly which languages ​​for the addressee are relatives, write in English. Busy hackers usually just skip questions in languages ​​they don’t understand, and English is the working language of the Internet. By asking a question in English, you reduce the likelihood that it will be missed without reading.

Send questions in clear formats

If you artificially make it difficult to read a question, it is more likely that they will answer a question that is not difficult to read instead. Therefore:

  • Send the message in plain text, not in HTML format. ( Turning off HTML is not that difficult.)

  • MIME applications are usually perfectly valid, but only if they have real content (for example, source code or a patch file is attached) and are not simply generated automatically by the email client (representing, for example, another copy of the letter, but in HTML format).

  • Do not send messages in which paragraphs are presented in one line, visually transferred to the following lines on the client. (This complicates the response to the message part.) Assume that the addressees will read messages on text terminals with 80-character lines, and set up accordingly for inserting hard line breaks, completing the line up to 80 positions.

  • In this case, however, do not break into several lines at a fixed position data (for example, log dumps or session recordings). Data must be included in the messages as they are, so that the addressees are sure that they see exactly what you saw.

  • Do not send MIME Quoted-Printable messages to the English-language forum. This encoding may be needed when sending a message in a language not covered by ASCII, but many user mail agents do not support it. Reading messages with control characters scattered throughout the text = 20 is inconvenient and unpleasant.

  • Do not even think that hackers will be able to read documents in closed, proprietary formats such as Microsoft Word or Excel. Most hackers react to them in approximately the same way you would react if you were smeared on the front door with piggy shit. Even when they can read them, the need to mess with these formats makes them angry.

  • When sending a message from a machine running Windows, disable the debility Microsoft support for Smart Quotes. This will get rid of a lot of junk symbols scattered throughout the message.

  • In web forums, do not abuse "emoticons" and the insertion options "html" (if they are provided). One or two emoticons are usually normal, but multicolored funny text suggests people that you are a lamer. Excessive use of emoticons, colors and fonts presents you as a funny teenage girl, which makes no sense, unless of course you are interested in answers, and not sex.

When using a mail client with a graphical interface (for example, Netscape Messenger, MS Outlook and the like), remember that it can violate these rules when using standard installations. Most of these clients have a menu command like "View Source". Use it to check one of the sent messages that plain text is being sent, without unnecessary garbage.

Describe the problem accurately and in detail.

  • Carefully and clearly describe the symptoms of a detected problem or error.

  • Describe the environment in which it occurs (machine, OS, application, etc.) Specify the distribution and release (for example: "Fedora Core 2", "Slackware 9.1", etc.).

  • Describe the research you did when trying to understand a problem before asking a question.

  • Describe the steps you yourself performed to diagnose and isolate the problem before asking a question.

  • Describe recent computer or software configuration changes that may be relevant.

Do your best to predict potential hacker questions and answer them in advance in your request for help.

Simon Tatham wrote a wonderful essay entitled How to effectively report bugs . I highly recommend reading it.

Volume does not mean accuracy

Be accurate and informative. For this, it is not enough to simply insert a large amount of code or data into the request. If there is a large, complex test case leading to a program error, try to minimize it.

This is useful for at least three reasons. First, the demonstrated efforts to simplify the question increase the likelihood of receiving an answer. Second, simplifying the question increases the likelihood of getting a useful answer. Third: during the clarification of the error message, you yourself can find a solution or workaround.

Do not claim to have found a mistake

If you have problems with this or that software, do not declare that you have found a mistake, unless you are absolutely sure of this. Hint: if you cannot provide a source code fix that solves a problem or a test case for a previous version that demonstrates the wrong behavior, you are most likely not sufficiently confident in your statement.

Remember that many other users have not encountered such a problem. Otherwise, you would already know about it when reading the documentation or when searching the Web (you did this before making such statements, did you ?). This means that, most likely, it is you who are doing something wrong, and not the software.

The creators of the software are making great efforts to make it work as best as possible. If you claim to have found a mistake, then you assume that they did something wrong, and they will almost certainly not like it - even if you are right. Particularly non-diplomatic would be to write a “bug” in the subject line of the message.

When asking a question, it is better to describe the problem, assuming that you are doing something wrong, even if you are personally absolutely sure that you have found a mistake. If this is really a mistake, you will read about it in the answer. Try to behave in such a way that people who support the program want to apologize to you if a real error is found, and not so that you have to apologize for your stupidity.

Public self-humiliation does not replace homework

Some, having understood that it is not necessary to behave rudely or haughtily, extorting an answer, choose the opposite extreme — self-humiliation. "I know, I am a beginner, a loser and a full kettle, but ...". It distracts from the essence and does not make sense. Especially in combination with the uncertainty in the description of the actual problem.

Do not waste your time, and ours, relying on pity. Provide better facts and your question as clearly as possible. So you declare yourself much better than by self-abasement.

Sometimes web forums have separate places for beginner questions. If you feel that such a question can only be asked by a novice user, ask it there. But there is no need to be humiliated.

Describe the symptoms of the problem, not your assumptions.

It is useless to tell hackers your opinion about the causes of the problem. (If your diagnostic theories are so valuable, is it necessary to seek help from others?) Therefore, check that you are reporting the actual symptoms of what is happening, rather than your own interpretations and theories. Let the respondents deal with interpretation and diagnostics.


I constantly get SIG11 errors when compiling the kernel, and I suspect that the cause is a microcrack on the motherboard. What is the best way to check this?


On the K6 / 233 computer I assembled on the FIC-PA2007 motherboard (VIA Apollo VP2 chipset) with 256MB of Corsair PC133 SDRAM memory, SIG11 errors often start to occur approximately 20 minutes after power up, during the compilation of the kernel, but they do not occur in the first 20 minutes Rebooting does not lead to anything, but disconnecting for the night helps. Replacing the entire memory did not help. The corresponding part of the results of a typical compilation is attached.

Describe problem symptoms in chronological order.

The most important information for clarifying the causes of what is happening is often related to the events immediately preceding this situation. Therefore, it is necessary to accurately describe what you did and what the machine did until the problem occurred. In the case of working with the command line interface, recording a session (for example, using the script utility) and including a couple dozen of corresponding lines in the message can help a lot.

If the crash program has diagnostics options (for example, -v - detailed information), try to find options that add useful debugging information to the transcript of the session.

If the record is long enough (more than a page), it makes sense to formulate the problem in advance at the beginning, and then indicate the chronological sequence of actions leading to it. In this case, hackers will know what to look for when reading a session.

Describe the goal, not a separate step.

If you are trying to figure out how to do something (and not report an error), start with a description of the goal. And only then describe a specific step towards it that you could not perform.

Often, people who need technical assistance have a high-level goal on their mind and are tied to one of their possible ways of achieving it. They ask for help to complete one step, without realizing that they have chosen the wrong path. To understand this, it may take a lot of effort.


How to make the color selection dialog in FooDraw perceive a hexadecimal RGB value?


I'm trying to replace the color table in the image with the values ​​I need. Now I see only one way to do this - editing each slot of the table, but I can not set the hexadecimal RGB value in the FooDraw color selection dialog.

The second version of the question is reasonable. It allows you to get an answer in which a tool will be proposed that is more suitable for solving the problem.

Do not ask to respond to a personal email address.

Hackers believe that problem solving should be an open, transparent process, during which the first attempt to find an answer can and should be corrected, if someone more knowledgeable will notice that this answer is incomplete or incorrect. In addition, those who respond are partially rewarded by the fact that their competence and knowledge will be noticed by their colleagues.

When you ask for a personal response, you interfere with both the decision-making process and the receipt of remuneration. Do not do this. To answer personally is the choice of the respondent , and if he does, it is usually because he considers the question too poorly formulated or obvious to be interesting to others.

There is one small exception to this rule. If you assume that you will receive many similar answers to your question, do not forget the magic words “send an answer to me, and I will summarize the answers received in the article for the discussion group.” Trying to save a discussion group or mailing list from the flow of essentially identical messages is very kind, but you have to keep your promise and send a summary summary.

Ask clear questions

Unlimited questions usually require unlimited time to answer. People who are likely to be able to give you a useful answer are also the busiest people (also because they do most of their work themselves). Such people are jealous of their time, and therefore often do not accept unlimited questions.

The probability of getting a useful answer increases if you make it clear what you are trying to get from the respondents (provide links, send code, check your decision, etc.). This will concentrate the efforts of the responders and implicitly set the time limit and effort that the responder will have to spend to help you. It's good.

In order to understand the world in which experts live, one must treat the knowledge of experts as an abundant resource, and their time as a very limited resource. The less time you implicitly require, the more likely it is to receive a response from a really good and busy expert.

Therefore, it makes sense to limit the question in order to minimize the time required for the expert to solve it. But often this is not the same thing as simplifying the question. For example, the question: "Can you give me a link to a good description of X?" - usually much smarter than a request: "Explain to me X, please." If you have a problem with inoperative code, it would be more reasonable to ask for an explanation of what is wrong with it, rather than asking for errors to be corrected.

Do not ask questions from homework

Hackers are well able to answer questions from homework - most of us did them on our own. These questions are asked to work for you so that you can learn from your own experience. You can ask for a hint, but not about the complete solution.

If you suspect that you have been asked a question from homework, but you still cannot answer it, try asking a question in the user group forum or (as a last resort) in the “user” mailing list / forum of the relevant project. Although hackers recognize it, some of the advanced users may at least give you a hint.

Avoid meaningless requests

Do not be tempted to complete your request with meaningless questions like: "Can anyone help me?" or "Is there any answer at all?" First, if you have described your problem at all competently, such additional questions are, at a minimum, superfluous. Secondly, since they are unnecessary, they seem annoying to hackers - and in response, they incite them to write a logically immaculate unsubscription like: “Yes, you can be helped” or “No, you will not be helped by anything”.

In general, yes-no questions are better not to ask, unless you want to get an yes-or-no answer .

Do not mark your question as “Urgent”, even if for you it’s such

This is your problem, not ours. The mention of urgency is often counterproductive: most hackers simply remove such messages as rude and selfish attempts to urgently attract special attention.

There is one partial exception to this rule. Mentioning urgency can make sense if you use the program in a serious organization that may be of interest to hackers; In this case, if you do not have enough time and you report it politely, people may be interested enough to respond quickly.

However, doing so is extremely risky, because the hacker’s point of view on seriousness and his interests are probably different from yours. A question from the international space station, for example, will arouse interest, but the question on behalf of a successful charitable foundation or political party, almost certainly, is not. In fact, the question with the topic "Urgent: Help me save the fluffy seals!" it will be ignored or maliciously commented even by those hackers who believe that the life of furry seals is important to them.

If this surprises you, re-read the rest of the document until you understand, and before that, refrain from sending questions at all.

Politeness never hurts, and sometimes helps

Be polite. Use the phrases "Please" and "Thankful in advance." Make it clear that we are grateful to people who dedicate their time to you for free.

To be honest, this is not as important as the absence of errors in the text of the question, clarity, accuracy and detail of the description, the use of open formats, etc. (and does not replace all of the above); hackers, in general, would prefer to receive rude, but technically accurate error messages than polite verbiage. (If it surprises you, remember that we value the question for what it teaches us.)

However, at the normal technical level of the question, politeness really increases the likelihood of getting a useful answer.

(It should be noted that the only serious objection received from veterans of the hacker movement to this document is related to the recommendation to use the phrase “Thank you in advance.” Some hackers see it as unwilling to thank anyone after the problem is resolved. We recommend give thanks both in advance and after receiving the answer, or express your gratitude differently, say, with the phrase "Thank you for your attention" or "Thanks for your consideration.")

Send a brief description of the solution.

After the problem is solved, send a message to everyone who has helped you; let them know how it all ended, and thank you once again for your help. If the problem caused a general interest on the mailing list or discussion group, it makes sense to send such a message there.

It will be optimal to answer in the threads of the discussion started with the original question, adding in the subject of the message the mark 'FIXED', 'RESOLVED', 'SOLUTION' or another equally obvious indication of the solution. In mailing lists with a large number of messages, the potential responder when looking at the discussion thread "Problem X", ending with the message "Problem X - SOLUTION" understands that he does not need to waste time even reading messages (unless he personally finds Problem X interesting) , and therefore can spend time solving another problem.

Such a message does not have to be long and detailed; idle time: "Hi! The problem was connected with a rupture in a network cable! Thanks to everyone. Bill," is already better than nothing. In fact, a short and polite summary is better than a long dissertation, unless the decision involves serious technical aspects. Write down what actions allowed you to solve the problem, but you do not need to re-describe the entire sequence of the search for a solution.

For serious problems, you can send a resume with a history of finding their causes. Describe the final problem statement. Describe how the solution turned out, and indicate the dead-end paths to avoid. Name everyone who has helped you: this is how you will find friends.

In addition to being polite and informing, this kind of summary message will help others search the mailing list / discussion group / forum in the archive to find out exactly which solution helped you, and therefore can help them.

Last but not least, this kind of message helps everyone involved in the discussion to get a feeling of satisfaction from the fact that the problem is closed. If you yourself are not a technician or a hacker, just trust us that this feeling is very important for the gurus and experts you turned to for help. Describing the problems that were not solved as a result is a complete disappointment; hackers crave to see them solved. Good karma, which arises when you satisfy this thirst, will help you a lot when asking the question next time.

Consider how you can prevent other users from having the same problem in the future. Ask yourself if the change in the documentation or the FAQ list will help, and if so, send the appropriate change to those who support these documents.

Among hackers, this behavior is actually considered more important than ordinary politeness. That is how they earn a reputation as a good team player, which is a very valuable quality.

How to interpret the answers

RTFM and STFW: how to understand that you are seriously screwed up

There is an ancient and sacred tradition: if you get the answer " RTFM ", then the respondent thinks you should read the manual ( Read The Fucking Manual ). He is almost certainly right. Read.

The RTFM response has a younger counterpart. If you get the answer " STFW ", then the respondent thinks that you should look for the answer on the network (Search The Fucking Web). He is almost certainly right. Search.

In the Web-forums you may be offered to look in the archives of the forum. In fact, the respondent may be so kind as to give a link to the previous discussion, in which this problem was solved. But do not hope for it; look in the archives yourself before asking.

Often, the one who sends one of these answers has a manual or web page with the information you need, and looks at it when it dials the answer. These answers mean that, in his opinion, firstly, the information you need is easy to find and, secondly, you will learn more when searching for information than if you give it to yourself on a platter.

You should not be outraged; by hacker standards, he showed you enough respect by not ignoring the question. You should thank the respondent for his fatherly kindness.

If you do not understand ...

If you do not understand the answer, do not immediately send a request to explain it. Use the same sources of information as when searching for the answer to the original question (guides, FAQ, Web, experienced colleagues) to understand the answer. If after that you need clarification, show what you have learned yourself.

For example, suppose I answered you: "It looks like your zentry is frozen; you need to check." Then the bad clarifying question would be: "What is zentry"? And good : "OK, I read the manual page, and about zentry it is mentioned there only in options -z and -p. None of them says how to reset a hung zentry. Do I need to use one of these options, or am I got it wrong? "

Reaction to rudeness

Most of what may seem rude in hacker circles is not used as an insult. Rather, it is a consequence of a direct, blunt, communication style that is natural for people trying to solve problems, and not seem soft and fluffy to others.

When faced with rudeness, try to respond calmly. If someone really goes beyond what’s acceptable, it’s likely that the moderator on the mailing list, discussion group or forum will put it in place. If this does not happen and you lose your temper, it is likely that the person who became the cause behaves within the norms of the hacker community, and everyone will think that you are wrong. This will significantly reduce the chances of getting the necessary information or assistance.

On the other hand, sometimes it is possible to meet with rudeness and challenge, which have no visible reason. The flip side of this medal is that such a reaction is a perfectly acceptable form of putting real rude men in place - we cut off their misbehavior with a sharply sharp verbal scalpel. However, you must be very confident in your position before attempting to do this. The line between indicating impoliteness and the beginning of a meaningless "bazaar" (in the original - flamewar - comment of the translator ) is so thin that the hackers themselves often cross it. If you are a novice or just a casual reader, there is little chance of avoiding such a blunder. If you are interested in information, not entertainment, it is better to remove your hands from the keyboard and do not risk to engage in such discussions.

(Some insist that many hackers suffer from a mild form of autism, or Asperger syndrome , and they simply lack the part of the brain that is responsible for the "normal" social interaction between people. Maybe it’s true, maybe not. If you - not a hacker, the idea of ​​hackers being sick in the head can help you come to terms with our oddities. Think what you want. We do not care, we like to be just like that, and we treat clinical diagnoses with healthy skepticism.)

In the next section, we'll talk about another problem; about a kind of "rudeness" with which you can meet, when exactly you are wrong.

Do not react as a loser

It is likely that you have screwed up several times in hacker forums - as described in this article, or similarly. And they have already explained to you exactly how you screwed up, perhaps in paints. With all honest people.

When this happens, the most unsuccessful reaction is to complain about what happened, consider yourself insulted verbally, demand an apology, yell, suffocate with anger, sue, complain to offenders' employers, do not let down the toilet seat, etc. Instead of all this, do the following:

Put up with This is normal. In fact, it is good and appropriate.

Social norms do not support themselves - they are supported by people who actively, openly, publicly apply these norms. Do not think that you should only criticize in personal correspondence - this is not so. It does not make sense to take someone’s comment as a personal insult that one of your statements is wrong, or that he has a different opinion. So are the losers.

There were hacker forums, where, based on incorrectly understood hypertrophied politeness, participants were forbidden to send error messages in other people's messages. They were told: "If you do not want to help the user, be silent." The outflow of knowledgeable participants to other forums led to their degeneration into meaningless chatter and to complete uselessness from a technical point of view.

Choose: exaggerated "friendliness" (of this kind) or utility.

Remember: when this hacker writes that you screwed up, and (no matter how rude) asks you not to do this anymore, he does it, taking care, first, of you, and second, of his community. It would be much easier for him to ignore you and strike him out of his life. If you are not enough for gratitude, keep your dignity - do not complain, and do not think that you will be treated like a fragile doll just because you are a beginner with a theatrical hypersensitive soul and illusions about self-importance.

Sometimes people will get personal, engage in foul controversy for no apparent reason, etc., even if you haven't screwed up (or screwed up only in their imagination). Resent in this case is a way to really screw it up.

These "brawlers" are either lamers who do not understand anything, but consider themselves to be experts, or potential psychologists, checking whether you are screwing up or not. Other readers either ignore them or find ways to deal with them on their own. The behavior of the brawlers creates problems for themselves, which should not bother you.

Do not let yourself be drawn into the useless "bazaar" either. It is better to ignore such discussions, having previously figured out that this is a really useless “bazaar”, and not hints about why you really screwed up, and not subtly encrypted answers to your actual questions (this also happens).

Questions not to ask

Here are a number of classic stupid questions and what hackers think when they are not answered.


Where can I find a program or resource X?


In the same place where I took it, idiot - found on the Internet. God, don't everyone know how to use Google ?


How can X do Y?


If you want to do Y, you need to ask so, without assuming in advance the use of a method that may not be appropriate at all. Questions of this kind are often asked by those who not only know nothing about X, but are confused with the Y problem being solved and are too focused on the details of their particular situation. It is usually better to ignore such people until they formulate their problem better.


How to configure the command prompt?


If you are smart enough to be interested in this, you are smart enough to search for an answer yourself.


Can I convert an AcmeCorp document to a TeX file using the Bass-o-matic file conversion program?


Try and find out. So you, first of all, know the answer, and, secondly, stop wasting my time.


My {program, configuration, my SQL statement} does not work


This is not a question at all, and I am not going to ask a dozen more leading questions in order to find out what your problem really is - I have things to do and more interesting. When I see such questions, I usually send one of the following answers:

  • You have nothing more to add to this?

  • Oh, this is very bad. I hope you have already fixed it.

  • And what does this have to do with me personally?


I have a problem with a windows machine. Could you help me?


Yes. Throw this Microsoft garbage out and set yourself up with an open source operating system, like Linux or BSD.

Note: You can ask questions related to Windows machines if they relate to a program that has an official version for Windows or that interacts with machines under Windows (for example, Samba). Just do not be surprised at the answer that the problem is in Windows, and not in the program itself, because Windows is so “crooked” as a whole that it often happens that way.


My program is not working. I think the problem is in the system component X.


Although it is possible that it was you who first discovered the obvious error in the system calls and libraries intensively used by hundreds or thousands of developers, but it is much more likely that you simply did not understand. Serious allegations require serious evidence; if you make such statements, they should be supported by a clear and comprehensive description of the situation in which the failure occurs.


I'm having problems installing Linux (or X). Could you help me?


Not. To solve this problem, I need direct access to your machine. Ask a local Linux user group who can personally help. (A list of user groups can be found here .)

Note: Linux installation questions may be relevant in a forum or mailing list dedicated to a particular distribution, if the problem is related to this distribution, or in local user groups forums. In this case, do not forget to accurately describe the details of the failure. But first, look carefully at the Web, specifying the keywords "linux" and all the suspicious hardware components.


How to crack the root user password / get extended privileges / read someone else's email?


Yes, you're just vulgar, if you want to do this, and an idiot, just ask the hacker to help you.

Good and bad questions

Finally, I'm going to show by examples how to ask questions correctly. I will present a couple of questions about the same problem, one - the given one is stupid, and the second is correct.

Silly: Where can I find information about Foonly Flurbamatic?

This question just begs for the answer "STFW" .

Correct: I tried to search the Web using Google for "Foonly Flurbamatic 2600", but did not get any useful links. Does anyone know where to find information about programming this device?

This questioner has already searched the Web and it seems he has a real problem.

Stupid: I can't compile the project code for foo. Why is it incorrect?

He thinks someone else screwed up. Self-confident type.

Correct: Project code foo is not compiled on Nulix OS version 6.2. I have read the FAQ (FAQ), but there is nothing about problems with Nulix. Here is a record of the compilation session; What did I do wrong?

He indicated Wednesday, read the frequently asked questions, showed an error message, and he does not think that the reason for his problem is in the error of someone else. This guy can get a little attention.

Silly: I have problems with the motherboard. Can anyone help?

Any hacker will answer such a question in his mind, most likely this way: “Okay. Maybe you can still help to burp and change the diaper?”, And press the Delete key.

That's right: I tried X, Y and Z on the S2464 motherboard. When it didn’t work, I tried A, B and C. Pay attention to the strange symptom when trying to do C. Obviously, this garbage doesn’t fool, but the results are unpredictable. What usually leads to the fact that they do not fry multiprocessor motherboards with Athlon? Does anyone have any ideas for additional tests that will help isolate the problem?

This fellow, on the contrary, seems to deserve an answer. He demonstrated the ability to solve problems, and not just wait until the answer falls to him from the sky.

In the last question, notice the small but important difference between "Give me the answer" and "Please help me figure out what additional diagnostic actions you can take to clarify the situation."

In fact, the form for specifying the last question is very similar to the one actually used in August 2001 on the linux-kernel mailing list. I (Eric) then asked this question. I watched strange hangs on the Tyan S2464 motherboard. Mailing list members provided valuable information that allowed me to get rid of these freezes.

By asking a question the way I did, you give people food for thought; I made it easy for them to participate in solving a problem. I demonstrated respect for the abilities of my colleagues and invited them to discuss on an equal footing. I also demonstrated that I value their time by describing which dead-end branches I have already passed.

In the end, when I thanked everyone and stressed how well the problem-solving process went, one of the participants on the mailing list drew attention to the fact that, in his opinion, everything did not work out because I am a “famous person” on this list, but because of the correct form of the question.

Hackers, in a certain respect, a very cruel intellectual elite (in the original - meritocracy . Approx. Translator ). I am sure that he is right, and if I were screwed up , I would be criticized or ignored, regardless of past merits. His proposal to describe the situation as a guide for everyone else was the immediate cause of this guide.

If no response is received

If you do not receive a response, do not take it personally, as our refusal to help you personally. Sometimes forum members simply do not know the answer. The absence of an answer is not tantamount to ignoring, although it is difficult to notice the difference from the outside.

In general, re-sending the question is not the best idea. It will be perceived as meaningless annoyance.

There are other sources of help that can be addressed, often more suited to the needs of beginners.

There are many user groups on the network and in the field who are enthusiastically involved in software, although many of their participants have not written a single serious program in their lives. These groups are often formed to help members help each other and new users.

There are also a lot of commercial companies with which you can sign a contract for support, both large and small (some of the most famous are Red Hat and Linuxcare, but there are many others). Do not be afraid of the idea of ​​paying for support! Ultimately, if an overhaul of a car engine is necessary, you will give it to the workshop and pay for repairs. Even if the software cost nothing, you cannot expect to be supported for free at all times.

With popular software, such as Linux, there are at least 10,000 users per developer. One person simply cannot cope with the support of 10,000 users. Remember that even if you have to pay for support, it still costs much less than when you also have to buy the software itself (and support for proprietary software usually costs more and is performed by less competent experts than in the case of open source software). code).

How to give good answers

Be generous. Stress related to the problem can make impolite or stupid people who are not.

On the first error, indicate privately. There is no need to publicly humiliate a person who may be honestly mistaken. A novice user may not know how to search the archives or where the list of frequently asked questions is located or published.

If you are not sure, say so! An erroneous but authoritatively sound answer is worse than no answer. Do not send people on the wrong path simply because you are pleased to be in the role of an expert. Be humble and honest; set a good example for questioners and colleagues.

If you can not help, do not interfere. Do not joke about the procedures that can destroy the user's environment - this blockhead can take your jokes as a guide to action.

Ask additional questions to get more information. If you do it right, the questioner will learn something, and you too. Try to turn a bad question into a good one; remember - we were all beginners.

Although the simple answer RTFM is justified when given just lazy, a link to the documentation (even if it is a set of keywords for Google search) is still better.

If you are already answering a question, let’s answer in essence. Do not offer hastily devised workarounds if the wrong means or wrong approach is used in principle. Offer good products. Rephrase the question.

Help the public benefit from the question. When you meet a good question, ask yourself: “How should the relevant documentation or the FAQ list be changed so that no one else asks this question?”. Then send the appropriate supplement to the person who supports these documents.

If you had to do research to answer the question, share your experience, and do not write as if the answer fell on you from the sky. To answer one good question is how to feed the hungry one time, but to set out the research methodology using an example means learning to get food for life.

Additional sources of information

If you need information on the basics of personal computers, Unix OS, and the Internet, see the The Unix and Internet Fundamentals HOWTO .

When creating software or issuing patches for programs, try to follow the principles outlined in the Software Release Practice HOWTO .


Evelyn Mitchell offered to comment on a number of stupid questions and inspired to write the section "How to give good answers." Mikhail Ramendik gave a number of valuable suggestions for improving the document.

Translator's notes

The original article is taken from here .