The following is borrowed from Experts Exchange. I have also opened up a discussion forum for comments. See How To Get Your Question Answered

First, before anyone cries plagiarism, let me say that this document borrows heavily from Eric S. Raymond's "How to Ask Questions The Smart Way" originally hosted here - http://www.catb.org/~esr/faqs/smart-questions.html. However in the interest of consolidating it down to a more concise representation, update it a bit, and give it a flavor more appropriate for Experts Exchange, I thought I'd rework it and post it for both users and experts to refer to when it is warranted.

The key to getting your questions answered in any type of Internet forum, newsgroup, or mailing list is to phrase your question in such a way that will make those you're asking WANT to answer your question. Even on Experts-Exchange, the experts themselves receive almost nothing for answering your question, beyond the satisfaction of helping someone else out, and the mental challenge of a new or particularly sticky problem. However, if you, the asker, have not taken the time to try to answer the question yourself, or to think through the problem with just basic problem-solving skills, we as the experts see red flags of a lengthy and time-consuming answer, and will often as not skip your question in favor of someone else who has exhibited those qualities. We all have normal lives, other jobs, and many different elements begging for our time. If you wish your question to rise to the top of those time-requests, you need to make sure that we are getting the most challenge, the most satisfaction, for the least amount of time possible.

The key: Do your homework to make it EASY for us to help you.

1) Think through your problem. If you haven't even tried to answer your own question, we'll be able to see it right away. This is one of the first questions to get skipped, because it's guaranteed to be be the tip of a large follow-up-question iceberg. A huge time-investment on our part for very little challenge or satisfaction.

2) Search First. If I can find the answer in 5 minutes using nothing but Google, you haven't done your homework, and are a waste of my time. Before you even ask a question, make sure you search Google, and check out at least the first page and a half of entries. Search the FAQ for the site or newsgroup you're asking in. Read any documentation relating to the products you're using. Only after you've exhausted those resources should you even be asking. And when you have done all these things, mention it in your post. That lets us know you did your homework, and are not just a mindless newbie, expecting to be spoon-fed.

3) Try to remove all your assumptions before asking. "How do I get Windows to run Linux?" is a bad question, because chances are pretty good you don't want to use Windows to run Linux. Apparently, what you want is to run Linux. The assumption of starting with Windows is most likely a faulty one. Tell us what you are trying to accomplish, and what limitations you have. Don't assume you're on the right track.

4) Ask in the right forum and only one forum. Don't ask a question about Javascript in an ASP.NET forum or a Windows question in a C++ forum. If you haven't at least narrowed down the specific area or technology in which the problem occurs, it's pretty much a sure thing you haven't done #1. If you're unsure which of two forums to post in, post it in one, and only when you don't receive an answer should you post it in the second.

5) Reduce your code to the simplist possible configuration that still presents the problem. If you're working on a project, create a second test project that reproduces the same problem, but doesn't have all the extraneous code that doesn't relate. You should almost always be able to reduce the code to 20 lines or less of what causes the problem. This helps two ways. One - just doing this often helps the problem area to present itself, and your question will be answered before you ask it; and Two - We do not want to read through 200 lines of irrelevant code to find the 3 lines of code that are actually the problem. The only exception to this rule is a stack dump or similar logging-type information, which should only be included at the END of the post, or better yet, hosted elsewhere with a hyperlink to get to it if needed.

6) Specify the problem exactly. Start with a short description, followed by exact steps to recreate the problem, what the expected result was, and what the actual result or error was. Be sure to include exactly what software or languages you're using, and what version, along with platform or OS. If the problem is intermittent, specify what causes the problem to come and go (as well as you can), or mention that you can't figure out what causes the discrepancy.

7) Briefly (!) describe what solutions you've already tried. This lets us know you've put some effort into it, and also gives greater clues as to what the problem might be.

8) Read your own post - carefully! Make sure you post is spelling- and grammatically-correct. Leave your l33t-speak for your teen-age friends on IM. Make sure you've said exactly what you needed to say, and remove anything that doesn't relate to the question at hand. If we can't understand what you're asking, chances are pretty low you'll get an answer.

9) Write a message subject that reflects your question or at least the topic. Subjects of HELP!!!! or URGENT!!!! are useless. Everyone thinks their problem is urgent, and they're all looking for help. Likewise subjects of "I'll never get this right..." or "What is causing this problem?" are better left for friendly emails. Better subject lines are "Windows crashes every time I run calc.exe" or "Emails are being sent to wrong addresses." Your subject line is your first chance to engage our interest. Don't waste it.

10) Describe the raw symptoms, not your conclusions. You're asking for help, so obviously you don't know what the problem is. List symptoms in the order they occured. The only exception is listing possible conclusions that you have tried and eliminated. This will help the answerer by avoiding trying things you've already tried. Although, you should be very careful here. Just because you tried something, doesn't mean you tried it correctly.

11) Ask a question, don't make a statement. You'd think this was obvious, but apparently not. Wrong="I can't get this code to work." Right="My code is throwing error 33, but I don't have any files involved. Does anyone know another reason error 33 would show up"

12) Think about what answer you want to receive. Don't ask a yes-or-no question unless you want a yes-or-no answer. Don't assume the answerer will want to expound, or be able to read your mind as to which area you want them to expound into. Wrong: "Is it possible to create a mortgage calculator in Coldfusion?" (Answer:yes) Right: "What's a good algorithm for calculating variable-rate mortgages?"

13) Assume you're the one doing something wrong, and take a humble, courteous attitude. Even if you secretly think the error is someone else's, it's better to be proven right, and get an apology from the person in the wrong, than to be arrogant and rude, and have to be the one to apologize if you're wrong.

14) Avoid the "Can I...?" question. For example, "Can I pass in a boolean to the DeleteTree() function?" Try it. Did it work? Then the answer is "yes." If not, the answer is "no." Don't bother us with this.

15) Avoid large-scale "How do I..." questions. "How do I?" questions are very often violations of rule #1 to begin with. But large scale ones are impossible to answer. This medium is not appropriate for long discourse. If we can't answer your question in a paragraph or two, we won't answer it. Wrong: "How do I make an e-commerce site?" Right:"What are the advantages of Motley's Paradigm over RFT-format (or vice-versa) when creating an e-commerce site in PHP?"


After you've asked your initial question:

14) If you don't understand a response, or have a follow-up question, use the same techniques you did in asking your question - search for the answer first, read the manuals for clues, etc. Don't assume that because someone already took the time to answer your question, they are now personally devoted to seeing you succeed. Also make sure a follow-up question is a follow-up question, and not an entirely new question, which should be posted seperately.

15) Say Thank you. Chances are you'll have another question sometime in the future. If you "Pay" the answerer with additional satisfaction from knowing they helped someone, they'll be more likely remember your name and be eager to answer you in the future.

16) If you find the answer to your own question, post the results so future people can find it.