Still confused about minimal understanding

Question

I'm still a little confused about the "minimal understanding" close reason and when it should be used. I'm afraid I might be defaulting to it a little too often. Shog recently posted the following:

During all of the recent discussions surrounding the close queue backlog, something's been bothering me... A pretty big chunk of the backlog is taken up by questions flagged or voted on using this "minimal understanding" reason. That's not surprising in the least - but it's a horribly inefficient way of dealing with these questions. It takes 5 voters to close a question, and because some amount of subject knowledge is required to properly evaluate them finding the right voters is extra-difficult. Meanwhile, folks who interpret the reason as "no effort shown" are pushing more and more questions into the queue every day...

...If they just down-voted the questions, a privilege available to nearly everyone flagging them, they'd drop out of sight a lot faster.

In response, I've started using more downvotes and using less close votes, but I'm still not certain I understand the close votes we have, or how they were intended to be used. I recently downvoted and voted to close this question:

https://stackoverflow.com/questions/20637685/adding-dropdown-list-column-to-templatefield-and-adding-it-to-gridview-through-c

I felt that the downvote was appropriate because the question didn't show any research effort (as per the tooltip). At the time, I felt the close vote was also appropriate because I felt that the OP should have included attempted solutions, etc.

Now I'm wondering if I should have used "problems with code you've written" because, based on the wording of the question, it would seem that the OP may have already written some code and thus does have a minimal understanding of the problem. The OP merely needed to include that code in the question. (The hazy distinction between these two close reasons was recently covered by Devolus, though I didn't find the answers very helpful.)

Then there's this question:

Passing < or > with modifiers to SendKeys

I chose to downvote it because I felt that the user could have easily found the documentation with a simple google search. But for this question I second-guessed closing it. The OP is asking about a specific problem and, while showing his/her code might have been helpful, in the end it wasn't necessary for answering the question. So I answered it with a link to the documentation and quoted the relevant section. I also added a bit of advice that I half-remembered from years ago.

This question, however, was closed as not showing "minimal understanding". (I'll also note that, for a while after it was closed, mine was the only downvote.) I think I disagree with that, because the OP clearly does have a minimal understanding... s/he knows the correct function to call, but is confused about the formatting of the string parameter. There was also clearly an attempt to write some code based on the OP's statement at the end: "">" and "<" are not listed in the Microsoft keys list."

So, while I don't think it was a good question and I downvoted it, I'm not sure if it's a bad question which deserves being closed.

Can someone help me understand how these close reasons should be used, or if they should be used, for the questions above.

Answer 1

What is the purpose of Stack Overflow?

“Collectively increasing the sum total of good programming knowledge in the world”.

How do we do that?

By doing our best to help people find good answers to their programming questions.

How do people find answers?

Either they find an existing question that addresses their problem, or they ask a question to solicit new answers.

Why do we close questions?

Some questions do not help us, because they do not lead to useful answers. We close them so as not to waste our time attempting to answer. Examples of reasons to close questions include duplicate question (we've answered already, so we don't need to waste our time answering again), unclear questions (if nobody understands what is asked then nobody will think of looking there for an answer), questions that are too broad or off-topic (so we have a poor chance of producing a good answer), etc.

Why do we require that “questions asking for code must demonstrate a minimal understanding of the problem being solved”?

If you ask for us to write a code snippet, fine. But will you know how to use it? If you can't understand the answers, then the answers won't benefit you, or at least not in a way we care about — it might get your boss happy that you've written something (but unhappy 6 months down the line when your code turns out to fail and you're unable to fix it or explain how it works), but it won't make you or anyone else a more competent programmer.

Furthermore, if you can't understand the answers, it's unlikely that you've asked a good question, thus it's unlikely that answers would benefit future visitors either. This is mostly a specialized variant of “too broad”: if a proper answer requires a semester-long programming course to bring you up to speed, it's not something we can provide.

So what's this “minimal understanding” thing in a nutshell?

Don't ask if you aren't capable of understanding the answers.

How can I demonstrate “minimal understanding”?

Show your prior research — this helps us know what we don't need to explain again, where we should start, and in what direction we should go. Follow up the obvious avenues first: check your reference manual, look up concepts on Wikipedia, etc. Try to write the code, and show us how far you've gone and where you got stuck. That way, we can provide the next step, the one that makes you go over the hurdle that was blocking you. In a nutshell: tell us where you are and where you want to go next.

• Bad: "Where's Eldorado?"
• Good: "I'm on 42nd Street in Springfield, KM headed North, where do I turn for Luton?"

What does this have to do with effort?

Nothing.

Oh, come on, do you really want Stack Overflow flooded with effortless questions?

A lot of effortless questions fall under the remit of a close reason: unclear, too broad, etc. But closing says “we can't answer this”. If a question is answerable, it should not be closed: it can help other people.

So what should I do about effortless questions then?

Downvote it. This is independent of voting to close. If a question…

• shows effort or is interesting, and is answerable: upvote it.
• shows no effort, and is answerable: downvote it.
• falls in between: move on.
• shows some effort but is misguided and not answerable: vote to close it.
• shows no effort, and is not answerable: downvote it and vote to close it.

---

https://stackoverflow.com/questions/20637685/adding-dropdown-list-column-to-templatefield-and-adding-it-to-gridview-through-c

I find this question unclear. The asker wants to add a feature to an existing application. He needs to provide some information about the existing application. This could take the form of a code stub, or at the very least an interface and a specification (I want a function with this and that parameter that does this and that thing when called in such and such context).

I don't think lack of minimal understanding is an issue here, but lack of details in the question is. This makes the question too broad and unclear.

Passing < or > with modifiers to SendKeys

I don't see any lack of understanding. The asker has specified (in words and tags) his working environment (.NET under Windows), his programming language (C#), the API he's working with (WinForms, specifically SendKeys), the task he's working on (sending a key event to another application), and the problem he's stumbling on: sending a specific key which is not straightforward to encode.

I see no reason to close this question. It is likely to help future visitors who have the same problem: in C# in .NET with WinForms, sending a key event concerning punctuation characters with modifiers.

Given that the answer is easy to find in the official documentation, you have a good case for downvoting it as lacking effort.