The title of the oldest revision of this SO question is, "Is it posible [sic]?" This doesn't provide any information at all. It should be mandatory for everyone asking questions on the Internet to read How To Ask Questions The Smart Way, which says:
Help your community learn from the question. When you field a good question, ask yourself "How would the relevant documentation or FAQ have to change so that nobody has to answer this again?"
I generally dislike people who link "How to ask questions the smart way" on Q&A sites and on IRC.
One, it is off-putting to a new user who, upon reading the basic FAQs, finds a 20-page manual on how to ask questions the "proper" way.
Secondly, the main problem with HTAQTSW is it caters and is useful to no one. Why is this? Because the people who could use it most will never read it. The people who ask poorly phrased, un-researched questions just aren't going to take the time to read a treatise on how to ask questions.
The people who do take the time to read it and understand it generally already ask questions of a higher caliber than most of the masses.
A while back Joel talked about "How to ask questions the smart way" on the podcast and I actually agreed with him on this point.
Main problems in my experience:
1. Look at the possible duplicates!
When you type in your title, a whole list of question appears underneath. You are supposed to look at those questions, to see if your question already have been asked.
2. Tell us what the problem is that you are trying to solve.
You got to Stack Overflow because you ran into some problem and during your efforts to fix that problem you ran into a wall. 90% of the time you ran into a wall because the way you decided to solve the problem is the wrong way. You end up trying to do something that is hard or impossible, like "How do I get the name of a variable in Python". Well, you don't. Python variables don't have names. In fact Python doesn't really have variables in the standard sense. You are barking up some sort of incorrect tree.
So tell what the problem is you are trying to solve, give us some context, so we can point you towards the right tree to bark up.
3. Format your code.
There is a button in the editor toolbar that looks like {}. Select your code, and press that button before you save. You also have a preview below your editor. There you can see how your question looks. Make sure it's readable.
That covers 99% of all bad questions.
I think the biggest issue is to make sure it's not a duplicate so:
Search first
Also make sure it's a question that can be answered without purely subjective responses:
No troll bait (apple vs pc...)
Make sure it's a question, this post for example has a clear question as a title, but the post is rather vague as to what the questions is.
Have a clear idea of what question you want to ask. Have a clear idea of what an answer would say.
Search SO to see if it's a duplicate. If so, learn from those answers.
Write a good title, which should convey what you're asking while not being too long.
Write the body clearly. Make it clear what you are asking.
Include all the constraints, and when applicable why they are constraints. Something like "must run on Linux" doesn't need an explanation, but something like "can't use Visual Studio" (on a Windows project) or "can't use open source" will need an explanation. Otherwise half the replies will either ignore the constraint or ask why.
Include a description of the environment. Not everybody runs BeOS, or Windows for that matter. Be as specific as you need to be.
Read the Eric Raymond link (the www.catb.orb one) in the question. It's got an excellent guide to the mindset needed to ask good questions, even if the examples given are all Greek to you.
Tag the question with useful tags. Look at other tags to see. Use commonly used tags (the tag entry line will help there).
Once you've asked, monitor the question. There may well be people who can help a lot provided they get more information.
For SO, I think asking questions the smart way includes describing the problem as clearly as possible with the least amount of waste (keep it short and to the point).
Format your text into paragraphs so it isn't a big chunk of text and use bold and italics to highlight words and phrases that are important to the context. Think of it as pre-highlighting the question. I like to bold key issues in my problem (how do I capture the space key with the TextCompositionManager since I don't want to use the InputManager for this).
Keep your code simple, clear and well formatted. This sucks:
public static void Foo(GeneralizationManager _fmainP, TargetLinkDesignator _bLol){
using(new TransactionalGeneralizationManagerTorquer(new ContextualBrachinatrix(), Repository.GetLatestTransactionalContext())){
foreach(InterstitialLink il in _bLol.Interstitials.Where(x => x.IsInternationalized))
//imagine this going on for thirty or more lines
}
}
So reformat your code to emphasize your issue:
public static void Foo()
{
using(new TransactionScope())
{
// how do I participate in this transaction?
}
}
Re-read your question after submitting and change anything you think might be confusing or that doesn't make sense.
And, when someone asks for additional information, don't hesitate to edit your question. Adding additional information in the question will bump it and make it likely that more people will read the question.
This was covered in Podcast 26:
Atwood: Have you read Eric Raymond's How to Ask Questions? Like this epic, 100,000 word--
Spolsky: Yeah. And that's the thing that he tried to encourage people to use as the answer to all Usenet questions that they don't feel like answering right now. Like, point everybody to How to Ask Questions?
Atwood: Well, this is why I say I think the more sophisticated Stack Overflow users are the ones that actually vote for questions. Maybe we should have some sort of promotional thing or bonus that comes with that because they appreciate how difficult it is to actually ask a good question.
Spolsky: Yeah.
Atwood: And I think a lot of people don't appreciate good questions. The irony of the thing that Eric Raymond wrote is that the type of people that ask bad questions are not going to read this giant "Treatise on how to ask questions." It's this total Catch-22 of a problem -- so who does this document actually serve at that point? It's just masturbation for someone.
Spolsky: Yeah. It's just the way you can be one of these annoying programmers which is like [condescending tone] "I'm not going to answer your question because you did not read this entire document."
Atwood: [laughs] But on Stack Overflow the advantage is that, unlike Usenet, people go in and fix your question. I won't give you my whole diatribe, but I've seen it happen again and again. People come in and help you fix your question, and it feels good. It feels good to help other people, I don't know why. It's really addictive. Even I, having built the system -- and frankly I'm a little bit sick of it at this point just because I'm doing it all day every day -- even I still get totally sucked into it. I'll spend hours, literally, just clicking around Stack Overflow, editing stuff, looking at stuff, learning stuff. The system is incredibly addictive, even to me, so I guess that's fair since we were the target audience. So I guess it would be a failure if that was not true. But I enjoy using the system, for what it's worth.
(from the transcript)
I've now written up a whole article on how to write a question effectively for Stack Overflow.
The key in my view is to read your question as if you were trying to answer it, and see whether it gives all the information you'd need, in the clearest possible way, showing that you're being considerate to those who are trying to answer. If it passes that test, it's likely to do well IMO.
As linked from the How to Ask page that is shown to every new user asking questions on Stack Overflow, and which is always linked in the rightmost column when asking a question:
And to learn about formatting:
There's no point having a guide for asking questions because the people it is aimed at are the least likely to find it and act on the information, but don't worry it doesn't matter.
Stack Overflow was designed with the realisation that poorly worded questions will occasionally be asked which is why it allows trusted users to edit questions to improve them.
The people who don't ask questions the "smart way" are the same users who would never read such a document.
The prudent user (most users) would first observe and watch the site for awhile to get the "lay of the land," then get their feet wet by answering a few simple questions... then ask their own questions when they are comfortable with the system.
There is, of course, no harm in writing such a "how to" document. It just won't actually solve any problems, assuming there is one.
Whenever possible, don't just dump all of your code on us and ask us to fix it "even if you give us the error messages." That means we have to compile/view it in a browser to analyze it. Be nice, and try to reproduce the problem with the smallest amount of code possible. I don't care about every single class in your file, or every bit of css style (we only want the relevant stuff). This makes it easier for us, and anyone else viewing your question in the future to understand the problem. :D
Oh, and try to avoid exclamation marks at all costs, and use good grammar and descriptive titles. No one likes the class "plzzz hulp meee" tagged only "programming"
Just found another nice and relevant "How to ask a question" article. (Thanks to HN again).
There's now an official page on this topic: see How to Ask
If you want to suggest any improvements to this page, you can do that as a feature-request on Meta.
A Question is composed of three distinct parts:
Body
By far the most important is the body of your question because this is where you pose the all important single question that you would like answered. It is the quality of your question body that engages or loses the attention of potential answerers.
You are provided with plenty of space and formatting tools here to assist you to present any background that potential answerers may need to understand your question.
Start by mentioning any relevant background. This saves potential answerers having to try and guess, or to ask, all of which may slow down or prevent an answer to your question.
The question body may well be the only part that potential answerers read and re-read after glancing at the title, so be sure to read and re-read it yourself, and to make ongoing edits to improve it as clarifications are sought by others via comments. You cannot assume that a potential answerer has read any of your previous questions, answers or comments so be sure to include all relevant details so that it can standalone.
Once written, a good cross-check on your question's body is whether it contains a single question mark? If that is the case, then what you are asking is clearly indicated. If you find yourself wanting to place more than one question mark in the body, then questions other than the most important one to you can always be researched/asked separately.
If you are asking a coding question I strongly recommend reviewing How to create a Minimal, Complete, and Verifiable example.
Title
The title is best written after the body of the question because it is there to summarise what is in the body. As a result it should not introduce any new terms or information not covered in the body. By making this as succinct and accurately descriptive of the body as possible you are likely to attract more potential answers than if you hastily pen something like "Help! stuff not working!!???".
My preference is for the title to always end in a question mark because that acts as a constant reminder that this site is about finding answers to questions.
Tags
These help the people who are willing to try and help you quickly find the subset of questions in which they have skills instead of having to open many in which they do not.
You can apply up to 5 tags that reflect the significant keywords that are likely to help group your question with others that are somewhat similar.
Do not worry if you get tags "wrong" - they are always quick and easy to fix as incoming questions are triaged as long as the information is in your question body.
What about Comments?
Comments are attached to, but do not form part of, your Question.
Their main purpose is to help you edit to improve your Question by requesting clarifications wherever potential answerers are unsure of what you are doing, using or asking.
Imagine the pleasure of a potential answerer reading just your Question body and thinking immediately "I know the answer to that", and answering it, versus reading a trail of back and forth comments between asker and commenters and thinking "does it mean this" or "does it mean that", and eventually "now I understand" or maybe not, or not bothering to read the comments and just moving on to the next Question.
What about Answers?
Answers should never be written in questions. We have a separate area for answers, and self-answering in that area is encouraged.
Is it OK to greet the audience for my question?
No, there is no chit chat in focused Q&A, and in any event potential answerers are more likely to be impressed by a quick to read and understand question, than a polite hurdle to get past before reaching the detail they came for.
Where do I include thanks in advance to those who may answer?
Don't - that is what upvotes and voting to accept (big green checkmark) are for.
Where do I include my signature and contact details?
Don't - your user card already signs every post that you make and, if you wish, your contact details can appear in that.
The particular question highlighted was a rather egregious example of 'how not to ask a question'. There was an interesting question on the inside, spoiled by appalling presentation. The original title and original content were both 'non-Smart'. The cleanup needed only a limited amount of work - and a degree of ruthlessness without disrespecting the original questioner's intent.
The material in 'Smart Questions' certainly should be cross-referenced and recommended reading. Some people will have sufficient knowledge and experience not to need to read it (they can ask decent questions without needing the explicit guidelines), but many would benefit from (re-)reading it.
Maybe the main FAQ for SO should include a cross-reference to it? That would be my first choice.
I'd like to point to T-SQL Grouping rows from the MAX length columns in different rows (?) as a good example of how to ask a question about a database. It provided the DDL for table definitions and INSERT statements for test data. As a result, I was able to just pop these scripts into my database system and get right to work answering the question.
I'd also like to know if people here feel there should be a separate question on "How to ask a Smart Question on Database Queries".
Just ask a simple question
There are no stupid questions..., answers may be stupid!
[faq]on SO before MSO existed, and the tag stuck when it got migrated here. This isn't even a question. It's just a short, thinly veiled rant. (Unless the OP is actually suggesting that SE somehow enforce making all askers read HTAQTSW, but that would be laughable.) I've voted to close and will flag to request de-FAQ-ification.