How should we revisit our standard close reasons?

Question

We have some history, shown below, with our close reasons, there are some problems we have with them. And there has been a consensus to rework them for a while now.

The latest I heard about this was in 200_success' message:

It's time to revisit our standard close reasons. The last initiative failed due to a poor process. I'll think about how to kick off the new discussion.

Since this was posted 2017-11-21, two months ago, I want to know if the moderators, and our community, have thought of ways to tackle the problems with our previous process.

---

The current close reasons are:

1. 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.
2. 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.
3. 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.

---

Below is a time line of changes, and requested changes, of the close reasons. They're listed below to make looking up information easier, and so users that haven't followed this before don't have to search meta to understand what's happened, and when.

1. status-completed Revising list of closure reasons

   The close reasons were re-worded to be based on the top voted answer on this question. The close reasons also haven't changed much since. These were implemented on 2014-04-02, with a couple of tweaks to the wording on 2014-04-07.

2. status-declined Rewording close reason “Explanation of code”

   Asks to change the close reason sentence "Questions seeking an explanation of someone else's code are off-topic" to "Questions seeking an explanation of code are off-topic".

   The accepted answer says that's not what the close reason is about.

   The top voted answer says that the wording should be changed.

3. The close reasons were slightly changed, on 2014-10-16, to have better links to My question was closed as being off-topic. What are my options?

4. status-declined Should we do away with “someone else's code” wording?

   Asks the same as the above. The top voted answer also says this should be changed.

   This however was status-declined in favour of revising the standard off-topic reasons.

5. Should the “broken code” close reason be reworded?

   This says that the current 'groups' of close reasons are confusing. I however can't write a short synopsis.

6. How should we revise the standard off-topic reasons, if we can have up to five?

   This lists a lot of proposals for how to change the close reasons if you can have three to five close reasons.

   I'm unsure why we didn't change to these close reasons.

7. [chat] We can't have more than three close reasons:

   Community Managers pushed back. We would have to build a stronger case if we wanted more than three.

8. Is our “broken” wording broken?

   We came to the conclusion, that whether you agree or disagree that it's broken, using 'code not working as intended' is better than 'broken'.

9. [duplicate] Can we do away with “someone else's code” wording?

   Closed in favour of completing How should we revise the standard off-topic reasons, if we can have up to five?

10. [chat] The user that started How should we revise the standard off-topic reasons, if we can have up to five? wants to look into restarting this discussion.

    It's time to revisit our standard close reasons. The last initiative failed due to a poor process. I'll think about how to kick off the new discussion.

If you're 10k you can see when the close reasons were changed. And is how I got some of the above dates.

And so we have the result:

• Users want to replace "someone else's code" with just "code".
• We don't want to use "broken code", as it confuses new users. Instead use "code not working as intended".
• We are limited to three close reasons.
• We have a lot of possible ways to group the close reasons. We want to avoid a user posting a duplicate answer first, and no-one else getting upvotes - FGITW.

Answer 1

As I see it, some of the problems with the existing close reasons are:

• Ambiguity of "broken code". Some users seem to think that anything that compiles is not broken.
• Accusations of "not real code". Sometimes, it's hard to tell whether code is real or not. Occasionally, we misjudge, and the author feels insulted by our accusation that their real code is pseudocode. The underlying problem, really, is that their question fails to explain the context in which the code is used.
• Accusations of "someone else's code". Since "pseudocode" and "someone else's code" are lumped together in the same message, a closure is sometimes misconstrued as an accusation of plagiarism.

In summary, those misunderstandings sometimes cause posters to be frustrated or angry.

---

These three proposed reasons are largely based on the suggestions by Peilonrayz from the previous discussion.

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

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

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

Key improvements, relative to the current situation, are:

• We no longer dedicate an entire reason to "must include the code to be reviewed". It's now combined with the "someone else's code" issue. These two issues may be safely combined without confusion, I think.
• The standard for "authorship" is more clearly defined and explained.
• Instead of just banning "pseudocode, hypothetical code, and stub code", we focus on explaining what reviewers are looking for: sufficient context.
• "Broken code" is more clearly defined.

Answer 2

I mostly agree with 200_success' answer. However there is one close reason I think that should be moved - the no code reason. This is mostly for three reasons:

1. Not including the code to be reviewed doesn't mean that the user isn't the author. It just means we may violate the licence they use, but relicensing it to CC BY-SA 3.0, if we were to rewrite their code. Something our users do a lot.

2. If the poster doesn't post the code in the question, then some users may not be able to access the third party site. And so they'd be missing this context. This is common if you're behind a strict corporate firewall. And so the post "Lacks concrete context", or "Lacks reviewable code" as I put it.

3. Keeping it in the "Lacks concrete context" close reason means that closing questions is simpler. As if any and all problems with code in posts - except code not working as intended - we use this close reason. Where currently, and with the new reason by 200, we'd have to pick one of three close reasons if there is a problem with code in posts.

   This has annoyed me a couple of times before, when selecting a close reason.

And so I'd like to recommend:

1. Authorship of code: Since Code Review is a community where programmers improve their skills through peer review of working code, we require that all code be posted by an author or maintainer of the code, and that the poster understands how the code works.

2. 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. Furthermore, the code to be reviewed must be embedded directly in the question.

3. Code 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.

Answer 3

Just for context and additional information.

The current close-reasons have been used as in the following picture for the last 30 days:

Almost 300 questions have been closed, which is not quite 30% of all questions asked.

The overwhelming majority (62%) of these questions are closed as "broken code / code not yet written". After that, there's not quite 20% closed as "Pseudocode / Seeking Explanation".

After that, it's "Unclear what you're asking" with ~7%, "Missing Code" with ~6% with Custom close-reasons and migrations each having 1%.

Answer 4

This is ranging farther afield than just "reword a reason", but I'll throw it out there.

As a reviewer, I would really like to encourage (or make mandatory) automated unit tests that exercise (a portion of) the reviewed code. Think fiddle. Anything the OP does which makes it easier for the reviewer to run the code is a Good Thing.

Soooo, if the "what are my options" FAQ, the "broken code" reason, and the original posting UI mentioned automated tests, and gently nudged OP in the direction of providing tests, that could improve submission quality. Which may bring down the high rate of off-topic posts. This could be phased in one language tag at a time by adding a "-with-test" tag. The site could offer OP immediate concrete feedback about adequacy of his testing, before involving a human reviewer.