Q: My program doesn’t work. I think system facility X is broken.

A: While it is possible that you are the first person to notice an obvious deficiency in system calls and libraries heavily used by hundreds or thousands of people, it is rather more likely that you are utterly clueless. Extraordinary claims require extraordinary evidence; when you make a claim like this one, you must back it up with clear and exhaustive documentation of the failure case.

Before You Ask

Before asking a technical question, do the following:

  • Try to find an answer by searching the archives of the forum you plan to post to.
  • Try to find an answer by searching the Web.
  • Try to find an answer by reading the manual.
  • Try to find an answer by reading a FAQ.
  • Try to find an answer by inspection or experimentation.
  • Try to find an answer by asking a skilled friend.
  • If you’re a programmer, try to find an answer by reading the source code.

When you ask your question, display the fact that you have done these things first; this will help establish that you’re not being a lazy sponge and wasting people’s time. Better yet, display what you have learned from doing these things. We like answering questions for people who have demonstrated they can learn from the answers.

Use tactics like doing a Google search on the text of whatever error message you get (searching Google groups as well as Web pages). This might well take you straight to fix documentation or a mailing list thread answering your question. Even if it doesn’t, saying “I googled on the following phrase but didn’t get anything that looked promising” is a good thing to do in e-mail or news postings requesting help, if only because it records what searches won’t help. It will also help to direct other people with similar problems to your thread by linking the search terms to what will hopefully be your problem and resolution thread.

Never assume you are entitled to an answer. You are not; you aren’t, after all, paying for the service. You will earn an answer, if you earn it, by asking a substantial, interesting, and thought-provoking question — one that implicitly contributes to the experience of the community rather than merely passively demanding knowledge from others.

On the other hand, making it clear that you are able and willing to help in the process of developing the solution is a very good start. “Would someone provide a pointer?”, “What is my example missing?”, and “What site should I have checked?” are more likely to get answered than “Please post the exact procedure I should use.” because you’re making it clear that you’re truly willing to complete the process if someone can just point you in the right direction.

Use meaningful, specific descriptions of the problem

One good convention for problem descriptions, used by many tech support organizations, is “object – deviation”. The “object” part specifies what thing or group of things is having a problem, and the “deviation” part describes the deviation from expected behavior.

Stupid: HELP! Video doesn’t work properly on my laptop!

Smart: X.org 6.8.1 misshapen mouse cursor, Fooware MV1005 vid. chipset

Smarter: X.org 6.8.1 mouse cursor on Fooware MV1005 vid. chipset – is misshapen

Be precise and informative about your problem

  • Describe the symptoms of your problem or bug carefully and clearly.
  • Describe the environment in which it occurs (machine, OS, application, whatever). Provide your vendor’s distribution and release level (e.g.: “pimp-1.5.6-amd-14.4”, etc.).
  • Describe the research you did to try and understand the problem before you asked the question.
  • Describe the diagnostic steps you took to try and pin down the problem yourself before you asked the question.
  • Describe any possibly relevant recent changes in your computer or software configuration.
  • If at all possible, provide a way to reproduce the problem in a controlled environment.
  • Do the best you can to anticipate the questions a hacker will ask, and answer them in advance in your request for help.
  • Giving people the ability to reproduce the problem in a controlled environment is especially important if you are reporting something you think is a bug in code. When you do this, your odds of getting a useful answer and the speed with which you are likely to get that answer both improve tremendously.

Adapted from the terrific article How To Ask Questions The Smart Way by Eric Steven Raymond: http://www.catb.org/esr/faqs/smart-questions.html