15
\$\begingroup\$

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ Can you provide specific examples of confusion or harm from the question asker's point of view? I see dissatisfaction from the close-voters' point of view, but I'm not clear on what the complaints are. \$\endgroup\$ – 200_success Nov 20 at 14:14
  • \$\begingroup\$ @200_success Confusion? Yes. Here and here. \$\endgroup\$ – Mast Nov 20 at 14:24
  • \$\begingroup\$ Those two examples don't indicate anything wrong with the wording of the close reason. \$\endgroup\$ – 200_success Nov 20 at 14:40
  • \$\begingroup\$ Can you be more specific about missing a specification? I'm not clear on what that means. \$\endgroup\$ – pacmaninbw Nov 20 at 14:44
  • 2
    \$\begingroup\$ @200_success Both ask clarification based on the close reason, indicating the reason isn't clear enough. Better examples can probably be found in comments under deleted questions, I don't have better examples on hand. I think, but I'm somewhat speculating here, that if we clear it up for whoever casts the votes, it must be clearer for OP as well. If it's unclear for whoever casts the votes and the votes are abuse, how clear can it be for OP? \$\endgroup\$ – Mast Nov 20 at 14:48
  • \$\begingroup\$ What I've noticed is that this no longer covers hypothetical code unless you are bundling that into asking about why code works the way it does? \$\endgroup\$ – pacmaninbw Nov 20 at 15:44
  • 3
    \$\begingroup\$ @pacmaninbw Sometimes it's hard to tell whether code is hypothetical or real. People get really pissed off if we accuse them of posting hypothetical code that happens to be real code with crazy variable names. \$\endgroup\$ – 200_success Nov 20 at 16:38
9
\$\begingroup\$

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.

\$\endgroup\$
  • 6
    \$\begingroup\$ Don't worry about the disagreements, I disagree with myself sometimes. \$\endgroup\$ – Mast Nov 20 at 15:41
  • 2
    \$\begingroup\$ I agree that LCC should be renamed, but I would go with CLCC - Code Lacks Concrete Context. \$\endgroup\$ – pacmaninbw Nov 20 at 15:42
  • 1
    \$\begingroup\$ @Mast It's a sign we both want what's best for the site :) pacmaninbw I think that's a great name, I couldn't come up with anything, lol. @ EveryoneElse if you think of a name you like better than LCC or CLCC please post in the comments! \$\endgroup\$ – Peilonrayz Nov 20 at 15:49
  • 1
    \$\begingroup\$ @Peilonrayz: How about "Code requires context"? "Scope not defined"? "Environment missing"? "Question is too abstract"? There are many ways to approach this naming problem. But given the history of LCC, we'll want a good name that gets the core problem across even when just used on its own. (Personally, I think we should stay away from muddy terms like "context", and look for something more concrete.) \$\endgroup\$ – hoffmale Nov 22 at 0:31
  • 1
    \$\begingroup\$ I like "Lacks Code" or "Question is too abstract/theoretical". No need to mention the words "context" or "concrete". \$\endgroup\$ – Simon Forsberg Nov 25 at 20:21
  • \$\begingroup\$ @SimonForsberg Given you've explicitly stated "concrete" do you think the first line of the close reason need to change too? \$\endgroup\$ – Peilonrayz Nov 27 at 4:36
  • \$\begingroup\$ @Peilonrayz Good question, but no, I think it's okay there - or can possibly be replaced with "real". \$\endgroup\$ – Simon Forsberg Nov 27 at 9:28
  • \$\begingroup\$ @SimonForsberg Ah good good. :) I'm not a fan of "real" - stub code, obfuscated code, and generic best practices are IMO real code. \$\endgroup\$ – Peilonrayz Nov 27 at 17:57
5
\$\begingroup\$

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.

\$\endgroup\$
  • 4
    \$\begingroup\$ What do you suggest we do? We can express distaste for the close reason till the cows come home, but if we don't have something actionable then how do we fix this? \$\endgroup\$ – Peilonrayz Nov 20 at 17:57
3
\$\begingroup\$

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ Thank you for your insight, +1, I can agree with your reasoning to (1). As for (2) I guess there's a terminology problem between CR language and non-CR language. Unfortunately, for the foreseeable future, we can't have more than 3 close reasons - and so this is why we use UCWYA. Also, IMO, code can be it's own context, if you've ever seen a really butchered LCC post then you'll why this makes sense - where everything is undefined. \$\endgroup\$ – Peilonrayz Nov 20 at 17:03
  • 6
    \$\begingroup\$ technical note: The "unclear what you're asking" close reason is fixed network-wide. As such we can't really do anything about that close reason itself. It has been noted previously that UWYA is difficult to apply on Code Review, so that part of your suggestion is unfortunately not applicable. The other one is possible. There is a limit of 5 custom close reasons, 3 of which we currently use. SE highly encourages sticking to 3 custom reasons to streamline and simplify processes for the community. \$\endgroup\$ – Vogel612 Nov 20 at 18:15
0
\$\begingroup\$

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ Two things 1) CMs say no to more than three - I think they could argue easily for a no still 2) (I've been on a 'break' and so I may not be up to speed here) but we have 6 well defined close reasons that were previously contesting each other, how do these fit into yours? \$\endgroup\$ – Peilonrayz Nov 20 at 16:01
  • \$\begingroup\$ @Peilonrayz I think Mast's response to 1) covers the issue. Replace Missing Code with No Code, leave Authorship as is, Code not working as intended covers Code not yet written. Thanks for letting me know I need to edit my answer. \$\endgroup\$ – pacmaninbw Nov 20 at 16:10
  • 7
    \$\begingroup\$ Things that can be fixed with an edit should not be a close reason - specifically the "title should indicate what the code does". \$\endgroup\$ – rolfl Nov 20 at 17:26
  • 6
    \$\begingroup\$ A bad title doesn't make the question off-topic. It hurts the quality of the question, but the question can still be reviewable and a bad title doesn't exclude a question from our scope. \$\endgroup\$ – Mast Nov 20 at 17:37
0
\$\begingroup\$

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'.
\$\endgroup\$
  • \$\begingroup\$ (3) If you wrote the code, then, with effort, you can read it again. Whilst there are times this may not be the case I think it fits quite well. (Not enough working code) We don't really need to make the broken code reason any bigger than it already is, it'll become the new LCC. \$\endgroup\$ – Peilonrayz Nov 21 at 14:32
  • 1
    \$\begingroup\$ 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. \$\endgroup\$ – Mathieu Guindon Nov 21 at 15:09
  • \$\begingroup\$ @MathieuGuindon That's fair, updating answer. \$\endgroup\$ – konijn Nov 21 at 15:14
  • \$\begingroup\$ @Peilonrayz Your comment bugged me. Having "Not enough working code" being the new LCC is a clear/net improvement, because it will make more sense to new users, and there should be less resistance because now the vocab will make sense. \$\endgroup\$ – konijn Nov 25 at 10:54
  • 1
    \$\begingroup\$ UCWYA is always there in addition to our three close reasons. Don't count it as one of the three. It will be there anyways. \$\endgroup\$ – Simon Forsberg Nov 25 at 20:14
  • \$\begingroup\$ I believe that all these things: 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 is waaaayy too much to bundle together in a single close reason. \$\endgroup\$ – Simon Forsberg Nov 25 at 20:15
  • \$\begingroup\$ @konijn I guess it's clear we disagree. Since "the vocab" is currently undefined, maybe defining it will enlighten me on how I'm wrong. Please note that each close reason has a character limit of 400 characters - including markdown. \$\endgroup\$ – Peilonrayz Nov 27 at 5:14
  • \$\begingroup\$ @Peilonrayz, re (3) I think you're overlooking a class of questions exemplified by codereview.stackexchange.com/q/231588/1402 where OP wrote the code but didn't understand the performance implications of some of the language features used. \$\endgroup\$ – Peter Taylor Nov 27 at 12:29
  • \$\begingroup\$ @PeterTaylor Yes, "there are times this may not be the case". But it still falls under the close reason, just has a slight accusation. Whilst I wasn't the creator of that reasoning, if you think it's a problem then we can take it to a new meta post. \$\endgroup\$ – Peilonrayz Nov 27 at 17:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .