How to ask questions?

Translations

There are translations of the document into Chinese , Czech , Danish , Estonian , French , German , Hebrew , Hungarian , Italian , Japanese , Polish , Russian , Spanish , Swedish and Turkish languages. If you want to copy, to support the mirror, translate, or quote this document, please read my copy rule .

Denial of obligations

The websites of many projects in the sections on how to seek help, references are made to this document. This is good, for this purpose it is intended, but if you - web-master is going to add a link to their project page, please, next to the link in a prominent place, indicate that we are not a support for your project!

We are on the bitter experience that, in the absence of such notification, we will constantly pester idiots who believe that the publication of this document obliges us to solve all the technical problems in the world.

If you're reading this document because you need help, and you finally think you can get it directly from the authors, you - one of the most idiots. Do not ask us questions. We will simply be ignored. Our goal - to show you how to get help from those who know the software or hardware with which you are working, but in 99% of cases, these will be versed we are not. If you do not know for sure that one of the authors is an expert in that, what you are good - leave us alone, and this all gets better.

introduction

In the world of hackers , the style of the answers that you get to ask technical questions, depending on the method of setting matters as much of their complexity. This guide will teach ask questions so as to increase the probability of obtaining a satisfactory answer.

Now that the software is open source has become widespread, you can often get answers from other, more experienced users, not from hackers. It's good; users are usually a little more tolerant to errors that beginners often make. However, if the address to experienced users as hackers, in accordance with the recommendations set forth herein, it will be most effective way to obtain useful replies from them.

First of all, we must understand that hackers actually like challenges and the good that can stir up the brains of these issues questions. If we did not like it, we would not have been hackers. If you ask us to an interesting question, which requires long deliberation, we will be grateful for it; good questions - and it's an incentive gift. Good questions to help you better understand the subject and often reveal problems that were previously overlooked or not thought about that. From the mouth of the hacker: "Good question!" - This is a great and sincere compliment.

Despite this, it is believed that the hackers are simple matters most hostile or arrogant. Sometimes it seems that we are quite rude to newbies and ignore them. But actually it is not.

We are, without doubt, a hostile attitude to the people, presumably not wanting to think or learn before asking questions. Such people kill time - they take without giving anything in return, they take the time that we could spend another question more interesting and another person more worthy of an answer. These people we call "losers" ( "losers") (for historical reasons, the word is sometimes written as "lusers" --losers users).

We understand that many people just want to use us created the software, and are not going to learn the technical details. For most computer - it's just a tool, a means to an end; they have more important things to do and other problems in life. We recognize this and do not expect that everyone will be interested in the technical details, so attractive to us. However, our style of answering questions for people who are really interested in this, and want to be active participants in the process of solving problems. This will not change. Yes, and should not be changed; Otherwise, we can not effectively do what we - the best.

We (mostly) - volunteers. We are committed during his troubled life answers to questions, and at times we do not cope with the barrage of questions. Therefore it is necessary ruthlessly to "filter Bazaar". In particular, the issues of potential losers to drop, to spend the allotted response time more efficiently, dedicating it to the winners.

If this position seems to you funny, haughty or arrogant, you're wrong. 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 take you to their culture, if you put in the necessary effort. But simply inefficient to try to help people to us who do not want to help themselves. Being rude - normal, but pretend to be an idiot - not.

So, although it is not necessary to be technically competent, to be worthy of our attention, it is necessary to demonstrate the quality, allowing to become competent - attentiveness, thoughtfulness, observation, desire to actively participate in the development of solutions. If you can not accept this kind of discrimination, it makes sense to pay somebody for a commercial support, instead of asking hackers to help you personally vain.

If you have decided to turn to us for help, do not get in the position of a loser. And do not act like a loser. The best way to get a quick and sensitive response - asking how an intelligent man, confident and knowledgeable, who just needed help in solving a particular problem.

(Additions to this guide are welcome. Suggestions can be sent to [email protected] . Note, however, that this document is not designed as a general guide to netiquette , and I usually ignore proposals that are not related directly to give useful answers in a technical forum ).

Before you ask ...

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

1. Try to find the answer with the help of Web search.
2. Try to find an answer in the manual.
3. Try to find the answer in the list of frequently asked questions (FAQ).
4. Try to find an answer by inspection or experimentation.
5. Ask an experienced friend.
6. If you - programmer, try to find the answer by analyzing the source code.

When asking a question, select from the start that you have already done so; This will help you understand that you are not some kind of a bummer, tranzhiryaschy people's time. Better yet, show that you have learned as a result of their search. We like to meet the people who have demonstrated their ability to perceive answers.

Use techniques such as search on Google for the text of the error message (look also in discussion groups - Google groups, and not just on the Web-pages). This may lead either directly to documentation about how to resolve this error, or to discussions on the mailing list, where you can find the answer. Even if the answer is not there, the phrase: "I have searched Google for the next request, but did not find anything useful," useful when applying for assistance by e-mail or discussion group.

Prepare your question. Think about it. On the surface the questions you will get answers to the surface, or in general do not get answers. The more you do to demonstrate their thinking and efforts to address the problem before asking for help, the more likely that you will get this help.

Do not ask the wrong questions. If the question is based on erroneous assumptions, any hacker (in the original -. J. Random Hacker, a comment of the translator) is likely to give a useless literal answer while thinking "Stupid question ..." and hoping that the receipt of about than you asked for, rather than what is really needed something to teach you.

Do not think that you have to answer. You no one should; you are, in the end, did not pay for these services. You will receive a response if earn it by asking a substantial, interesting and thought-provoking question - the question, implicitly giving the community a new experience, and not merely passively demanding knowledge from others to share.

On the other hand, not bad just to make clear what you can and want to help in the decision-making process. On questions like "Can anyone suggest something?" "What is not taken into account in my example?" and "Is not there a site that is on the subject to see?" more likely to be answered than the requirement to send the exact sequence of actions to solve the problem, because you clearly showed that solve the problem yourself, if someone tells you the correct course of action.

When you are asking ...

Choose the right forum

Think carefully about exactly where to ask. You are likely to be ignored, or written off as a loser, if you:

• post your question in the forum is not the appropriate topics (off topic)
• send the most elementary question to a forum where complex technical issues are discussed, or vice versa
• post your question at the same time (cross-post) in a variety of different panels
• send a private e-mail message to a stranger, not personally responsible for solving your problem

Hackers ignore the questions directed to the wrong address, so as not to upload links irrelevant information. Do not fall into the category of issues.

Therefore, you first need to find an appropriate forum. This will help you over the search engine Google and other Web search tools. Use them to find the project pages, are most closely associated with hardware or software, which are having difficulties. Usually there will be a reference to a list of frequently asked questions (FAQ, FAQ - Frequently Asked Questions) on this page, the project mailing lists and their archives. It is there and it is necessary to ask for help, if your own efforts (including reading those found you FAQ) failed. On the page of the project can also be described a procedure for reporting a bug or have a link to it. In this case, use the recommended procedure.

Sending the same message to a person or forum which you are not familiar, - the company, at least risky. For example, do not assume that the author of an informative web-page wants to be your free consultant. Do not make optimistic assumptions about what your question will be happy - if you are unsure, send it to another address or give up its premises at all.

When choosing a Web-forum, newsgroup or mailing list, do not take a decision only on the basis of the name; Read a list of frequently asked questions (FAQ), or the rules to make sure that the issue corresponds to the subject. Read the posts for a while before sending questions to feel like and what is being done here. In fact, before sending the matter does not hurt to look for key words related to your problem in the archives of the newsgroup 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 once. This is similar to the cry of the people and outraged. Refer to them in turn.

Correctly identify the theme! One of the classic mistakes - ask a question on the Unix or Windows programming interface in a forum devoted to the language, the library or the tools running on both platforms. If you do not understand why this is - a blunder, it is better not to ask questions until you understand.

In general, the probability of getting answers to the questions in a properly selected public forum than in private. The reasons for this are several. One of them - the number of potential respondents. Another - the size of the audience, which knows the answer; hackers with great pleasure to answer questions that may interest many people than questions that are useful only to a few.

It is clear that skilled hackers and creators of the popular programs already receive much no more pertinent question than you would like. By increasing the flux in some cases, you can be the last straw - occasionally participating popular projects stopped their support because they do not take out more than its attendant problems in the form of a stream of useless emails to their personal address.

Web- and IRC-forums for beginners are often allowed to get an answer as quickly as possible

Your local user group, or your Linux distribution can support Web-forums or IRC channel, designed to help beginners. (In non-English speaking countries, a forum for beginners, is still likely to be organized in the form of mailing lists.) It is - suitable locations for the initial assignment of issues, especially if it is assumed that you are faced with a relatively simple or common problem. Openly advertised IRC channel - it is an open invitation to ask questions, and often the ability to get answers in real time.

In fact, if the program with which you are having problems, taken from the distribution (which, today, typically), it may be better to ask in the forum / mailing list for the appropriate distribution kit, before calling for a forum / mailing list program. Hackers working on the project may simply answer: "Use our assembly."

Before asking a question at any Web-forum, check it for any search capabilities. And if it is, look for a couple of times by keyword discussion of the problem, like yours; this can help. If before that you have performed a general search in the Web (that should have been done), you still look at the forum; perhaps, your search engine for a long time not to re-indexed this forum.

There is an interesting trend to perform user support projects through the Web-forum or IRC channel, leaving e-mail for communication between developers. Therefore, if you need help on the project, please refer first to those of his sources of information.

As a second step, use project mailing lists

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

• Any question good enough to him to turn to a single developer, and will be valuable for the whole group. On the contrary, if it seems that the issue is too primitive for a mailing list, it's not a reason to fool them head individual developers.
• If the question is asked on the mailing list, the load is distributed among all developers. The particular developer (especially if he - the project leader) may be too busy to answer your questions.
• The majority of archived mailing lists and archives - are indexed by search engines. Someone could find your question and answers on the network, and does not ask him again on the mailing list.
• If certain questions are asked often, developers can use this information to improve the documentation or the software itself to become more apparent. But if those questions are asked in person, no one has an overall picture - what is most often asked.

If the project has a separate mailing lists or Web-based forums for the "user" and "developer" (or "hackers"), and you do not collated (hacking) code, ask a question in the list / forum for the "user". Do not count on a warm welcome on the mailing list for developers, where your question is likely to carry to the category of "noise" that interferes with the exchange of information on the progress of development.

However, if you are confident in their non-triviality of the issue and have not received a response to the mailing / forum for the "user" list in a few days, contact the developers. It makes sense to ensue for the appropriate mailing list or forum a few days to explore its tradition (in fact, it makes sense to do before contacting any private or semi-closed mailing list).

If you can not find the address of a project mailing list, but known address of the person leading the project, send your question master. But in this case, do not assume that the mailing list there. In his message, specify that tried, but could not find the appropriate mailing list. Mention also that do not mind sending your message to other people. (Many believe that personal correspondence should remain private, even if there is nothing secret in it. Solving send your message, you give people a choice.)

Ask meaningful, concrete posts Topics

When sending a message to a mailing list or discussion group posts the theme - a great opportunity to attract the attention of qualified experts line up to 50 characters. Do not spend it on babble like "Please help me" (not to mention the theme "PLEASE HELP ME !!!!"; messages with subjects thrown reflexively). Do not try to impress us with the depth of their suffering; better use the space provided for the most concise description of the problem.

Good agreement on registration of the messages used by many Technical Support services - the use of a template "object - deviation". Part of the "object" specifies what is a problem, and some "deviation" describes the deviation from expected behavior.

Silly:

HELP! Video card on my laptop is not working properly!

reasonable:

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

Better:

XFree86 4.1 mouse on Fooware MV1005 chipset - irregular shape

The process of writing the theme template "object-deviation" will help to understand the problem in more detail. What exactly it is not working? Just the mouse cursor or other graphics too, have a problem? The only problem is XFree86? Only in version 4.1? This problem only occurs on the cards with the chipset Fooware? Only MV1005 model? Hacker received a message with a similar theme, will, in general, to understand what it is you have a problem and what the problem is.

In general, imagine viewing a list of questions in the archive, which represents only the subject line. Make the subject line well enough to reflect the essence of the issue and the following are browsing the archives for the answer to this question could find a discussion that leads to the answer, and did not send the question again.

If you ask a question in return, do not forget to change the subject line so that it is clear on it - the question is asked. The subject line of the form "Re: test" or "Re: new bug" will not attract enough attention. In addition, reduce the citation of previous posts to a minimum adequate to new users to understand what was being said.

Do not send a response to the mailing list message, if you are going to discuss a new topic (start a discussion thread). This narrows the range of respondents. Some mail readers, for example, mutt, allow the user to sort messages by subject, and then hide messages on the subject, turning the discussion thread. Those who enjoy this opportunity, never your message will not see.

Change the subject is not enough. Mutt, and probably other mail readers, take into account not only the subject line of the program, but also other information in message headers when you bind them to the discussion thread. Create a brand new message.

In the Web-forums discussing the rules are slightly different, because messages are usually more closely linked to specific strands of discussion and often invisible outside those threads. Changing the subject when asking a question in reply is not essential (not all forums even allow you to specify the theme in the responses, and if they can be and ask, almost nobody reads). But ask a counter question to answer in itself - a dubious practice, since this question will see only those who follow the appropriate discussion thread. Therefore, if you are not sure you want to apply it to those who participate in discussion threads, start new topic.

Simplify the answer parcel

Completion of the issue by "answer, please send to ..." makes it quite unlikely to receive a response. If you do not have a couple of seconds to ensure that the correct set the Reply-To header in your mail program, then we have a couple of seconds and then on to think about your problem. If your mail program does not allow to do it - throw it. If your operating system does not support e-mail programs allow to do this, look for a better operating system.

Asking to answer by e-mail to Web-forums - very rude, unless you believe that the information may be sensitive (and someone, for some unknown reason, he wants to announce it to you personally, and not around the forum). If you want to be notified via email that someone has replied to the topic in the forum ask this notice in the Web-interface online; this feature is supported almost everywhere in the form of options "watch this thread" ( "follow the discussion"), "send email on answers" ( "notify mail"), etc.)

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

Experimentally found that people who write casually and carelessly, usually in the same careless and negligent in his mind and in the code generated by the programs (at least often enough to confidently say so). Answer people's questions inattentive and careless thinking - a thankless task; we time better spent on something else.

Therefore, the clarity and accuracy of the wording of the question is important. If you do not want to fool myself that head, we are not fooling ourselves, focusing on such issues. Try to formulate the question of the right language. It should not be heavy and formal - in fact, hacker culture values ​​in an informal, full of humor and slang language used correctly. But the thought must be expressed clearly; needs to demonstrate at least some signs of thoughtfulness and attention.

Observe the rules of syntax, punctuation and use capital letters. Do not confuse "its" with "it's", "loose" with "lose", or "discrete" with "discreet". Do not write in ALL CAPS - is perceived as shouting and considered rude. (If it is written in lower case - not much better, because so hard to read Alan Cox is forgiven, and you -. No.)

In general, if you write at the level of children's babble or delirium of a madman, your question is likely to be ignored. Scribble style minors "hatskerov" (in the original - l33t script kiddie hax0r - comment of the translator.) - Is absolutely hopeless, and guarantees in response - silence (or, at best, a portion of neglect and sarcasm).

If you ask questions in a forum that does not use your native language, some lexical and grammatical errors you forgive - but no forgiveness elementary laziness do not wait (yes, we are usually able to understand the difference). Also, if you do not know exactly which languages ​​to the addressee - family, please write in English. Busy hackers usually just skip questions in languages ​​they do not understand, and English - working language Internet. Ask a question in English, you lessen the likelihood that it will miss not reading.

Please send all questions to understand format

If you artificially make it difficult to read the question, increases the likelihood that the answer to the question, which is not difficult to read instead. Therefore:

• Send the message in plain text instead of in HTML format. ( Disable HTML is not too difficult.)

• MIME-applications are usually quite acceptable, but only if they are real content (eg, attached source code or patch file), and not just automatically generated e-mail client (representing, for example, another copy of the letter, but in HTML format).

• Do not send messages that paragraphs are presented in one line, visually shifting to the next line on the client. (This complicates the response to the part of the message.) On the assumption that the recipient will read the message on text terminals with lines of 80 characters, and adjust accordingly insert hard line breaks, ending a string of up to 80 positions.

• In this case, however, break into multiple lines at a fixed position data (e.g., magazines or dumps recording sessions). These should be included in the message as they are to the recipients were confident that they are seeing exactly what you saw.

• Do not send messages encoded MIME Quoted-Printable in an English-language forum. This encoding can be necessary when sending a message in a language that is not covered by ASCII encoding, but many custom mail agents do not support it. Read posts scattered throughout the text control characters type = 20 uncomfortable 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 like this, how would you respond if you smeared door pig shit. Even when they can read them, the need to tinker with these formats they resent.

• When sending a message to a Windows machine, turn off Microsoft-moronic ovsky support "Smart Quotes". This will get rid of many garbage characters scattered around the post.

• In the Web-forums do not abuse "smiley" and insert capabilities "html" (if provided). One or two smiles - this is usually normal, but colorful funny text leads people to think that you - lamer. Excessive use of emoticons, colors and fonts you as risible is a teenage girl, that does not make sense, unless of course you are interested in answers, not sex.

If you use e-mail client with a graphical interface (eg, Netscape Messenger, MS Outlook, and the like), remember that it may violate these rules when using the default settings. In most of these clients have a team type "View Source" menu. Check with the help of one of the sent message that is sent plain text, without unnecessary waste.

Similarly, and describe the problem in detail

• Carefully and clearly describe the symptoms of problems or errors.

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

• Describe the research you did to try and understand the problem before you asked the question.

• Describe the steps you took to diagnose and isolate the problem before you asked the question.

• Describe recent changes in your computer or software configuration that might be relevant.

Do the best you can to anticipate potential issues and advance the hacker to answer them in his appeal for help.

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

The volume does not mean accuracy

Be precise and informative. It is not enough just to insert the query a lot of code or data. If you have a large, complicated test case, resulting in an error in the program, try to minimize it.

This is useful for at least three reasons. The first is demonstrated by efforts to simplify the issue increases the likelihood of a response. The second is the simplification of the issue increases the likelihood of getting a useful answer. Third: during refinement error messages you yourself can find a solution or workaround.

Do not claim you have found a mistake

If you have any problems with this or that software do not claim to have found an error, unless absolutely sure of that. Tip: If you can not provide the source code fix that solves a problem or a test case for a previous version that demonstrates incorrect behavior, you are likely to believe enough in a statement.

Keep in mind that many other people are not faced with such a problem. Otherwise you would have learned about it while reading documents or searching the Web (you did do that, before making such statements, does not it ?). This means that, most likely, you are doing something wrong, not the software.

The creators of the software applied great efforts to make it work as best as possible. If you claim that you have found a mistake, thus suggesting that they have done something wrong, and it is almost certain they do not like - even if you're right. Especially undiplomatic to write a "bug" ( "Error") in the subject line.

When asking a question, it is better to describe the problem, assuming that you are doing something wrong, even if you personally are absolutely sure that you have found a mistake. If this is an error, you will read about it in the answer. Try to behave so that people involved in supporting the program wanted to apologize to you, if the detected error is real, not that you had to apologize for his stupidity.

The public self-humiliation is not a substitute homework

Some, having understood that we should not behave rudely or arrogantly, extorting response, choose the opposite extreme - self-humiliation. "I know, I'm a beginner, a loser and a full tea, 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 self-pity. Imagine the best facts and your question as clearly as possible. So you bragging rights much better than through self-abasement.

Sometimes Web-forums have separate places for beginners questions. If you feel that this question can only set a novice user, ask him there. But there does not need to be humiliated.

Describe the problem's symptoms, not your assumptions

It is useless to hackers report their opinion on the causes of the problem. (If your diagnostic theories are so valuable, whether to seek the help of others?) Therefore, verify that inform the actual symptoms of what is happening, rather than their interpretations and theories. Let the interpretation and diagnosis will be engaged in responsible.

Silly:

I keep getting SIG11 errors when compiling the kernel, and I suspect that the reason - a hairline crack on the motherboard. How best to test it?

reasonable:

On the assembled my computer K6 / 233 FIC-PA2007 motherboard (VIA Apollo VP2 chipset) with 256MB Memory Corsair PC133 SDRAM starts frequently occur SIG11 errors about 20 minutes after the power is turned on, in the course of compiling the kernel, but they do not occur in the first 20 minutes. Reboot to nothing lead, but the trip at night helps. Replacing the entire memory has not helped. The relevant part of a typical compile the results attached.

Describe the symptoms of the problem, in chronological order

The most important information to determine the causes of what is happening is often associated with the immediately preceding this situation events. It is therefore necessary to describe exactly what you did, and that made the car up to the problem. In the case of working with the command line interface can really help a session record (for example, using the script utility) and the inclusion of a message a couple of dozen relevant lines.

If a program in which the failure occurred, has diagnostic options (for example, -v - detailed information), try to choose the options that add useful debugging information to the "transcript" of the session.

If the record is already too long (more than a page), it makes sense to pre-formulate the problem in the beginning, and then specify the chronological sequence of actions that lead to it. In this case, hackers will know what to look for when reading session.

Describe the goal, not a single step

If you are trying to figure out how to do anything (and not reporting a bug), begin by describing the goal. Only then describe the particular step towards it that you could not perform.

Often, people who need technical help have a high-level goal in mind and become attached to one of the possible, in their opinion, the ways to achieve it. They are asking for help to perform a single step, without realizing that chose the wrong path. To understand this, it may take a lot of effort.

Silly:

How to make color selection dialog in the program FooDraw accept hexadecimal RGB-value?

reasonable:

I'm trying to replace the color table in the image values ​​necessary to me. Now I see only one way to do it - by editing each table slot, but I can not specify a hexadecimal value in the RGB-select program FooDraw color dialog.

The second version of the question - is reasonable. It allows you to get an answer, which will be offered to remedy more suitable for solving the problem.

Do not ask to respond to a personal email address

Hackers believe that solving problems should be a public, transparent process during which a first attempt to find an answer can and should be corrected if someone more knowledgeable will notice that this answer - incomplete or incorrect. In addition, corresponding partly rewarded by the fact that their expertise and knowledge to be seen colleagues.

When you ask for a personal reply, you are preventing a decision-making process and receivable. Do not do this. Answer person - it is a choice in charge - and if he does, it's usually because he thinks the question is too poorly formulated or obvious to be interesting to others.

Because of this rule, there is one small exception. If you suspect that your question will get many such responses among themselves, do not forget the magic words "please send the answer to me, and I summarize the answers in the article to a discussion group." Trying to keep a discussion group or mailing list from the stream, in fact, identical messages - it's very kind, but you have to keep the promise and send a final summary.

Ask clear and precise questions

Unlimited questions usually require unlimited time to respond. People are likely able to give you a useful answer, even the busiest people (also because most of their work make yourself). Such people are jealous of his time, and therefore often do not take unlimited questions.

The probability of getting a useful response is enhanced if you give it clear that by striving for responsible (to provide links, send code, check your solution, etc.). This meeting will focus and implicitly asks the restriction in time and effort that would have to be spent in charge to help you. It's good.

To understand the world in which live the experts, it is necessary to refer to the expert knowledge as a resource abundant, and their time - as a resource is very limited. The less time you implicitly require, the more likely to get an answer from the really good and engaged expert.

So it makes sense to limit the question to minimize the time it takes an expert to resolve it. But this is often 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 more reasonable than the request, "Explain to me X, please." If you have a problem with a non-working code would be wise to ask to explain what it is not, and does not ask to correct the mistakes.

Do not ask questions of homework

Hackers are well able to answer questions from the homework - most of us have made their own. These questions are asked for you, so you can learn from their experiences. Asking about possible clue, but not a complete solution.

If you suspect that you have thrown the issue of homework, but I still can not give an answer, try to ask a question in a forum or a group of users (in extreme cases) in the "user" mailing list / forum of the project concerned. Although hackers and it "recognizes" some of the advanced users may at least give you a hint.

Avoid meaningless requests

Do not be tempted to conclude his inquiry meaningless questions like: "Do I help someone?" or "Is there an answer?" Firstly, if you are in any way competent to describe your problem, such a question, as a minimum, superfluous. Second, because they are superfluous, hackers they seem annoying - and in response to them and inciting write logically impeccable runaround like: "Yes, you can help" or "No, you have no help."

In general, the answers yes-no questions better not to ask, if you do not want to answer yes-or-no .

Do not mark your question as "Urgent", even if it is just such for you

That's your problem, not ours. Mention of urgency is often counter-productive: most hackers simply delete such messages as rude and selfish attempts to immediately attract attention.

This rule is one partial exception. Mention of urgency might make sense if you are using the program in a serious organization that may be interested hackers; In this case, if you do not have enough time and you report it politely, people may not be interested enough to answer faster.

So doing, however - very risky, because the point of view of the seriousness of the hacker and his interests are likely to differ from your own. The issue with the International Space Station, for example, will be of interest, but the question on behalf of a successful charitable foundation or a political party, almost certainly - not. In fact, the question with the subject "Urgent: Help me save the fuzzy baby seals!" It will be ignored or maliciously commented even by hackers who think fuzzy baby seals that life has meaning for them.

If this surprises you, re-read the rest of the document as long as do not understand, and to refrain from sending it matters at all.

Courtesy never hurts, and sometimes helps

Be polite. Use of the phrase "Please" and "Thanks in advance". Make it clear that grateful people, devoting your free time.

To be honest, this is not as important as the absence of errors in the text of the question, clear, precise and detailed description of the use of open formats, etc. (And does not replace all of the above); hackers in general would prefer to get rough, but technically accurate error messages than polite verbiage. (If you are wondering, remember that we value a question of what it teaches us.)

However, under normal technical level, the question politeness does increase the likelihood of getting a useful answer.

(It should be noted that the only serious objection received this document from the hacker movement veterans, due to the recommendation to use the phrase "Thanks in advance". Some hackers see in her unwillingness to thank anyone was after the problem is solved. We recommend thanks in advance, and after receiving a response, or express your gratitude in a different way, for example, the phrase "Thank you" or "Thank you for your consideration".)

Send a brief description of the solution

Once the problem is resolved, send a message to all who helped you; let them know what it was over, and thank you again for help. If the problem is caused by a common interest in a mailing list or discussion group, it makes sense to send such a message.

Optimally be answered in the discussion thread, started with the original question, adding in the subject line marked 'FIXED', 'RESOLVED', 'Decision' or another equally obvious sign solutions. As with a lot of mailing lists posts, the potential charge when you look at the thread of discussion "Problem X", ends with the message "Problem X - SOLUTION" understands that he does not need to waste time even for reading messages (if he personally did not consider the problem of X interesting) and therefore can spend time solving a different problem.

This message does not have to be long and detailed; a simple "Hello, The problem has been associated with a break in the mains lead Bill Thank you all!." - it is better than nothing. In fact, a short and friendly summary is better than a long dissertation unless the solution is not affected by serious technical aspects. Write what action solved the problem, but the whole sequence of search solutions do not need to describe again.

For sufficiently serious problems can be sent separately to the history of the search of their reasons. Describe the final statement of the problem. Describe how the decision turned out, and enter the dead-end path, which should be avoided. What are all those who have helped you, so you will find yourself friends.

In addition to the display of courtesy and information, this kind of summarizing the message will help others when searching the archive mailing list / discussion group / forum to know exactly which solution helped you and thus may also help them.

Last but not least - this kind of message helps everyone who participated in the discussion to get a sense of satisfaction from the fact that the issue is closed. If you yourself - no technician and not a hacker, just trust us that this feeling is very important for the gurus and experts, to which you are seeking help. Descriptions of the problems, so in the end and not solved - it is a disappointment; hackers are eager to see them resolved. Good karma that occurs when you satisfy this craving, will be very helpful to you when setting the question next time.

Think about how you can prevent the same problem from other users in the future. Ask yourself whether the change will help documentation or FAQ list, and if so - send a corresponding change to those who support those documents.

Among hackers, this behavior is, in fact, considered to be more important than conventional politeness. That is earning a reputation as a good team player, which is a very valuable asset.

How to interpret the answers

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

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

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

In the Web-forums you can still suggest you search the archives online. In fact, the charge may be kind enough to give a link to the previous discussion, in which the problem was solved. But do not rely on it; search the archives themselves before asking.

Often the one who sends one of these answers is handy manual or web-page with the information you need, and looks at it when typing a reply. These responses indicate that, in his opinion, first of all, the information you need is easy to find, and secondly, you will learn more when searching for information than if you do it will present to himself on a platter.

You should not be anger; by hacker standards, he had enough respect for you is the fact that not ignored the question. You have to thank the answer for his fatherly kindness.

If you do not understand ...

If you do not understand the answer, do not send immediately demand him to explain. Use the same sources of information as when searching for an answer to the original question (manuals, FAQs, Web, experienced colleagues) to understand the answer. Then, if you need an explanation, show that you know yourself.

For example, suppose I have said: "It sounds like you hung zentry; it is necessary to check." Then poor clarifying questions will be: "What is zentry"? A good: "OK, I read the manual page, and about zentry there mentioned only in options, -z and -p none of them said how to reset a hung zentry Do I have to use one of these options, or I do.. -That misunderstood? "

Rudeness Reaction

Much of that may seem rude, it is not used to insults in hacker circles. It is, rather, a consequence of the direct, bluntly, communication style, natural for people who are trying to solve problems, rather than to seem other soft and fluffy.

When you meet with rudeness, try to react calmly. If someone really goes beyond the permissible, it is likely that the master mailing list, discussion group or forum will put him in his place. If this did not happen, and you get out of yourself, it is likely that which caused this person behaves under the rules of the hacker community, and everyone will believe exactly what you are wrong. This will significantly reduce the chances of obtaining the necessary information or assistance.

On the other hand, sometimes you can meet with rudeness and a challenge, not having any apparent reason. The reverse side of the coin is that this reaction is a perfectly acceptable form of setting in place the actual bullies - we cut off their misbehavior sharpened verbal scalpel. However, you should be very sure of your position before you try to do it. The distinction between an indication of bad manners and the beginning of the senseless "bazaar" (in the original - flamewar - comment of the translator.) Is so thin that the hackers themselves often pass it. If you are - beginner or just a casual reader, chances of avoiding such a blunder bit. If you are interested in information rather than entertainment, it is better remove your hands from the keyboard and do not risk to enter into such discussions.

(Some argue that many hackers suffer a mild form of autism or Asperger's syndrome , and they just do not have the part of the brain that is responsible for the "normal" social interaction between humans may be true, but maybe not if you.. - not a hacker, the notion of hackers as patients on the head can help you come to terms with our eccentricities Think what you want of us do not care;.. we like it to be such, and to clinical diagnoses we treat with healthy skepticism).

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

Do not react like a loser

It's likely that you've screwed up a few times in hacker forums - as described in this article, or similar. And you have explained how you screwed up, possibly in the paint. With all honest people.

When this happens, the bad reaction - to complain about the incident, considered himself insulted verbally, demand apologies, scream, choking with anger, sue, complain offenders to employers not to give for a toilet seat, etc. Instead of all this, do the following:

To reconcile. This is normal. In fact, it is good and appropriate.

Social norms do not support themselves - they are supported by people actively, openly, publicly, these rules apply. Do not think that should be criticized only in personal correspondence - it is not. It makes no sense to take as a personal insult someone's comment that one of your claims - wrongly, or that he has a different opinion. So there are losers.

There have been hacker forums where, on the basis of a misunderstood hypertrophic courtesy, participants are forbidden to send error messages in the wrong messages. They were told: "If you do not want to help the user, be silent." The outflow of knowledgeable participants in other forums has led to its degeneration into a senseless chatter and the complete uselessness from the technical point of view.

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

Remember: When that hacker wrote that you screwed up, and (no matter how rudely) asks you not to do, he does it, taking care in the first place, about you, and secondly, on their community. It would be much easier to ignore you and erase from your life. If you do not have to thanks, save the dignity - do not complain and do not think that you will be treated like a fragile doll just because you are - beginner to theatrically hypersensitive soul and delusions of self-importance.

Sometimes people will go to the individual, to enter into controversy dirty for no apparent reason, etc., even if you do not screw up (or just screwed up in their imagination). Resent in this case - a way to really screw up.

These "brawlers" - or lamer, who do not understand anything, but consider themselves experts or potential psychologists, inspectors, you screw up or not. Other readers either ignore them, or find ways to deal with them alone. Behavior brawlers creates problems for themselves, that should not bother you.

Do not let too drawn into useless "Bazaar". Such discussions are best ignored, having understood beforehand that it is really useless "market" rather than hints at why you really screwed up, and not subtly encrypted answers to your actual question (this happens as well).

Questions that do not need to ask

Here are some classic stupid questions, and what hackers are thinking when they do not respond.

Good and Bad Questions

Finally, I'm going to show by example, how to ask questions. I will present a couple of questions about the same problem, one - given the silly, and the second - right.

Stupid: Where can I find information about Foonly Flurbamatic?

This question just begs for an answer "STFW" .

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

This questioning has searched the Web and it looks like he - a real problem.

Stupid: I can not compile the code project foo. Why is it incorrect?

He thinks that somebody else screwed up. Self-confident type.

Right: foo draft code does not compile in OS Nulix version 6.2. I have read the FAQ (FAQ), but there was nothing about the problems with Nulix. Here are the compilation recording session; What did I do wrong?

He said on Wednesday, read the frequently asked questions, showed an error message, and he does not think that the cause of his problems at fault for someone else. This guy could be given some attention.

Stupid: I have a problem with the motherboard. Could anyone help?

Any hacker to such a question in the mind will answer most likely like this: ".? Well maybe you still help burp and change the diaper", and presses the Delete key.

Correct: I tried X, Y and Z on the motherboard S2464. When that did not work, I tried A, B, and C. Note the strange symptom when you try to C. Obviously, this is not garbage furychit, but the results are unpredictable. That usually leads to the fact that not furychat multiprocessor motherboard with Athlon? No Does anyone have ideas for additional tests that will help isolate the problem?

This fellow, on the other hand, seems worthy of an answer. He has demonstrated the ability to solve problems, rather than simply waiting for an answer he will fall from the sky.

In the latest issue of pay attention to small but important difference between "Give me an answer" and "Please help me figure out what additional diagnostic steps can be performed to clarify the situation."

In fact, the shape of the job the last question is very similar to the used real in August 2001, a mailing list linux-kernel. I (Eric) asked the same question. I watched the strange hovering on the motherboard Tyan S2464. Participants mailing list provided valuable information that helped me get rid of these lockups.

By asking the question this way, as I did, you give people food for thought; I did participate in solving the problem of easy and attractive for them. I demonstrated respect for the abilities of colleagues and invited them to a discussion on an equal footing. I also showed that the value of their time describing, in some dead-end, I have already passed.

Eventually, when I thanked everyone and said how good was the process of solving the problem, one of the mailing list I pointed out that, in his opinion, everything was not because I - "known person" on this list, but because of the correct form of the question.

Hackers, in some respects, very cruel intellectual elite (in the original - a meritocracy . Note interpreter.). I am sure that he is right, and if I screwed up, he would be criticized or ignored, regardless of previous achievements. His proposal is to describe the situation as a guideline for all others was the direct cause of compiling this guide.

If no response is received

If you do not receive a reply, do not take it personally, as our refusal to assist you personally. Sometimes forum members just do not know the answer. No response is not the same neglect, although the outside is difficult to notice the difference.

In general, the re-posting the question - not a good idea. This will be perceived as a meaningless boring.

There are other sources of help that can be accessed, and is often more adapted to the needs of beginners.

There are many groups of users in the network and on the ground, enthusiastically engaged in software, although many of the participants had never written a single major program. These groups often form so that participants helped each other and to new users.

There are also plenty of commercial companies, which can be contracted to support both large and small (one of the most famous - Red Hat and Linuxcare, but there are many others). Do not be afraid of the idea of ​​paying for your support! Ultimately, if needed overhaul of the car engine, you do give it to the workshop and will pay for the repairs. Even if nothing is worth the software, you can not expect that it will always support free of charge.

In popular software such as the Linux, on a single developer account for at least 10,000 members. One person simply can not cope with the support of 10,000 members. Remember that even if for support to be paid, it is still much cheaper than when you have to buy another, and the software itself (and the support of proprietary software typically costs more and runs less competent specialists than is the case with open source software code).

How to give good answers

Be generous. Linked to the problem of stress can make rude or stupid people who are not.

On the first error in select private. There is no need to publicly humiliate the man who may honestly mistaken. New user may not know how to search archives or where or published a list of frequently asked questions.

If you are not sure, say so! Wrong, but authoritative-sounding answer is worse than no answer. Do not point people in the wrong direction just because you have a wonderful stay in the role of an expert. Be humble and honest; set a good example for the asking, and colleagues.

If you can not help, do not interfere. Not kidding about the procedures that can destroy the user's environment - the fool can take your jokes as a guide to action.

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

While the simple answer is RTFM justified when given just a lazybones, a reference to documentation (even if it is for a set of keywords in Google search) is better.

Since you answer a question, give an answer on the point. Do not offer hastily devised workarounds, if applicable, in principle, not the means or the wrong approach. Suggest good tools. Reframe the question.

Help the public benefit from the issue. When dating a good question, ask yourself, "How should we change the relevant documentation or FAQ list to see more this question no one asked?". Then send an appropriate addition to the one who supports those documents.

If the answer to the question had to conduct research, share their experiences, and do not write as if the answer had fallen on you from the sky. Respond to a good question - it's like feeding the hungry once, but the technique to study the example - then learn to produce food for a lifetime.

Additional sources of information

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

When creating a software release or patches for software, try to follow the principles laid down in the manual Software Practice the Release the HOWTO .

Thanks

Evelyn Mitchell (Evelyn Mitchell) asked to comment on a number of stupid questions and inspired to write the section "How to give good answers." Michael Ramendik gave a number of suggestions to improve the document.