The context of "Lacks concrete context": let's fix it

Question

Early 2018 we changed the close reasons on Code Review. This was necessary, but now almost 2 years later it's perfectly clear there's a growing discontent with one of them: "Lacks concrete context".

In this post, I'll provide a bit of ehm, context about:

• History on the problem
• Signs there is a problem
• The core of the problem
• Reasons we can't simply throw the problem overboard
• Suggestions

It's going to be a long post with a lot of links, but we've been dancing around this problem long enough now so I want to be thorough.

Feel free to post alternate solutions and/or alternate phrasings of the close reason in the answers. The goal of this question is to come up with a fix that:

• helps moderating users (anyone voting and in the queues) by picking the correct course of action based on our scope
• helps new and existing users with fixing their question should it get closed
• reduces the growing resistance to our close reasons

All explicitly by improving (the usage of) this particular close reason. One way or another.

History

This all started in January '18. Peilonrayz correctly remarked the old reasons weren't working out. We went from this list:

• Questions containing broken code or asking for advice about code not yet written are off-topic, as the code is not ready for review. After the question has been edited to contain working code, we will consider reopening it.
• Questions must involve real code that you own or maintain. Pseudocode, hypothetical code, or stub code should be replaced by a concrete implementation. Questions seeking an explanation of someone else's code are also of-topic.
• Questions must include the code to be reviewed. Links to code hosted on third-party sites are permissible, but the most relevant excerpts must be embedded in the question itself.

To:

• Authorship of code: Since Code Review is a community where programmers improve their skills through peer review, we require that the code be posted by an author or maintainer of the code, that the code be embedded directly, and that the poster know why the code is written the way it is.
• Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site.
• Code not implemented or not working as intended: Code Review is a community where programmers peer-review your working code to address issues such as security, maintainability, performance, and scalability. We require that the code be working correctly, to the best of the author's knowledge, before proceeding with a review.

For those with 10k+ rep, find the full history here.

200_success explained how and why, and it worked fairly well. Except this point didn't work out:

• Instead of just banning "pseudocode, hypothetical code, and stub code", we focus on explaining what reviewers are looking for: sufficient context.

Problem? I thought we just fixed it?

It was more than a good step in the right direction, absolutely. But, while the idea behind the close reason would appear to be clear, it's a common source of confusion ^{[1][2][3][4][5][6][7][8][9][10]}. And there have been attempts at fixing it, but we're almost 2 years in now and so far no joy. I've picked the wrong reason myself often enough, and sometimes so many reasons apply it arguably doesn't matter much at all (such questions are usually unsalvageable).

But it's too much up for opinions at the moment and we need something clearer. Not just for us, but for the next round of people arriving, sticking around and taking up moderating responsibilities.

Please post suggestions which are clearer than the current reason.

So people don't like the close reason, what's the problem with it?

Core of the problem is that the close reason is both misunderstood and misapplied. The latter is in part a logical consequence of the former.

Where LCC was supposed to be used when the code was missing code-context (or at least enough description as substitute, if need be), it's used for a lot of things.

Can we discard it?

Absolutely not. Often enough when an attempt is made to review a question with code that leaves us guessing at the intentions of the poster, it turns out the answer is useless. It's a problem we share with hypothetical code.

Or, as Dan put it years ago:

Put it this way: Imagine you post a section of code and we give you a review and a potential change to the code.
Someone spends an hour basing his reply on this change.
You then say "I can't do that, because the foo can't be barred. That bits not in my question, but its part of the same part of code"
You've now wasted another person's hour because you didn't include the entire context in your original post.
I appreciate that may or may not be the case in your example, but its (one of) the reasons we dont' accept example or partial code here.

Emphasis mine. (source)

Not having enough context means we can't review it or a review would be a waste of everyone's (including whoever asked the question) time. Effectively questions like that hold no value (yet). They can often enough be fixed, but to fix a question we need to enlighten the poster what's wrong with the question. Part of that is leaving comments (which we don't do enough), but it starts with using the right reason to close a question.

Now what?

We can't accept the current unclear situation as the new normal.

2 things:

• clarify
• use the proper reason

We need to clarify the close reason so it isn't abused as easily, and finally, we need to stop abusing it. It's basically that simple.

Is a question:

• overall unclear?
• missing a specification (what is the code supposed to accomplish)?
• missing a description?

Unclear what you're asking.

• missing complete portions of a function?
• missing functions or libraries that have to be included for a meaningful review?

Lacks concrete context.

• missing all code, is all code behind a link or are essential parts behind a link?
• asking about why code works the way it does?

Authorship of code.

Keep in mind, there's the 'Other' reason to vote to close if we can't (or shouldn't) help the poster for a less clear-cut reason. If you think this clarifies things, use it. It may ruin the closure stats a bit, but I'd prefer a clean, efficient site over clean stats.

Also keep in mind that code doesn't have to be posted completely per our current scope. If the posted bits are enough to review it, review it. Do you prefer more-than-average context? Fine, so do I. Pick a different question to answer. We got plenty.

Answer 1

IMO the biggest and simplest problem is LCC being used as UCWYA. But why is this happening?

1. I don't know, but I can guess.

   The reason's name "Lacks Concrete Context" makes it sound like any context. Whilst the description of the close reason states explicitly code 5 times, I think most people remember the name. And the name doesn't specify code.

   We don't want to read the close reason time and time again, and so the name should be the entire story. But the name is unfortunately not the entire story.

2. Context doesn't mean what we think it does.

   In short the close reason is stating there's not enough context. And so it's easy to think that is also including non-code aspects.

3. The closing norms of the site.

   The more something is closed incorrectly the more correct it feels. This makes me feel that it's going to be an uphill battle against the entire sites' close voters unconscious biases.

---

I think changing the name should help.

• Changing it from "Lacks Concrete Context" to "Lacks Code Context" means the entire stories is in the name.
• Changing the name to not be LCC. Breaking the cognitive ties that LCC is "Lacks Concrete Context" will be hard, and so a new acronym may help kickstart the change.
• If we stick with LCC - "Lacks Code Context" - then we as a site should write it out to help break down the old cognitive links into the new ones.
  For a while after changing the name people will still think "LCC that's Lacks Concrete Context".
• I feel removing the word context from the close reason would help lessen the idea that it's about not code aspects of the question.

• I don't know how to change the closing norms of the site. I'm unsure if even telling people they're doing it wrong even helps.

  Maybe stating in the comments if you see an LCC vote on an UCWYA post, to post a short recognizable comment to help push the next close voters in the right direction.

---

I suggest the following change:

Insufficient code - Code Review requires concrete code from a project, with enough code for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site.

Original:

Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site.

---

LCC has always been a bit on the not well-defined side. I have had meta disagreements with Mast over this, way back. I think it's a pretty big problem, but I think fixing UCWYA as LCC should come first.

Answer 2

I have never liked this as a close reason. I believe it does damage to the site. Community consensus at the time was significant, and I've come to accept it over time as a potentially necessary evil.

There ARE good reasons for LCC, and I have seen a number of instances where I have agreed with using it as a close reason, but it is being applied incorrectly too often.

The most "destructive" use of LCC is to indicate that a question is off-topic because you don't understand the question. Code review is intended to be a place where people bring code to be reviewed by others who are typically more experienced or versed in some aspect that the OP is not. As members of this site we cannot know every situation and every language, and every problem domain... so there will always be times when we don't understand the context of a question. It may be as basic as "I don't know python, this is a Python question".

Too often I see LCC used as a close reason when the reviewer lacks the context, and not the question. Just because you know a language, and you don't have the context needed to review the question, it does not mean that there is not another reviewer who does have the context.

Note, it's important to differentiate between down-voting and close-voting. Too often I feel people use LCC in order to express what should rather be done with a down-vote instead.

Consider this recent example.

It was closed as LCC, but, it has tons of context. Just not the context that some people want.

On the other hand, I don't doubt that there are members here who would easily be able to see some significant issues in that code, and provide meaningful reviews for it.

So, by voting to close a question you don't understand, even though it has enough context for another user to review, just robs value from the site as a whole. It takes away a good experience from a question asker, and removes the opportunity to review from a motivated reviewer.

Answer 3

Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site.

I don't think the intent behind it matters. The text above is what everyone sees and works with. To me, this seems to be two separate reasons:

1. Lacks context: code to be reviewed must be given sufficient context to understand what it does, how it works, and how it is used.

   Note: This missing context may be code, description or something else. (i.e. Users lack information to be able to review the code. The code to be reviewed may or may not be complete).

2. Too abstract: Code Review requires concrete code from a project. Pseudocode, stub code, hypothetical code, obfuscated code, and questions about generic best-practices are outside the scope of this site.

   Note: This doesn't talk about "context" at all, but deficiencies in the code. The code itself is unsuitable for review.

(It seems that the second reason is what's intended, but I've usually used it for the first one).

---

I'm not sure "unclear what you're asking" makes much sense on code review. While people might ask specific questions, answers are expected to be open ended reviews that may or may not address them.

Personally I'd be inclined to remove the "unclear" reason entirely and split "lacks concrete context" into its two parts.

---

Of course, it's quite possible that questions have more than one thing wrong. So the close reason kind of doesn't matter. There should always be a comment applying the reason to the question. (i.e. not just a copy-paste of a close reason, but "[this specific thing] is missing", "how does [this] work?", "please add a usage example", "please explain what [this] does").

---

Note also the definition of the word "context":

the circumstances that form the setting for an event, statement, or idea, and in terms of which it can be fully understood.

If we say "the code to be reviewed lacks context" it means that the other stuff (information, intent, other code) is missing. You can't use "lacks context" to mean "the code to be reviewed is itself deficient" because something is not its own context.

Answer 4

First I mostly agree with the answer @Peilonrayz although I think the name should be Code Lacks Concrete Context.

Unfortunately I think there should be more options under Off-topic:

• No Code - for questions that have no code.
• Missing Specification - for questions that don't clearly define the task
• Missing Description - for questions that don't describe what the code is doing
• Title Should Indicate What the Code Does
• Hypothetical - Pseudocode and questions that have no concrete code, possibly includes code with variables that seem too generic.

The above suggested close reasons should not affect the other VTC options. In reference to 6 well defined close reasons Explanations of Code obviously indicates the person asking is not the author (Authorship), Code Not Working as Intended kind of covers Code not written yet.

This would make it clearer to both the question posters and those moderating the questions in the queues. Bundling reasons together can cloud what the close reason is for both poster and closers.

Answer 5

Focusing on this part:

Is a question:

• overall unclear?
• missing a specification (what is the code supposed to accomplish)?
• missing a description?

Unclear what you're asking

• missing complete portions of a function?
• missing functions or libraries that have to be included for a meaningful review?

Lacks concrete context.

• missing all code, is all code behind a link or are essential parts behind a link?
• asking about why code works the way it does?

Authorship of code.

My thoughts;

(1) For me, on Code Review, anything but the code is context because of how the dictionary defines context. I truly believe that most new users feel the same way about what context is on a code review site.

Following that, missing functions or libraries should not be LCC(Lacks Concrete Context).

Following that even further, missing a specification or description should be LCC.

(2) Unclear what you are asking should only be relevant when the question is overall unclear because of (1).

(3) Authorship of code means to me "You did not write that code", It is confusing to use this for questions about why code works the way it does.

So if per Vogel612 we are encouraged to have only 3 reasons and one of those has to be UCWYA, I would propose

Unclear what you're asking

• Overal unclear

Not enough context

• Missing a specification
• Missing a description

Not enough working code

• Missing complete portions of a function
• Missing functions or libraries
• Pseudo code
• Stub code
• Hypothetical code
• Code that is known not to work
• Code is not in the question, but in a link

Other (which is always possible)

• User posted someone else's code

Some things are missing on purpose;

• If the title is bad, fix it with an edit. If you cant figure out a title, then downvote (or not) and move on, or comment about the post title, and let someone else come up with a title. A bad title does not make a question off-topic.
• If there is no question, assume the user wants a code review. Don't close with UCWYA. I've gone as far as editing the question and adding 'Please review this code'.