Improving "demonstrate a minimal understanding" close reason [closed]

Question

Note: the eventual outcome of this discussion involved dropping this particular off-topic reason, along with other changes. See: https://meta.stackexchange.com/questions/216585/recent-changes-to-close-reasons-on-stack-overflow   —Shog

---

I was using the reason "demonstrate a minimal understanding" myself quite frequently, but the more I review, the more I have doubts about it and I think this reason can either be dropped entirely or at least rephrased, so I started to use "problems with code you've written must describe the specific problem" instead:

Questions asking for code must demonstrate a minimal understanding of the problem being solved.

So the poster has posted some description, maybe even a snippet of code and in his mind that already proves that he has that minimal understanding required. After all he described the problem and what he tried to solve. So telling him that he lacks that understanding is rather rude, and from the posters point of view doesn't even apply. What both version of the reason not emphasize is that a description of a problem is not various versions of

it doesn't work

but that we rather mean really specific details (see below). I can often see in the reopen review queue that the "improved" version just includes a more verbatim description, while what usually would be expected is some specific error message, a trace or a log, or whatever applies.

Then it continues with:

Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist

comparing it to:

problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.

Which says essentially the same, only in more detail.

So the "minimum understanding" reason is IMO a more rude version of the reason telling the user that an SSCCE is missing.

The intent of giving this reason is to tell the user that he needs to give exact details to be able to help him, so IMO a checklist would be much better. Something like:

Your question was closed because it may not provide enough details. Things you can do to improve your question to get an answer include:

1. Format the code in a way that makes it readable and easily understandable.
2. Provide the smallest working sample of code demonstrating the problem (link to SSCCE)
3. Include your input and output.
4. If applicable provide logs (i.e. Android debugging log, stack trace, etc.).
5. If applicable provide the exact error messages (compiler, etc.).

And something like this should be best included already in the banner that appears when a question is closed instead of being hidden in some pages you often enough have to actively looking for.

It might be helpful to adjust this, based on the tags or close reason, as I realize that I'm more focused on the programming area, and the above list may not apply to other areas of SO.

Update

Another thing I forgot to mention (but wanted to) is this:

Questions asking for code

Is IMO essentially an invitation of the type of questions

I have a problem, can you provide the solution? (with an optional please)

while

Questions concerning problems with code you've written

puts at least some emphasis on the fact that the poster has to put some effort himself in trying to solve the problem by providing the code which he used to attempt the solution.

Answer 1

Take 3: Closing camels, not gnats - poorly-written questions are Unclear

First off, a big thanks to everyone who pitched in here - trying to distill a broad class of (often ill-defined) problems into a clear, helpful bit of guidance is quite a challenge - I'm happy to see so many folks willing to take a crack at it.

In particular, I'd like to thank Travis for helping to push this in the direction of identifying a specific problem clearly, Gilles for the keen observation that what we're discussing here is very close to Too Broad, and jmac for an excellent write up on the notion of "minimal understanding" itself. After reading these three answers, it's pretty clear that we're converging on a close reason that is remarkably close to Too Broad! There's just one problem...

Too Broad questions aren't the problem. Clearly-written but overly-broad questions are fairly obvious: if you've been assigned the task of implementing an order-entry system from scratch and haven't ever written more than "hello world" before, you have my sympathy... But that's clearly too much for a single question. It's the ones that could be plausible if not for a complete lack of information as to how much of an answer is needed that lead to confusion and chameleons.

Unclear what you know == Unclear what you're asking

I was discussing the results here with Anna, noting in the process how this close reason could be described as "unclear if it's too broad", and she made a rather insightful observation: we're still talking about questions that are Unclear What You're Asking - we just have some fairly unhelpful guidance attached to that close reason.

So let's fix that.

As of now, the "minimal understanding" off-topic reason is gone. Instead, the top-level "Unclear what you're asking" reason links to a new, Stack Overflow-specific Help Center page that focuses on guiding readers toward including the sorts of information that make for a good Stack Overflow question. This page is moderator-editable, and in addition I've started a discussion to solicit suggestions for improvement.

Typos are off-topic - but let's do more to help folks find and fix them themselves

In addition, I've replaced the "problems with code you've written" off-topic reason with this:

This question was caused by a problem that can't be reproduced or a simple typographical error. While similar questions may be on-topic here, this one was solved in a manner unlikely to help future readers. This can often be avoided by identifying and closely inspecting the shortest program necessary to reproduce the problem before posting.

A few other sites have been using similar off-topic reasons for a while, and "typo" has constantly been one of the top write-in reasons for closure on Stack Overflow - time to make it more convenient.

Note that the help page linked to in this reason is also specific to Stack Overflow and moderator-editable; I've started a discussion soliciting suggestions for this as well. Oh - and this is linked to from the "How do I ask a good question?" page now referenced by Unclear.

Answer 2

Analogy Time

A good question-answer pair is like collaborative problem solving.

The asker has a big puzzle they are trying to solve, and are stuck on some part of it.

A good question will explain what it's trying to achieve as well as the specific problem they are currently facing so that people can help them find an appropriate solution.

Unclear what you're asking

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question.

If you don't clearly explain what you're trying to achieve overall, answerers can't figure out what an appropriate answer would be without additional information. e.g. "How should I put these 4 pieces together?"

Too broad

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.

Even if you explain what you're trying to achieve (e.g. "I want to put together a 24-piece puzzle!") if you don't explain where you're having trouble accomplishing that, answers would need to cover too many different things and end up being too long.

Primarily opinion-based

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.

Even if you clearly describe a specific problem, sometimes a question doesn't have a 'right' answer. If you ask "Which puzzle do you prefer?" then it's clear what you're asking, and you've limited the scope, but all answers will only be stating the preference of the answerer.

Off-topic

Questions seeking debugging help ("why isn't this code working?") must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself. Questions without a clear problem statement are not useful to other readers. See: How to create a Minimal, Complete, and Verifiable example.

If you ask "What's wrong with my puzzle?" nobody can answer unless you provide answerers with the ability to understand what you are expecting to get, and give them enough information to reproduce the same problem you have.

^{The above was updated based on a post for Japanese SO}

Current Issue

The current off-topic reason in question reads as follows:

Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist

Reading this as a rational human being, this sounds like we want the user to prove that if we provide the missing piece, they can figure out how to combine it with the information they already provided without handholding:

If you actually click through to the question checklist, it becomes far more confusing, since that talks about code formatting, including code, doing research, etc. Which aren't necessarily associated with having a minimal understanding.

I think what strikes me as so odd about the close reason is that it is saying that what would be a very valid question is invalid if the person asking can't understand the answer (even if future visitors with the same problem could understand it).

What I think the close reason is trying to say is that the person may be providing details or otherwise following the rules, but it's clear that they aren't even in the right ballpark and don't understand what they're actually asking well enough to have their problem solved given the current explanation. Something more like this:

The issue with the close reason is that to the person asking, they think they provided relevant information, and simply lack the knowledge to realize how far off they actually are. That close reason is not going to sit well if they think they're asking this:

The Problem with the Current Message

Let's say I'm trying to put a glove on as a sock. I ask a question:

Putting on Toesy Socks

I am trying to put on my socks to keep my feet warm, but it isn't working. I can get them on my feet, but they don't stay well, and they don't fit properly despite being large enough to fit my feet. I know they are properly sized, and I definitely don't have them inside out. How can I fit this sock Insert Image of Glove on to my feet? I am new to Toesy Socks.

This question would definitely be eligible for a great big:

Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist

But here I am, no closer to getting the glove on my foot, and wondering where the heck I went wrong. I definitely explained my problem, my attempted solution, what my expected results are, and even included a fancy picture of my sock! Why is this question getting closed? SO users are mean! Why is everyone a fascist?!

I think the fundamental issue is that this is being used to say, "You are clueless beyond anyone's ability to help you", and there is no way to explain that nicely, especially to people who can't distinguish between a glove and a sock despite being a sentient being.

Proposed Solution

I think that rather than confusing the user with nice jargon to say, "You're beneath us", we should be a bit more straight with them. Something like:

This question needs more help than we can provide. We like helping people, but sometimes the person needs to help themselves first by reading a book on the language, the online documentation, or asking someone they know who can help them. Once you understand the topic a little better, we invite you to edit this question, fix the obvious mistakes, and get it re-opened.

Yes, this isn't nice. But neither are poor quality questions from people who don't have the ability to understand that their question is low quality. At least if we're honest that this is not something that will be solved on Stack Overflow, they may be less likely to ask 20 variants of it and get a question ban.

Answer 3

I'm still digesting yesterday's conversation, so this probably sucks. But,

Questions without context are off-topic on Stack Overflow, as they require answerers to guess at how much the asker needs to know. Questions should include a clear statement of the problem being solved, as well as why it needs to be solved, what has been tried, and how that didn't work.

Key changes:

1. Focus on stating the problem and why it's a problem before suggesting solutions.

2. Emphasize that the question - not the asker - is a potential problem for answerers.

3. Emphasize what, why, how as the keys to establishing that delicious context.

Obvious weaknesses:

1. Replaces one bit of jargon with another: I've little doubt "context" would quickly become another synonym for "gratuitous displays of effort" in some camps.

2. Doesn't link to any long-form resources. This isn't strictly required, but it is nice.

3. Doesn't include any examples of what a good question looks like. Keeps it relatively brief, but concerning given weakness #2.

I'll think about this more over night.

Answer 4

What questions are we targeting?

This close reason was introduced to

handle the sorts of "here's my spec, please write code for me" questions that were already being closed

Let's see what kinds of questions this covers. First, this is only applicable to questions of the form “how to I accomplish this task?”, not questions of the form “debug this piece of code” (these are the two main kinds of questions on Stack Overflow). The task has to be a programming task, otherwise off-topic (in the vernacular sense of “not about the site's topic”) applies.

What kind of programming tasks are not appropriate for a questions and answers site about programming? I can see two reasons (beyond of course unclear if the task is insufficiently specified).

• The task may be too big — it's not something that people would be expected to write in a few minutes, but on a 6-to-8-week-contract. There is already a close reason for that: too broad.
  Do we need a more precise close reason for givemetehcodez questions? I don't see a pressing need. It's true that too broad covers both the case where there can be too many answers (such as resource requests) and the case where answers would be too large (such as givemetehcodez), but I don't see much potential for confusion. However, it is true that the guidance for too broad is fairly generic and could perhaps be improved.

• The task may be so unique that it is unlikely to be helpful to future visitors. This happens mostly with the kind of homework-type question that sets a purely artificial task that is adapted to a particular progression in a curriculum. But even homework questions can be useful to future visitors — especially when the exercise is from a textbook. Indeed such questions are more useful than “debug this piece of code”, which we do allow (and even encourage by saying right off the bat that “the best Stack Overflow questions have a bit of source code in them”).

So how is this “minimal understanding” thing relevant?

In a previous discussion, I mentioned how “demonstrate a minimal understanding” is useful for cases where the asker is out of his depth. The thing is — just how common is this on Stack Overflow, in a way that the question isn't asking for an unreasonably scoped task?

Not all questions call for complete code. Instead of answering with code, we can answer with a general strategy, a roadmap of what libraries to use and how to assemble them. Even if the way a question is phrased demonstrates that the asker will not be able to accomplish the task, in a way, that's his problem. A good guideline for writing good answers on Stack Exchange is: how many future visitors will find this answer useful? Maybe the next person to come along will have the required understanding. Write for that person.

A note on some other sites

Security and Cryptography have close reasons corresponding to this “minimal understanding” issue that I find appropriate, respectively:

• Questions asking us to break the security of a specific system for you are off-topic unless they demonstrate an understanding of the concepts involved and clearly identify a specific problem.
• Requests for analyzing or deciphering a block of data are off-topic here, as the results are rarely useful to anyone else.

In both cases, these address a very specific kind of questions which is relatively common (like “how do I hack www.example.com” or “how do I decipher OIAIJDNXYFIKLWQJSDIUQPZUA”), and it's helpful to have a pre-worded close reason. These close reasons are subsets of unclear (rather than too broad), though different from many unclear questions in that usually the asker would be incapable of adding more details. I don't see a similar pattern on Stack Overflow. Those unreasonably-scoped questions are all over the map in terms of the site's scope — asking to write programs from scratch, asking to add features to an existing program, asking what technologies to combine to achieve a goal. We aren't going to find a unifying factor.

Regarding some proposals on this thread

Accomplishing the goal of this question is beyond the scope of a single answer. Questions should clearly explain a specific misunderstanding in its simplest form, how it was reached, and what was attempted to work through it. (by Travis J)

I like the first sentence, but it's only a slightly specialized variant of too broad. The part about “clearly explain a specific misunderstanding” is an oxymoron; you can't expect the asker to say anything other than “if I could explain it clearly I wouldn't be able to understand the question”. As for the what-did-you-try part… for a plzsendtehcodez question, “what did you try” doesn't always improve the question, it often leads down the garden path.

Conclusion

I think this close reason should be changed to

too broad
Good answers would be too long for this format. Please add details to isolate an issue that can be answered in a few paragraphs.

Given how close it is to the existing too broad close reason, I propose to keep using too broad as it is.

More specific guidance — more specific than what we have now — can always be given in a comment.

Postlude

I'm not totally happy with my conclusion, because I do find that there is a very common type of guidance (or at least encouragement) that can be given to a “solve this for me” question: “what did you try?” However this needs to be wielded carefully. First, “what did you try?” needs to be worded in a helpful way (definitely not “what did you try?”!), which in itself is a reason to have it in a prepackaged form. Second, it is not appropriate for all plzsendtehcodez questions. Third, what it's really calling for is breaking the too-broad question into manageable subquestions — starting with one subquestion. The subquestions can either be about general strategy or a specific coding problem, and we should not push the latter but forget the former.

Travis J's proposal, once cleared of that irrelevant bit about understanding, does have a point, and I do like the first sentence. Here's some draft wording — but I wouldn't want this wording to go into production, I need to think about it some more.

Accomplishing the goal of this question is beyond the scope of a single answer. If you are looking for guidance regarding algorithms or libraries, state precisely what environment you're working in, your goal is, and what part of the design you need guidance on. If you need help with the coding, show us what you have done so far, what you want to do next and what is blocking you.

Answer 5

Take #2: riffing on Travis

It is not clear that a reasonably-scoped answer can satisfy this question. Questions should clearly explain a specific misunderstanding in its simplest form, how it was reached, and what (if anything) was attempted to work through it. For help writing a good question, see the question checklist.

I liked Travis J's problem statement, but I felt it was incomplete: the real problem here is that we don't necessarily know if the question is too broad or simply unclear. Calling out both makes the problem a bit more obvious, I think.

Also, I'm expanding the scope of this discussion a little bit to include the other weird OT reason on SO: the one for help debugging code you've written. In practice, there's been entirely too much overlap between that one and this one, and it's time to separate them:

This question was prompted by a problem that is unrelated to the actual question asked. While similar questions may be on-topic here, this one was solved by the asker in a manner unlikely to be relevant to others. This confusion can often be avoided by identifying and closely inspecting the shortest program necessary to reproduce the problem before posting.

Obviously, this is a pretty major change, but I think these two reasons together should suffice to cover two broad categories of problematic questions:

• Those lacking a clear and specific problem statement
• Those relating to typos and similar silly mistakes

If anyone has any concerns with this change, raise 'em now.

Answer 6

Modifying Shog's new one to de-emphasize the "show attempts" even further in favor of "show what you know".

It is not clear that a reasonably-scoped answer can satisfy this question. Questions should clearly explain a specific misunderstanding in its simplest form, and the parts of the problem that are understood (which may involve showing attempted solutions). For help writing a good question, see the question checklist.

The two key points here, as Gilles has explained, are a) "where are you starting from?", so that answers aren't wild guesses or thousand-word theses, and b) "are you going to understand a reasonable answer?", so that answers don't turn into hand-holding tutoring sessions that only apply to the asker.

Answer 7

I like that @Shog9 is willing to visit this topic. I like his suggestion and am just putting forward some food for thought.

This close reason tends to be for help vampires. Specifically, the kind who asks too much of answers. Users cannot be expected to write a book explaining the background and history, a library to support whatever is being created, and a framework to do the creating all in one answer.

The thing is, there are users capable of all that, but it is unfair for them to labor for hours on end just to deliver it to someone who could have done it themselves with effort and time.

I like shog's suggestion because of its aims. It aims at making askers be clear through explaining the why, what, and how of their question. Perhaps the message to accomplish those goals can be a little more clear.

Accomplishing the goal of this question is beyond the scope of a single answer. Questions should clearly explain a specific misunderstanding in its simplest form, how it was reached, and what was attempted to work through it.

Advantages:

• Attempts to reduce the size of something new an answer must create. For example, "how do I create a div in jQuery" vs "how do I create a mobile app like facebook on Android"
• Asks for an explanation of the misunderstanding the OP is facing while not asking for the entirety of what led to it
• Asks for a simple backstory and for a sample attempt

Disadvantages:

• References the "scope of a single answer" which is hard to determine
• Uses the word misunderstanding which may not always be the best fit
• Does not address code directly

Answer 8

I feel that the new reason of

This question was caused by a problem that can't be reproduced or a simple typographical error. While similar questions may be on-topic here, this one was solved in a manner unlikely to help future readers. This can often be avoided by identifying and closely inspecting the shortest program necessary to reproduce the problem before posting.

... is rather usefull to target the "debug me" kind of questions. However, I think that the "minimal understanding" should not have been removed though as there are also enough questions where this really applies and would warrant a more specific close reason. In such cases the other close reasons don't feel appropriate.

Examples like this would be

What's this =! operator? or Function to save data as struct on C

For these kind of questions I'm using now

This questions shows a serious lack of understanding the technology involved and is therefore beyond the scope of SO. Please refer to an appropriate beginners tutorial or other relevant documentation first.

which is basically a variation of the "minimal understanding". Questions of this type really show that the user needs to read up a manual first and learn the basics of his language and this should be what we need to tell him.

Answer 9

The standard used on certain other SE sites (e.g. languages) is, "Demonstrate that you have tried to solve the problem yourself."

1. Show your proposed solution (identify methodology and provide some relevant code).
2. Relate your expected results.
3. Relate your actual results.
4. Discuss how 2 and 3 differ: E.g. "I was expected solutions of a type X, and got error message(s) Y instead."

Then someone can probably answer, "If you use methodology B instead of A, you will probably get your desired results." Or, You made a mistake with code in line Z; here is the correct code."

Answer 10

I mostly like the existing reason, but have seen enough questions wrongly closed under it that I feel like it could stand clarification/re-emphasis.

First, the existing reason:

Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist

Here's how I would word it:

Questions that ask for the complete code to the solution must demonstrate a minimal understanding of the problem to be solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist

This emphasizes that asking for “teh codez” is a significant part of why the question was closed.

• To the questioner, it implies that if you're willing to write the code yourself, and to amend the question to make that clear/not ask for “teh codez”, then your question can be reopened on that basis.
• To would-be closers, it makes clear that this reason is for questions that ask for code.

Answer 11

Shog9 has proposed (and implemented) the following close reason:

This question was caused by a problem that can't be reproduced or a simple typographical error. While similar questions may be on-topic here, this one was solved in a manner unlikely to help future readers. This can often be avoided by identifying and closely inspecting the shortest program necessary to reproduce the problem before posting.

I have some reservations about the wording, however I also feel it now fails to highlight a particular and very common issue - failing to describe a code error in sufficient detail.

Should we consider a companion close reason that focuses just on this topic? "Unclear what you're asking" might cover it anyway, but that's a broad, broad topic. I'm suggesting something like:

Questions about runtime or compilation errors must fully describe the error in a manner appropriate to the language in question. Please include the complete error message (including stack trace, for languages that provide one) and indicate which line of your code example triggered the problem.

Answer 12

I'll cut right down the middle and put it like this:

Questions asking for code must demonstrate minimal effort has been made to resolve the problem. Include attempted solutions, why they didn't work, and the expected results.

The main questions to weed out are the ones that finish with a variation of "gib me teh codez plz!!" And that wording might help both reviewers and askers.

It can genuinely happen that the reason for posting is a lack of understanding. In fact, at some point, that's why anybody posts, no? "I don't understand how this feature works, please explain it to me." However, behind that question, there can be an effort put in, which for various reasons has not yielded a satisfactory understanding. Or there was no research. Lack of effort to find a solution (meaning that there's probably a ton of duplicates or similar questions, or that documentation is amply available on Google) clutters our knowledge base with low quality questions.