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

Question

Note: For chat-like discussions of this subject, let's use this Discuss Close Reasons chat room

Code Review currently has three standard off-topic reasons:

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 example. Questions seeking an explanation of someone else's code are also off-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.

While sites are encouraged to stick to three, we can have up to five standard reasons, if we can justify it. With that in mind, how would you modify the list?

For your reference, here is the relevant excerpt from the Help Center:

To be on-topic the answer must be "yes" to all questions:

• Is code included directly in my question? (See Make sure you include your code in your question below.)
• Am I an owner or maintainer of the code?
• Is it actual code from a project rather than pseudo-code or example code?
• Do I want the code to be good code? (i.e. not code-golfing, obfuscation, or similar)
• To the best of my knowledge, does the code work as intended?
• Do I want feedback about any or all facets of the code?

If you answered "yes" to all the above questions, your question is on-topic for Code Review.

Note that the max-length for a close reason is 400 characters (including markdown).

Answer 1

I found working on this jigsaw puzzle a personally rewarding experience. It really helped me appreciate what you do here.

Obviously the longer your site has been around, the more problems you find that need addressing. I'm sure you've tried cramming more unrelated close reasons into each slot, but that becomes unwieldy fast.

I've been developing a better way of communicating the things that a well-meaning user might think are on topic, but probably aren't. The basic idea is when you start by explaining what the site is about, it becomes way less cumbersome to explain where they went wrong. I've been experimenting with this format, and it's been an unexpected bonus that users seem to come away feeling much more satisfied knowing what the site *is* about… rather than just being told what they did wrong.

Let's see if we can make it work here:

put on hold as off-topic by rolfl ♦, Jamal ♦, 200_success ♦ 1 hour ago

This question appears to be off-topic. The users who voted to close gave this specific reason:

• Code is not ready to review — Code Review is a community-run website where programmers offer to peer review your fully working code for security issues, readability, completeness, and optimal performance. Unfortunately, questions about non-working or buggy code, incomplete stubs, or code not yet written are outside the scope of this site.

put on hold as off-topic by rolfl ♦, Jamal ♦, 200_success ♦ 1 hour ago

This question appears to be off-topic. The users who voted to close gave this specific reason:

• Tools and programming concepts are off topic — Code Review is a community-run website where programmers offer to peer review your fully working code for security issues, readability, completeness, and optimal performance. Unfortunately, questions about review tools, methodologies, how code works, adding features, and general programming concepts are outside the scope of this site.

put on hold as off-topic by rolfl ♦, Jamal ♦, 200_success ♦ 1 hour ago

This question appears to be off-topic. The users who voted to close gave this specific reason:

• Not the owner — For constructive and practical reasons, we ask that all code submitted for peer review be under the direct "ownership" and control of the author requesting the review. Unfortunately, reviewing code written by colleagues, employees, or other third parties is not within the spirit of this site.

Wow. It fits! I hope we can make this work.

This site really pushes the limits of what a Stack Exchange site can do — and you've done a superb job of it! My hope is that we can keep this site approachable and its purpose clear without having to wade through a gauntlet of meta posts and off-topic lists just to know if you are in the right place <fingers crossed>.

Good luck!

Answer 2

1. Code Review is a community where programmers peer-review your working code to address issues such as security, maintainability, and performance. Questions about code that has not yet been written, code that does not work as intended, or code that the author does not understand are off-topic, as the code is not ready for review.

   I've clarified what we mean by "broken", as some users seem to have the mistaken belief that any code that successfully compiles isn't broken. I've added "code that the author does not understand" as a variant of "broken".

2. Questions must be asked by an author or maintainer of the code and 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.

3. Questions must be about real code, not generic best practices in hypothetical situations. Pseudocode, hypothetical code, or stub code should be replaced by a concrete example, since context is essential to code reviews.

The "Do I want this code to be good code?" and "Do I want feedback on all facets?" rules are violated rarely enough that they can be closed with custom reasons instead.

Answer 3

I believe we should use 5 close reasons. This will significantly reduce the confusion people may express when they have to figure out which of multiple close reasons was actually used to close a question:

Note, finding bugs is now in 2, and fixing bugs in 3 - this makes it clear that 2 and 3 could both relate to buggy code, but it is the way the question is asked which makes the 2 or 3 close reason more appropriate.

1. Questions asking about someone else's code are off-topic because programmers are expected to know what motivated design and implementation choices when presenting code for review. If you don't know why the code is written the way it is, it is assumed that the code is not your own.

2. Questions asking to explain why code behaves the way it does are off-topic because programmers are expected to be able to explain the code to the reviewers (not the other way around).

3. Questions asking to fix or add features to code are off-topic because the code is not ready for review.

4. Questions about hypothetical code, pseudo-code, anonymized code, or anything except the actual code as used in projects are off-topic because context is essential to code reviews.

5. Questions must include the code to be reviewed. You may reference supplementary code hosted on third-party sites, but only the excerpts embedded in the question itself are in scope for the review.

Answer 4

Looking through the on-topic questions, I decided to categorize into three different categories, which can be used as close reasons.

I have not added any markdown to the close reasons as I wanted to more or less "throw this out there" first, before focusing on the exact details.

I do like Robert's idea about telling what Code Review as a site is instead of focusing on what is wrong with the question, and I have incorporated this idea in my close reason drafts.

Not something we review

On-topic questions:

• Is code included directly in my question? (See Make sure you include your code in your question below.)
• Am I an owner or maintainer of the code?

Close reason:

For constructive and practical reasons, we ask that all code submitted for peer review be under the direct "ownership" and control of the author requesting the review, and that the code is included within the question itself. Unfortunately, reviewing code that is written by a third party or located on a third party site is not within the spirit of Code Review Stack Exchange.

Purpose of reviewing code

On-topic questions:

• Do I want the code to be good code? (i.e. not code-golfing, obfuscation, or similar)
• Is it actual code from a project rather than pseudo-code or example code?

Close reason:

Code Review is a community-run website where programmers offer to peer review your fully working code to make it better with regards to security issues, readability, completeness, and performance. To accomplish that we require code to not be stripped of too much context.

(This close reason could probably be improved a bit)

Working, finished code

On-topic question:

• To the best of my knowledge, does the code work as intended?

Close reason:

Code is not ready to review — Code Review is a community-run website where programmers offer to peer review your fully working code for security issues, readability, completeness, and optimal performance. Unfortunately, questions about non-working or buggy code, or code not yet written are outside the scope of this site.

(taken from Robert's answer, with a minor change)

Not used as a close reason

There is one on-topic question that we tend to ignore when it comes to close reasons:

• Do I want feedback about any or all facets of the code?

Instead, we do post feedback about all facets of the code, no matter what is being asked.

Answer 5

I think we're mostly discussing how we should arrange the following reasons, from the close-reason meta thread:

• Code not working as intended
• Code not yet written
• Owner of code
• Pseudocode, etc.
• Explanation of code
• No code

I'm of the idea of making them easier for closers to use and to have code not working as intended on it's own. This is as it takes five people to close a single question. (Without moderator intervention.)

I like bold titles such as the ones Robert Cartaino used. They make talking about close reasons easier, I can say 'Code is not ready to review' rather than 'close reason one' for example.

I'd use the following groups:

1. Owner of code | Explanation of code
2. Pseudocode, etc. | Code not written yet | No code
3. Code not working as intended

Why?

1. Don't know and own the code, Both owner of code and explanation of code link to the same answer in our close-reason meta thread. I also don't like the idea of separating these as I don't particularly wish for us to go on witch hunts to check out if it is someone else's code. It's also more than likely that if you're asking what the code does that you don't own it, otherwise you could read it yourself and after a while understand what it's doing.

   This makes the close reason simple, does the asker say it's someone else's code or ask what it does.

2. Lacks reviewable code, all have a lack of code. None of pseudocode, stub code, hypothetical code or code not (yet) written have enough code to do a proper review. I'd also include the 'no code' close reason in this section too, it can fit quite well if we phrase it nicely, something like 'or if you forgot to include the code in the question.'

   This would make the close reason simple, if there are no code blocks or if the code blocks are not 'real' code.

3. Code not working as intended, is our largest close reason, and so having it on its own will allow us to better explain to users what is wrong with their code. Currently our broken code reason confuses new users, so this gives us the option to change the entire close reason to fully and clearly explain what is wrong.

   This will make the close reason simple as if you cannot compile or run the code, it produces incorrect results or it doesn't contain the features the asker wants then it does not work as intended. The same as before and as simple.

I know that I'm going to use a wrong word or some wrong grammar, and so I welcome any improvements to these. These are also heavily based on Robert Cartaino's, as I'm no good at writing close reasons larger that 50 characters. And so I'd word these as:

• Don't know and own the 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 owner or maintainer of the code, and that the poster understands how the code works.

• Lacks reviewable code - Code to be reviewed must be embedded directly in the question. Note that questions about pseudocode, stub code, hypothetical code, code not yet written, or generic best practices are outside the scope of this site; please post concrete code.

• Code not working as intended - Code Review is a community where programmers peer-review your working code to address issues such as security, maintainability, and performance. Unfortunately, questions that contain code that doesn't work as intended are outside the scope of this site.

Answer 6

It will be good if the off-topic close reasons are ordered such that voters could go down the list and pick the reason that is most likely to stick. (@200_success' idea)

How about something like this (some parts borrowed from other answers):

• Programming concepts are off topic — Unfortunately, questions about review tools, methodologies, how code works, adding features, and general programming concepts are outside the scope of this site.

• Not the owner — For constructive and practical reasons, we ask that all code submitted for peer review be under the direct "ownership" and control of the author requesting the review. Unfortunately, reviewing code written by colleagues, employees, or other third parties is not within the spirit of this site.

• Hypothetical or example code — Questions must involve the real code as it is in your existing project. Pseudocode, hypothetical code, or stub code should be replaced by a concrete example. After that, we will consider reopening it.

• Code is not ready to review — We offer to peer review your fully working code for good practices, readability, completeness, optimal performance, and security issues. Unfortunately, questions about non-working or buggy code, incomplete stubs, or code not yet written are outside the scope of this site. After the question has been edited to contain working code, we will consider reopening it.

• Code not included — 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. After the code to be reviewed has been included, we will consider reopening it.

A related issue is that the current off-topic close reasons don't line up well with the on-topic checklist. It will be good to adjust those too accordingly.