As programmers we are daily faced with having to get requirements, test things out, etc.
It's practically half our job to know what questions to ask, and how to ask them to get the most concise, actionable answer possible, especially from reluctant users/managers/customers/etc.
How do you ask questions that get answers?
This is something for the FAQ... it's been beaten to death. Hopefully people signing up for this site will understand... "How to ask questions the right way"
http://www.catb.org/~esr/faqs/smart-questions.html
Of course, the people who ask dumb questions are the same kind of people who won't read that article - "it's too long, I just want my answer!"
I think this site is doing a good job of discouraging the annoying behaviors that are rampant on other forums, but we're still in a private beta phase, so I'd like to think we're getting better quality folks here right now than what we'll see in the future. When it opens up to the public, I imagine there will be a lot of "plz snd the codez" questions... but we'll have to see.
This is an ok point, but the thing is, asking good questions involves already having some knowledge of the topic, which the user often doesn't have. If he googles the topic, he's gonna find it, refining the search and googling some more will maybe answer the question, and he's not gonna post it here. Some users are terribly lazy at googling. I often answer some questions by simply googling it by keywords, and yanking/pasting the first results.
So, I'll say, let them ask the questions in the form they wish. Questions will be modifies, refined and rewritten if necessary, and in the end we will have a good answer on the topic. Duplicate ones can easily be deleted (and usually are).
Answer to lothar since comments are too short: Yes, of course it is. But, as I tried to point out, a new user will maybe not know it is a bad question. Because from his point of view (doesn't know) it is a valid question. And it is really. From yours or mine, naturally, it is a bad/boring/repetitive question, 'cause we've seen it so many times before. That is a way of learning. To be a teacher one has to be patient.
Now, as you probably guess, this can be taken to the extreme. Trolls arise. So the question is "how to stop users from continuously asking bad question, which everyone can see make no sense?". Should something like, "question closed for LAZY USER reason - user cannot post another for 24h" be implemented (where LAZY USER would be a category where the answer to your question appears in the upper block while you're writing the question).
Judging from the tags, I took this as a question about requirements collection, which so far puts me in quite a minority.
The problem with soliciting useful requirements from customers essentially lies in the difference between natural and formal languages. We need discrete answers to questions about how the system needs to work. But people naturally insist on qualifiers like "well, usually" or "most of the time".
So I believe the trick to asking questions that get useful answers for the purpose of requirement collection (if that's what you were asking about), is to define, define, define!
Formally document all of the terms that have special meaning to your project, and make sure that the client always has a current copy. Until you've come to terms on these definitions, no further discussion is going to be productive. It sounds rude, but to some degree you have to train the natural vagueness out of your client.
After the first, informal project discussions, I steer requirements sessions to inherently-documented forms like chat and email.
In terms of gathering requirements, try to get a really good understanding of the client's intent -- what problem are they trying to solve? Ideally, watch as they go through their process the old way, and learn what works and what doesn't.
Questions have to be short and to the point.
There's also a huge class of problems that can't be solved here (or anywhere else). SO is good for "how do I send a mail with Java", but you won't get help with the real problems that involve the larger picture.
When I meet with someone to go over requirements my goal is to really understand what they want.
The first rule I have is to not worrying about looking stupid or asking stupid questions. It is the person or group you are meeting with responsibility to convey their requirements to you in a way that you understand. Asking questions shows that you are serious about understanding what they want.
I like to use a basic cycle of:
For example,
Q: "Adam, we are needing a dynamic system that will notify our users to changes made to it".
A: "Ok - so you want a dynamic system that will notify your users to change made to it. So, what exactly do you mean by "Dynamic?"
and so on....
Don't be afraid to say "I really don't understand what you are wanting. This is what I understand so far, please help me fill in the blanks..."
In order to avoid misunderstandings and misinterpretations humour should be avoided at all cost. No matter how dry the question, do not use jokes to lighten it up. Cheerfulness factor should equal void. Or null. Or nil. Not use it. Okey? Let's repeat:
Humour = Bad.
No humour = Good.
We'll talk about smileys another time.
The upvote/downvote system encourages good questions and discourages bad questions. It's simple. Another idea would be to force new users to read an article before they post.
I don't think a FAQ link will help no matter how prominent you make it. Most people don't read that sort of thing. And anyway the people asking these questions might not know they are leaving out important context. If they were such experts they wouldn't need to ask the question in the first place.
I also don't think this is such a huge problem anyway. Questions can be edited to make them better, so who cares if they are not so great at the start?
I refer those interested in asking great questions to this nice piece by ESR. ("Courtesy never hurts and sometimes helps", "Make it easy to reply"...)
Also worthy is this tutorial on how not to ask questions. ("Be patient", "Show some effort"...)
If the question seems tricky, don't forget to set up the context. Also, go through the question by yourself first... think it through. What really is your problem? Why do you not understand it? How can you understand more about it? It is silly to ask a question if you already know the answer to it yourself.
I think all the questions on here are getting answers (for better or for worse). I see your generalized point here, but I think the answer lies in just reading the site for a while.
