admin_only: false

############################################################
#                                                          #
#            HOW TO ASK QUESTIONS THE SMART WAY            #
#                                                          #
############################################################

Original Authors: Eric S. Raymond, Rick Moen
Version: 1.0 (Adapted)
Original Copyright © 2001-2014 Eric S. Raymond, Rick Moen

SUMMARY

The quality of answers you receive to technical questions is directly proportional to the quality of the questions you ask. This guide explains how to formulate questions effectively to get satisfactory answers from experts, developers, and experienced users, particularly in the open-source and hacker communities.

TABLE OF CONTENTS

  1. Disclaimer
  2. Introduction: Understanding the Culture
  3. Before You Ask: Do Your Homework
  4. When You Ask: How to Frame Your Question
    • Choose the Right Venue (Stack Overflow, Forums, Lists)
    • Craft a Meaningful Subject Line
    • Write Clearly and Precisely
    • Provide Detailed, Relevant Information
    • Describe the Goal, Not Just the Step
    • Follow Proper Etiquette
  5. How to Interpret Answers
  6. Questions to Avoid
  7. Examples: Good vs. Bad Questions
  8. What to Do If You Don't Get an Answer
  9. How to Answer Questions Helpfully
  10. Related Resources

1. DISCLAIMER

This document is a guide on how to get help. The authors of this guide are NOT a help desk. We published this to show you how to get support from people who know about the specific hardware or software you are using. Do not contact us directly for technical support; we will ignore you. Asking us for help proves you have not understood this guide.

2. INTRODUCTION: UNDERSTANDING THE CULTURE

In the world of developers and tech experts ("hackers"), good, thought-provoking questions are valued as a stimulus and a gift. They can reveal unforeseen problems and deepen collective understanding.

However, these experts have a reputation for responding poorly to simple or lazy questions. This is not arrogance; it's a defense against those who are unwilling to think or do their own research before asking. Such people are considered "time sinks"—they take without giving back.

We are largely volunteers with busy lives. We filter questions ruthlessly to spend our time efficiently on those who demonstrate a willingness to be active participants in solving their own problems. It is not necessary to be a technical expert to get our attention, but it is necessary to show an attitude that leads to competence: alert, thoughtful, and observant.

If you want help, you must demonstrate that you are not a "loser" (or "luser"). The best way to get a rapid, helpful response is to ask like a smart, confident person who simply needs assistance with one specific problem.

3. BEFORE YOU ASK: DO YOUR HOMEWORK

Before posting a technical question, you must do the following:

  1. Search the archives of the forum or mailing list you intend to post to.
  2. Search the web for an answer (e.g., using Google).
  3. Read the official manual (RTFM - "Read The... Manual").
  4. Read the Frequently Asked Questions (FAQ) documents.
  5. Try to solve the problem by experimenting and inspecting the issue yourself.
  6. Ask a skilled friend for help.
  7. If you are a programmer, try reading the source code.

When you ask your question, mention that you have already done these things and briefly state what you learned. This establishes that you are not a lazy sponge and have respected the experts' time. For instance, stating "I searched Google for 'X error message' but the results didn't apply to my situation" is very helpful.

4. WHEN YOU ASK: HOW TO FRAME YOUR QUESTION

Choose the Right Venue

Be sensitive when choosing where to post. You will likely be ignored if you: * Post to a forum where your question is off-topic. * Post a basic question in a forum for advanced topics (or vice-versa). * Cross-post to many different newsgroups at once. * Email an individual who is not personally responsible for your problem.

Find the project's official webpage. It will usually link to the appropriate forums, mailing lists, FAQs, and bug-reporting procedures. Use these resources. In recent years, Stack Exchange sites have become a primary resource:

  • Stack Overflow: For programming questions.
  • Super User: For general computing questions.
  • Server Fault: For network and server administration.
  • Many projects (like Ubuntu, Android, etc.) have their own specific sites.

Craft a Meaningful Subject Line

The subject line is your best chance to grab an expert's attention in 50 characters or less. Avoid generic pleas like "Please help me." Instead, provide a concise problem summary.

A good convention is "Object - Deviation". Describe the thing that has a problem and how it's misbehaving.

* **POOR:** HELP! My laptop video is broken!
* **GOOD:** X.org 6.8.1 mouse cursor misshapen on Fooware MV1005 chipset.
* **BETTER:** X.org 6.8.1: misshapen mouse cursor on Fooware MV1005 chipset

Write Clearly and Precisely

Careless writers are often careless thinkers. To be taken seriously, you must express your question clearly.

  • Use clear, grammatical, and correctly spelled language.
  • Do NOT type in all caps, which is perceived as shouting.
  • Do not use "l33t" speak or instant messaging shortcuts (e.g., writing "u" for "you").
  • If English is not your first language, state that. You will be given some slack for language errors, but not for laziness.

Use Accessible, Standard Formats

Make your question easy to read. * Send emails as plain text, not HTML. * Do not send emails where paragraphs are single, long, wrapped lines. * Do not expect experts to open proprietary document formats like Microsoft Word (.doc). * On web forums, use smileys and formatting sparingly.

Provide Detailed, Relevant Information

  • Describe symptoms carefully, not your guesses about the cause.
  • Describe the environment: Machine, OS, application, and relevant versions (e.g., "Fedora 38", "Node.js v18.1").
  • Describe your research: What have you tried so far to solve the problem?
  • Describe diagnostic steps: What did you do to try and isolate the issue?
  • Provide a way to reproduce the problem in a controlled environment. A minimal, bug-demonstrating test case is the most effective way to get help with code.

"Volume is not precision." Don't dump hundreds of lines of code. Trim your example to the smallest possible piece that still demonstrates the problem.

Describe the Goal, Not Just the Step

If you are stuck on a particular step, explain your ultimate goal. You may be on the wrong path entirely, and an expert can suggest a better approach.

* **POOR:** How do I make the FooDraw color picker accept a hex RGB value?
* **GOOD:** I'm trying to replace a color palette in an image with my own
  values. I can't figure out how to input a hex RGB value into FooDraw's
  color picker to do this. Is there a better way?

Follow Proper Etiquette

  • Don't ask for private replies. Problem-solving should be public so others can benefit.
  • Don't post homework questions. These are for you to solve on your own.
  • Don't mark your question as "Urgent." This is your problem, not ours, and it is considered rude.
  • Courtesy helps. Use "Please" and "Thank you."
  • Follow up with the solution. After your problem is solved, post a brief note summarizing the solution. This is courteous, informative, and provides a sense of closure that helpers appreciate. Tag the subject line with [RESOLVED] or [FIXED].

5. HOW TO INTERPRET ANSWERS

RTFM and STFW

If you get a reply that says "RTFM" (Read The... Manual) or "STFW" (Search The... Web), the respondent believes you could have found the answer easily yourself. They are correct. Go do it. This is not an insult; by hacker standards, they are showing you respect by not ignoring you completely.

If You Don't Understand

Do not immediately ask for clarification. Use the same tools (manuals, web search, etc.) to try and understand the answer first. Then, if you still need help, show what you have learned from your research.

Dealing with Rudeness

Much of what seems rude is just a direct, no-nonsense communication style focused on solving problems, not on making people feel comfortable. Try to react calmly. If someone is truly out of line, a senior member of the community will likely correct them. If you overreact, you will be seen as the one at fault.

6. QUESTIONS TO AVOID

  • Q: Where can I find program X?

    • A: The same place I would: by searching the web. Learn to use a search engine.

  • Q: How can I use X to do Y?

    • A: You are assuming a solution. State what goal Y is, and be open to better methods.

  • Q: My program/configuration doesn't work.

    • A: This is a statement, not a question. Provide details or you will be ignored.

  • Q: I'm having problems with my Windows machine. Can you help?

    • A: Yes. Install an open-source OS. (Unless the question is about a specific cross-platform program, expect this response).

  • Q: How can I crack root / steal admin privileges / read someone's email?

    • A: You are a lowlife for asking and a moron for asking an expert to help you.

7. EXAMPLES: GOOD VS. BAD QUESTIONS

Example 1

  • Ineffective: Where can I find out about the Foonly Flurbamatic?
  • Effective: I searched Google for "Foonly Flurbamatic 2600" but found no useful programming information. Can anyone point me to the relevant documentation?

Example 2

  • Ineffective: I can't get the code from project foo to compile. Why is it broken?
  • Effective: The code from project foo fails to compile on Nulix v6.2. The FAQ does not mention this issue. Here is the last part of the compile log: [...]. Did I miss a step?

Example 3

  • Ineffective: I'm having motherboard problems. Can anyone help?
  • Effective: I tried X, Y, and Z on my S2464 motherboard. When that failed, I tried A and B. I noticed a strange symptom when I tried C. It seems the florbish is grommicking. What usually causes this on Athlon MP boards? What other tests can I run?

8. WHAT TO DO IF YOU DON'T GET AN ANSWER

Do not take it personally. The group may not know the answer. Re-posting your question is generally a bad idea and is seen as annoying.

There are other places to find help: * Local and online user groups. * Commercial companies you can pay for support. Don't be dismayed by this; even if the software is free, support is not always free.

9. HOW TO ANSWER QUESTIONS HELPFULLY

  • Be gentle. Stress can make people seem rude or stupid when they're not.
  • If you don't know for sure, say so. A wrong answer is worse than no answer.
  • If you can't help, don't hinder. Don't make jokes that could be misinterpreted as destructive instructions.
  • Ask probing questions to turn a bad question into a good one.
  • Give good value. Suggest better tools or reframe the question instead of offering a clumsy workaround.
  • Help the community learn. If you answer a good question, consider how the documentation or FAQ could be improved to prevent it from being asked again.