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.

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.

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).

Good point, but is it not tiresome to sift through the wast number of questions that are bad. And would it not be a better experience for a new SO user if he started with a good question rather than a bad one.
–
lotharApr 17 '09 at 1:45

@lothar - see my answer in the post. These comments are too short.
–
ldigasApr 17 '09 at 3:27

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.

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:

Listen to their question,

repeat their question,

express what you do not understand about the question.

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:

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?

Maybe I am biased, because I have not reached the level where I could edit someones question. And even If I can I might not be able to enhance the question because I don't have the information in the first place. I just know there are many questions with comments that say provide more info.
–
lotharApr 17 '09 at 1:49

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.