How to Ask a Question

I work in Technical Support, and I participate in a number of online communities. Not a week goes by without shaking my head when reading a question by someone seeking technical help.
I consider asking a question a form of communication. Any form of communication can be improved if we follow some guidelines and aim for some goals.
The main goal is to get an accurate answer to the question faster. This could be achieved by:

• Reaching expert audience
• Maintaining their attention
• Delivering the right question

Reaching Expert Audience

This is not just about going to the right forum or Q&A site to ask your question. Even in those places, there’s an audience reading your question that’s usually bigger than the experts you’re targeting.
Very early in your question, make clear what’s the focus of your question. Don’t start with background. It seems like a natural place to start with how things came to be. However, from the reader’s perspective, they want to know if this question is for them or not. Start with the big technology terms you’re using.
On the other hand, don’t be too specific to avoid pushing away some of your audience. Don’t say something like “Calling Adobe Flex Experts only”. Anyone who’s not an Expert will just move along, and it’s your loss because one of them have the answer to your question. Instead say “I’m having a problem with Adobe Flex”, or better, “I’m getting an error with Adobe Flex” or “I can’t do X with Adobe Flex”.
Your starting sentence is the synopsis of your problem.

Maintaining their Attention

Now that I have the right audience for my question, I gotta give them more details to get them thinking. The first paragraph of your question is a more detailed description of the problem. It’s not the most detailed description. The first sentence in a foot deep in the water, and the first paragraph is knee deep.
The first paragraph is the hardest part to write. You might think that the first sentence is more difficult because it’s shorter, but there’s only one (or at most, two) piece of information you need to deliver in the first sentence. The first paragraph is a summary of your problem with enough information to cause the reader to come up with a suggestion or ask for more details.
There’s a big upside in asking the question in this manner. You’re forced to think about how to phrase, or describe, the problem. This is a slightly different exercise than trying to solve the problem. In stepping back and looking at the problem from a far, you get to see things you’ve missed while neck deep into the details.
I’ve had clients emailing me with long technical details and attached code files asking for help, only to email me an hour later saying they’ve figured it out even though it wasn’t an easy problem. It’s just when they send the first email, they step away from the problem because someone else is looking into it now. This gives their minds enough space to wonder about the problem from a distance.
The same kind of thing happens to me as well. I would run into a problem. Frustrated, I run to a coworker asking for help. I start explaining the problem out loud, breaking down what’s wrong, and in the process of describing it I say “you know what? never mind. I found it”. They look at me not understanding what just happened but offering “you’re welcome” as I run back to my desk.
The first paragraph is about what not to write more than what to write. Don’t write about the background for the question, don’t write deep technical details like version numbers, don’t write long snippets of your code. Use your words, don’t just show your work and ask the reader to figure out what’s wrong.
There’s one exception to this which is error messages. These sum up the problem very well that they can cause the reader to offer a suggestion right away. However, they also beg the question: why didn’t you search for the error message. We’ll talk about this in a bit.

Delivering the Right Question

Your first paragraph got the reader thinking. The rest of your question is about answering the questions they’re most likely to ask, and shooting down the suggestions you’ve already tried.
This might be the place to provide background for your question. However, do so in a gradual manner. First, technical background, then less technical details. Start with “I’m trying to make the user data persistant on the client side”, then later talk about “I’m a contractor building an app for a financial institution”. Design your question on the assumption that the reader will stop reading half way either to leave or to answer.
Talk about what you’ve tried. It’s important to show that asking the question isn’t your first attempt to solve the problem. The reader’s time is precious and you want to show that you care about saving it. Give brief (one sentence) explanation on why this solution didn’t work for you.
Provide the technical details about your problem. This includes version numbers, configurations that you’ve set up, requirements and limitations you must adhere to. Any details that limit and rule out some of the possible solutions.
The idea here is to avoid wasting time on long exchanges about things other than solid suggestions you can act on. You don’t want to have a response like: “what version are you using?”. You don’t want to get answer like: “I’ve googled your question and I got this” then a response from you saying “I’ve tried this”. All these exchanges are wasting time and draining the attention of your audience. They’re losing interest in your problem as time goes on. The only people sticking around are the ones who have the same problem as you.

General Rules

Formatting
Formatting is very important. I don’t want to read through a ball of text. I want to be able to scan the text for a specific piece of information. Bold and italics are your friend. Break your text into paragraphs. Use lists and bullet points anywhere they make sense. Avoid stream-of-consciousness type of writing.
Be Mindful of your Readers
These are people who are trying to help you, usually only out of the goodness of their own hearts. Don’t waste their time. Understand that they could be busy if they don’t come back to follow up. Be grateful, not just for their suggestions but even for taking the time to read your question.
Finish the Story
When you finally find an answer, post it where you posted the question. You started out asking the Internet for help, it’s only suitable to help the Internet when you can. It’s temping to just move on, but think about all those long forum threads you stumble upon that matches your problem and goes on and on only to end with no good conclusion. It’s very frustrating.

You might end up with very short threads if you follow these rules. You can get the answer, or even shorter; no answer. It’s not as exciting as having people come in and ask you simple questions to get basic information or make basic suggestions. This gives the illusion that people are engaged and the solution is just around the corner. However, it’s not. It’s just wasting time, and giving the impression that you didn’t do your part.
People will read your question and probably end up not having an answer or making a suggestion. You can give them another chance to look at your question by providing an update every time you make some progress.
Happy troubleshooting!