Be sensitive in choosing where you ask your question. You're likely to be ignored, or written off as a loser, if you:

Hackers blow off inappropriately targeted questions, in order to try to protect their communications channels from being drowned in irrelevance. You don't want this to happen to you.

The first step, therefore, is to find the right forum. Again, Google and other Web-searching methods are your friend. Use them to find the project Web page most closely associated with the hardware or software giving you difficulties. Usually, it will have links to a FAQ (Frequently Asked Questions) list, and to project mailing lists and their archives. These mailing lists are the final places to go for help, if your own efforts (including reading those FAQs you found) don't find you a solution. The project page may also describe a bug-reporting procedure, or have a link to one; if so, follow it.

Shooting off an e-mail to a person or forum you're unfamiliar with is risky at best. For example, don't assume the author of an informative Web page wants to be your free consultant. Don't make optimistic guesses about whether your question will be welcome: If you're unsure, send it elsewhere, or refrain from sending it at all.

When selecting a Web forum, newsgroup, or mailing list, don't trust the name by itself too far; look for a FAQ or charter to verify your question being on-topic. Read some of the back traffic, before posting, so you'll get a feel for how things are done, there. In fact, do a keyword search for words relating to your problem, on the newsgroup or mailing list archives, before you post. It may find you an answer, and, if not, it will help you formulate a better question.

Don't shotgun-blast all available help channels at once; that's like yelling, and irritates people. Step through them.

Know what your topic is! One of the classic mistakes is asking questions about the Unix or Windows programming interface in a forum devoted to a language or library or tool portable across both. If you don't understand why this is a blunder, you'd be best off not asking any questions at all, until you get it.

In general, questions to a well-selected public forum are more likely to get useful answers than are equivalent questions to a private one. There are multiple reasons: One is simply the size of the pool of potential respondents. Another is the size of the audience; hackers would rather answer questions that educate many people than questions serving only a few.

Understandably, skilled hackers and authors of popular software are already receiving more than their fair share of mis-targeted messages. By adding to the flood, you could in extreme cases even be the straw that breaks the camel's back — quite a few times, contributors to popular projects have withdrawn their support because collateral damage in the form of useless e-mail traffic to their personal accounts became unbearable.

Your local user group, or your Linux distribution, may advertise a Web forum or IRC channel where new users can get help. (In non-English-speaking countries, new-user forums are still more likely to be mailing lists.) These are good first places, to ask, especially if you think you may have tripped over a relatively simple or common problem. An advertised IRC channel is an open invitation to ask questions there, and often get answers in real time.

In fact, if you got the program that is giving you problems from a Linux distribution (as common today), it may be better to ask in the distro's forum/list before trying the program's project forum/list. The project's hackers may just say, use our build.

Before posting to any Web forum, check if it has a Search feature. If it does, try a couple of keyword searches for something like your problem; it just might help. If you did a general Web search before (as you should have), search the forum anyway; your Web-wide search engine might not have all of this forum indexed recently.

There is an increasing tendency for projects to do user support over a Web forum or IRC channel, with e-mail reserved more for development traffic. So, look for those channels first, when seeking project-specific help.

When a project has a development mailing list, write to the mailing list, not to individual developers, even if you believe you know who can best answer your question. Check the documentation of the project and its homepage for the address of a project mailing list, and use it. There are several good reasons for this policy:

If a project has both a "user" and a "developer" (or "hacker") mailing list or Web forum, and you're not hacking on the code, ask in the "user" list/forum. Don't assume you will be welcome on the developer list, where they're likely to experience your question as noise disrupting their developer traffic.

However, if you're sure your question is non-trivial, and you get no answer in the "user" list/forum for several days, try the "developer" one. You would be well advised to lurk there for a few days, before posting, to learn the local folkways. (Actually, this is good advice on any private or semi-private list.)

If you can't find a project's mailing list address, but see only the project maintainer's address, go ahead and e-mail the maintainer. However, even in that case, don't assume the mailing list doesn't exist. Mention in your e-mail your unfruitful attempt to find an appropriate mailing list. Also mention that you don't object to having your message forwarded to other people. (Many people think private e-mail should remain private, even if nothing in it is secret. By allowing forwarding, you give correspondents a choice in handling your mail.)

On mailing lists, newsgroups, or Web forums, the subject header is your golden opportunity to attract qualified experts' attention, in around 50 characters or fewer. Don't waste it on babble like "Please help me" (let alone "PLEASE HELP ME!!!!"; messages with such subjects get discarded, by reflex). Don't try to impress us with the depth of your anguish; use the space for a super-concise problem description, instead.

One good convention for subject headers, used by many tech support organizations, is "object - deviation". The "object" part specifies what thing, or group of things, is having a problem. The "deviation" part describes observed deviation from expected behaviour.

The process of writing an "object-deviation" description will help you organise your thinking about the problem in more detail. What is affected? Just the mouse cursor, or other graphics, too? Is this specific to the X.org version of X? To version 6.8.1? Is this specific to Fooware video chipsets? To model MV1005? A hacker who sees the result can immediately understand what you're having a problem with and the problem you're having, at a glance.

If you ask a question in a reply, be sure to change the subject line to indicate you're asking a question. A Subject line resembling "Re: test" or "Re: new bug" is less likely to attract useful amounts of attention. Also, pare quotations of previous messages, to the minimum consistent with cluing in new readers.

Don't simply hit Reply on an existing list message, to start an entirely new thread: This will limit your audience. Some e-mail readers, like mutt, allow the user to sort by thread, and then hide messages in a thread by folding the thread. Such users will never see your message.

Changing the subject isn't sufficient. Mutt, and probably other e-mail readers, looks at other information in the e-mail's headers to assign it to a thread, not the subject line. Instead, start an entirely new e-mail.

On Web forums, the rules of good practice are slightly different, because messages are usually much more tightly bound to specific discussion threads, and often invisible outside those threads. Changing the subject when asking a question in reply is not essential. Not all forums even allow separate subject lines on replies, and nearly nobody reads them when they do. However, asking a question in a reply is a dubious practice in itself, because it will be seen only by those who're watching this thread. So, unless you're sure you want to ask the people currently active in the thread, start a new one.

Finishing your query with "Please send your reply to..." makes it quite unlikely you'll get an answer. If you can't be bothered taking even the few seconds required to set up a correct Reply-To header in your e-mail agent, we can't be bothered to take even a few seconds to think about your problem. If your e-mail program doesn't permit this, get a better e-mail program. If your operating system doesn't support any e-mail programs permitting this, get a better operating system.

In Web forums, asking for a reply by e-mail is outright rude, unless you believe the information may be sensitive (and somebody will, for some unknown reason, let you but not the whole forum know it). If you want an e-mail copy when somebody replies in the thread, request that the Web forum send it; this feature is supported almost everywhere, under options like watch this thread, send e-mail on answers, etc.

We've found by experience that careless, sloppy writers are usually also careless, sloppy thinkers and coders (often enough to bet on, anyway). Answering questions for careless, sloppy thinkers is not rewarding; we'd rather spend our time elsewhere.

So, expressing your question clearly and well is important. If you can't be bothered to do that, we can't be bothered to pay attention. Spend the extra effort to polish your language. It doesn't have to be stiff or formal — in fact, hacker culture values informal, slangy, and humorous language used with precision. However, it has to be precise; there has to be some indication that you're thinking and paying attention.

Spell, punctuate, and capitalise correctly. Don't confuse "its" with "it's", "loose" with "lose", or "discrete" with "discreet". Don't TYPE IN ALL CAPS; this is read as shouting, and considered rude. (All-smalls is only slightly less annoying, as it's difficult to read. Alan Cox can get away with it; you can't.)

More generally, if you write like a semi-literate boob, you'll very likely be ignored. Writing like a l33t script kiddie hax0r is the absolute kiss of death, and guarantees you'll receive nothing but stony silence (or, at best, a heaping helping of scorn and sarcasm), in return.

If you're asking questions in a forum not in your native language, you'll get a limited amount of slack for spelling and grammar errors — but no extra slack at all for laziness (and yes, we can usually spot the difference). Also, unless you know what your respondent's languages are, write in English. Busy hackers tend to simply flush questions in languages they don't understand, and English is the Internet's working language. By writing in English, you minimise the chance of your question being discarded unread.

If you make your question artificially hard to read, it's more likely to be passed over in favor of one that isn't. So:

If you're using a graphical-user-interface e-mail client, (such as Netscape Messenger, MS Outlook, or their ilk), beware that it may violate these rules when used with its default settings. Most such clients have a menu-based "View Source" command. Use this on something in your sent-mail folder, verifying sending of plain text without unnecessary attached crud.

Do the best you can to anticipate the questions a hacker will ask, and answer them in advance in your request for help.

Simon Tatham has written an excellent essay entitled How to Report Bugs Effectively. I strongly recommend you read it.

You need to be precise and informative. This end is not served by simply dumping huge volumes of code or data into a help request. If you have a large, complicated test case that breaks a program, try to trim it and make it as small as possible.

This is useful for at least three reasons. One: Being seen to invest effort in simplifying the question makes it more likely you'll get an answer, Two: Simplifying the question makes it more likely you'll get a useful answer. Three: In the process of refining your bug report, you may develop a fix or workaround, yourself.

When you're having problems with a piece of software, don't claim you've found a bug, unless you're very, very sure of your ground. Hint: Unless you can provide a source-code patch fixing the problem, or a regression test against a previous version that demonstrates incorrect behaviour, you're probably not sure enough. This applies to Web pages and documentation, too; if you've found a documentation bug, you should supply replacement text and a note as to which pages it should go on.

Remember, many other users aren't experiencing your problem. Otherwise, you would have learned about it while reading the documentation and searching the Web. (You did do that before complaining, didn't you?) This means that very probably it's you who're doing something wrong, not the software.

The people who wrote the software work very hard to make it work as well as possible. If you claim you've found a bug, you'll be implying they did something wrong, and will almost always offend them — even if you're correct. It's especially undiplomatic to yell "bug" in the Subject line.

When asking your question, write as though you assume you're doing something wrong, even if you're privately pretty sure you've found an actual bug. If there really is a bug, you'll hear about it in the answer. Play it so the maintainers will want to apologise to you if the bug is real, rather than so you'll owe them an apology if you've messed up.

Some people who get that they shouldn't behave rudely or arrogantly, demanding an answer, retreat to the opposite extreme, of grovelling. ("I know I'm just a pathetic new user, but...".) This is distracting, and unhelpful. It's especially annoying when it's coupled with vagueness about the actual problem.

Don't waste your time, or ours, on crude primate politics. Instead, present the background facts and your question as clearly as you can. That is a better way to position yourself than by grovelling.

Sometimes, Web forums have separate places for new-user questions. If you feel you do have a new-user question, just go there. However, don't grovel there, either.

It's not useful to tell hackers what you think is causing your problem. (If your diagnostic theories were such hot stuff, would you be consulting others for help?) So, make sure you're telling them the raw symptoms of what goes wrong, rather than your interpretations and theories. Let them do the interpretation and diagnosis.

Since the preceding point seems to be a tough one for many people to grasp, here's a phrase to remind you: "All diagnosticians are from Missouri." That US state's official motto is "Show me" (earned in 1899, when Congressman Willard D. Vandiver said "I come from a country that raises corn and cotton and cockleburs and Democrats, and frothy eloquence neither convinces nor satisfies me. I'm from Missouri. You've got to show me.") In diagnosticians' case, it's not a matter of skepticism, but rather a literal, functional need to see whatever is as close as possible to the same raw evidence that you see, rather than your surmises and summaries. Show us.

The clues most useful in figuring out something that went wrong often lie in the events immediately prior. So, your account should describe precisely what you did, and what the machine did, leading up to the blowup. In the case of command-line processes, having a session log (e.g., using the script utility) and quoting the relevant twenty or so lines is very useful.

If the program that blew up on you has diagnostic options (such as -v for verbose), check for options useful in adding debugging information to the transcript.

If your account ends up being long (more than about four paragraphs), it might be useful to succinctly state the problem up top, and then follow with the chronological tale. That way, hackers will know what to watch for, in reading your account.

If you're trying to find out how to do something (as opposed to reporting a bug), begin by describing the goal. Only then, describe the particular step towards it, on which you're blocked.

Often, people seeking technical help have a high-level goal in mind, and get stuck on what they think is one particular path towards the goal. They come for help with the step, but don't realise the path is wrong. It can take substantial effort to get past this.

The second version if the question is smart. It allows answers suggesting tools better suited to the task.

Hackers believe solving problems should be a public, transparent process, during which the first try at an answer can and should be corrected, if someone more knowledgeable notices incomplete or incorrect data. Also, helpers get some of their reward for being respondents from being seen to be competent and knowledgeable by their peers.

When you ask for a private reply, you're disrupting both the process and the reward. Don't do this. It's the respondent's choice whether to reply privately — and, if he or she does, it's usually because he/she thinks the question is too ill-formed or obvious to be interesting to others.

There is one limited exception to this rule. If you think the question may attract a number of similar answers, then the magic words are "e-mail me and I'll summarise answers for the group". It is courteous to try and save the mailing list or newsgroup a flood of substantially identical postings — but you must keep the promise to summarise.

Open-ended questions tend to be perceived as open-ended time sinks. Those people most likely to be able to give useful answers are also the busiest (if only because they take on the most work themselves). People like that are allergic to open-ended time sinks; thus, they tend to be allergic to open-ended questions.

You're more likely to get a useful response if you're explicit about what you want respondents to do (provide pointers, send code, check your patch, whatever). This will focus their effort, and implicitly put an upper bound on the time and energy a respondent must allocate for helping you. This is good.

To understand the world experts live in, think of expertise as an abundant resource, and time to respond as a scarce one. The less time commitment you implicitly request, the more likely you are to get an answer from someone really good and really busy.

So, it's useful to frame your question to minimise the time commitment required for an expert to field it — but this is often not the same thing as simplifying the question. Thus, for example, "Would you give me a pointer to a good explanation of X?" is usually a smarter question than "Would you explain X, please?". If you have some malfunctioning code, it's usually smarter to ask what's wrong with it than to request someone to fix it.

Hackers are good at spotting homework questions; most of us have done them ourselves. Those questions are for you to work out, so you'll learn from the experience. It is OK to ask for hints, but not for entire solutions.

If you suspect you've been passed a homework question, but can't solve it anyway, try asking in a user group forum or (as a last resort) in a "user" list/forum of a project. While the hackers will spot it, some of the advanced users may at least give you a hint.

Resist the temptation to close your request for help with semantically-null questions like "Can anyone help me?" or "Is there an answer?" First: If you've written your problem description halfway competently, such tacked-on questions are at best superfluous. Second: Because they are superfluous, hackers find them annoying — and are likely to return logically impeccable but dismissive answers like "Yes, you can be helped" and "No, there is no help for you."

In general, asking yes-or-no questions is a good thing to avoid unless you want a yes-or-no answer.

That's your problem, not ours. Claiming urgency is very likely to be counter-productive: Most hackers will simply delete such messages as rude and selfish attempts to elicit immediate and special attention.

There is one semi-exception: It can be worth mentioning if you're using the program in some high-profile place, one hackers will get excited about; in such a case, if you're under time pressure, and you say so politely, people may get interested enough to answer faster.

This is a very risky thing to do, however, because the hackers' metric for what is exciting probably differ from yours. Posting from the International Space Station would qualify, for example, but posting on behalf of a feel-good charitable or political cause would almost certainly not. In fact, posting "Urgent: Help me save the fuzzy baby seals!" will reliably get you shunned or flamed, even by hackers who think fuzzy baby seals are important.

If you find this mysterious, re-read the rest of this HOWTO repeatedly, until you understand it, before posting anything at all.

Be courteous: Use "Please" and "Thanks for your attention" or "Thanks for your consideration". Make it clear you appreciate time spent helping you for free.

To be honest, this isn't as important as (and cannot substitute for) being grammatical, clear, precise, and descriptive, avoiding proprietary formats, etc.; hackers in general would rather get somewhat brusque but technically sharp bug reports than polite vagueness. (If this puzzles you, remember that we value a question by what it teaches us.)

However, if you have your technical ducks in a row, politeness does increase your chances of getting a useful answer.

(We must note that the only serious objection we've received from veteran hackers to this HOWTO concerns our previous recommendation to use "Thanks in advance". Some hackers feel this connotes an intention not to thank anybody afterwards. Our recommendation is to either say "Thanks in advance" first and thank respondents afterwards, or express courtesy in a different way, such as by saying "Thanks for your attention" or "Thanks for your consideration".)

Send a note after the problem has been solved, to all who helped you: Let them know how it came out, and thank them again for their help. If the problem attracted general interest in a mailing list or newsgroup, it's appropriate to post the followup there.

Optimally, the reply should be within the thread started by the original question post, and should have 'FIXED', 'RESOLVED', or an equally obvious tag in the subject line. On mailing lists with fast turnaround, a potential respondent who sees a thread about "Problem X" ending with "Problem X - FIXED" knows not to waste time even reading the thread (unless he/she personally finds Problem X interesting), and therefore can use that time solving a different problem.

Your followup needn't be long and involved; a simple "Howdy — it was a failed network cable! Thanks, everyone. - Bill" would be better than nothing. In fact, a short and sweet summary is better than a long dissertation, unless the solution has real technical depth. Say what action solved the problem, but you need not replay the whole troubleshooting sequence.

For problems with some depth, it's appropriate to post a summary of the troubleshooting history. Describe your final problem statement. Describe what worked as a solution, and indicate avoidable blind alleys. Name the names of people who helped you; you'll make friends that way.

Besides being courteous and informative, this sort of followup will help others searching the mailing-list / newsgroup / forum archives to know exactly which solution helped you, and thus may also help them.

Last, and not least, this sort of followup helps everybody who assisted feel a satisfying sense of closure, about the problem. If you aren't a techie or hacker, yourself, trust us: This feeling is very important to the gurus and experts you tapped for help. Problem narratives trailing off into unresolved nothingness are frustrating things; hackers itch to see them resolved. The goodwill scratching that itch earns you will be very, very helpful to you, next time you need to pose a question.

Consider how you might be able to prevent others from having the same problem in the future. Ask yourself if a documentation or FAQ patch would help. If the answer is yes, send your patch to the maintainer.

Among hackers, this sort of behaviour is actually more important than conventional politeness. It's how you get a reputation for playing well with others, which can be a very valuable asset.

There is an ancient and hallowed tradition: If you get a reply reading "RTFM", the person who sent it thinks you should have Read the Fucking Manual. He/she is almost certainly right. Go read it.

RTFM has a younger relative. If you get a reply that reads "STFW", the person who sent it thinks you should have Searched the Fucking Web. He/she is almost certainly right. Go search it. (The milder version of this is when you're told Google is your friend!)

In Web forums, you may also be advised to search the forum archives. In fact, someone may even be so kind as to provide a pointer to the previous thread, where this problem was solved. However, don't rely on this consideration; do your archive-searching before asking.

Often, the person sending either of these replies has the manual or the Web page with the information you need open, and is looking at it, as he or she types. These replies mean your respondent thinks (a) the information you need is easy to find, and (b) you will learn more if you seek out the information than if it's spoon-fed to you.

You shouldn't be offended by this; by hacker standards, he or she's showing you a rough kind of respect simply by not ignoring you. You should instead thank that person for grandmotherly kindness.

If you don't understand the answer, don't immediately bounce back a demand for clarification. Use the same tools you focussed on your original question (manuals, FAQs, the Web, skilled friends), to understand the answer. Then, if you still need to ask for clarification, exhibit what you've learned.

For example, suppose I tell you: "It sounds like you've a stuck zentry; you'll need to clear it." Then: Here's a bad followup question: "What's a zentry?" Here's a good followup question: "OK, I read the man page; zentries are only mentioned under the -z and -p switches. Neither of them says anything about clearing zentries. Is it one of these, or am I missing something here?"

Much of what looks like rudeness in hacker circles is not intended to give offence. Rather, it's the product of the direct, cut-through-the-bullshit communications style natural to people who're more concerned about solving problems than about making others feel warm and fuzzy.

When you perceive rudeness, try to react calmly. If someone really is acting out, very likely, a senior person on the list or newsgroup or forum will call him or her on it. If that doesn't happen, and you lose your temper, very likely the person you lose it against was behaving within hacker community norms, and you'll be considered at fault. This will hurt your chances of getting the information or help you want.

On the other hand, you'll occasionally run across quite gratuitous rudeness and posturing. The flip-side of the above is that it's acceptable form to slam real offenders quite hard, dissecting their misbehaviour with a sharp verbal scalpel. Be very, very sure of your ground, before you try this, however. The line between correcting an incivility and starting a pointless flamewar is thin enough that hackers themselves not infrequently blunder across it; if you're a new user or outsider, your chances of avoiding such a blunder are low. If you're after information rather than entertainment, it's better to keep your fingers off the keyboard than risk this.

(Some people assert that many hackers have a mild form of autism or Asperger's Syndrome, and are actually missing some of the brain circuitry lubricating 'normal' human social interaction. This may or may not be true. If you're not a hacker, yourself, it may help you cope with our eccentricities if you think of us as brain-damaged. Go right ahead. We won't care; we like being whatever we are, and generally have a healthy skepticism about clinical labels.)

In the next section, we'll talk about a different issue; the kind of "rudeness" you'll see when you misbehave.