146

About reviewing

The review queues contain posts that possibly need further action from the community, like improvement, closure or deletion. By presenting those posts for peer-review, the system aims for higher quality content.

Some user actions, such as suggesting an edit, casting a flag, close vote or reopen vote, or posting for the first time, can trigger the inclusion of a post on a review queue. There are also posts included on the queues algorithmically, such as the contents of Late Answers and Low Quality Posts.

General guidelines

  • Always read the full post you are reviewing.
  • Don't rush. Take the necessary time to read the post carefully.
  • If you don't care about a post, just click Skip or Not sure.
  • When you need more context, open the post link to see the question and all answers.
  • Most posts can be improved. Use the Edit option, and edit thoroughly.
  • If you're unsure how to review a post (perhaps it's outside your areas of expertise), skip it. Someone who understands it better will review it later.

Guidelines for specific review queues

Return to FAQ index

71
+500

Guidelines for reviewing Suggested Edits

Basic workflow

  1. Review the differences between the original post and the suggested edit, and the edit summary above the differences. You could feel more at ease if you use filters.
  2. Check if there is any reason to approve the edit as is. If you find any, Approve.
  3. Verify if the suggested edit is complete. If there is anything else to edit, Improve Edit.
  4. If there's clear evidence that the edit makes the post worse or that it doesn't solve critical issues click either Reject or Reject and edit.
  5. Otherwise, Skip.

Common reasons to Approve

  • Edits that attempt to add clarification to an answer, like “this doesn’t work in Windows 8”, or addendums to the post should be approved.
  • Edits that fix grammatical mistakes or make the post easier to understand by others.
  • Edits that include additional information only found in comments.
  • Edits that include updates as the post ages, or correct minor mistakes.
  • Edits that add relevant resources or links.

Common reasons to Reject

  • Edits that introduce formatting (code, bold or italic) where such additions don’t make sense or don’t make any difference. Reject as no improvement whatsoever or causes harm, depending on the case.
  • Edits that change an answer's explanation or code to a completely different alternative. If the proposed edit is an improvement of the current answer, you need to be able to ascertain so, by going to the question and verifying that the answer still has the same intended effect as before.
  • Edits that modify code or correct code typos in a question, unless it clearly doesn't invalidate the question, should be rejected as clearly conflicts with author’s intent.
  • Edits that plagiarize content from an external source without proper attribution. Reject as causes harm and write an explanation. (Always check for plagiarism from common sites such as Wikipedia when a tag wiki/excerpt is created!). For tag wikis and excerpts, there's a special reason copied content, so you can just go ahead and use it.
  • Edits that add content that doesn’t belong (e.g., “thanks in advance”, “please help me”, “SOLVED” in the title). Reject as no improvement whatsoever.
  • Edits that add irrelevant tags.
  • Edits that change URLs to link to unrelated content should be rejected as spam or vandalism. The review page will automatically display the Markdown source whenever a link is changed.

Explicitly check URL changes: This is an easy way to sneak spam in, so do not assume a link update is correct without verifying. If any link is changed, the system will automatically show the Markdown view by default. Note, however, to check to ensure that the formatting is correct by viewing the rendered output.

Check the edit summary before rejecting: Occasionally a poster has provided information in a comment or other answer that cannot be seen on the edit review screen, and the editor is bringing that content into the post. This should be mentioned in the edit summary. You can click the question link (it’s probably best to open it in a new tab) to see the full context.

It helps if you know what the post is about: Sometimes an edit fixes a minor mistakes that was obviously hand-typed by the answerer (typos in questions should only be fixed if that doesn't invalidate the question). It’s a challenge to know the difference between a typo-fix and an actual change if you don’t know about the topic or context of the post. For example, in Perl, a single character can change the entire meaning of a line. In C++, changing == to = can also have a dramatic impact. You don’t always need to understand the content of an edit to review it, since suggested edits could be about changing the format without changing the meaning, but if you are not sure, skip the edit and leave it for someone who knows.

For specifics about reviewing tag wiki edits, see this answer to How do I review tag wiki edits for new tags?.

Be aware that if the post is community-wiki, the author waives authorship and changing the meaning isn't as important as improving the post.

  • 1
    Motion to add a separate answer for tag wiki edits (or queue entirely honestly??) They're really distinct and both should be covered in this thread alone. – djechlin May 17 '13 at 16:54
  • 1
    I personally think it's a little more organized to separate them. I think more value is added from clear titles than a 1-1 correspondence between review queue / answer here, in particular because I think it really, really should jump out to perusers of this thread that we have comprehensive guidelines on reviewing tag wiki edits. But yes at minimum we need to complete integrating that into this answer. – djechlin May 17 '13 at 17:21
  • 1
    @djechlin Create a separate Answer for reviewing tag wiki edits, and add a note at the top of this answer explaining that there are two types of Edits for review (normal posts and tag wikis), and link to the tag wiki answer. – Rachel May 20 '13 at 19:01
  • Why does the guideline recommend rejection of: "Edits that attempt to add clarification to an answer, like “this doesn’t work in Windows 8”," ? IMO opinion that stops us from 'future proofing' old answers: those that were written for Linux or Windows 7 for example. – Qsigma Feb 23 '15 at 9:48
  • @Qsigma That would be considered altering the original answer too much. The preferred solution for this is to comment on the answer, and let the author update it (unless it's a Community Wiki). If the author doesn't update himself, then I believe it would be okay to edit. – bfavaretto Feb 23 '15 at 17:29
  • Wait, "Edits that attempt to add clarification to an answer, like “this doesn’t work in Windows 8”, or addendums to the post should be approved." - these I reject as attempts to reply. Unless the edit summary makes it clear they are bringing in info from comments, this kind of edit is not an Accept in my opinion. – Kate Gregory Feb 19 '17 at 19:56
  • @KateGregory the help center explicitly states those edits as common reasons of why to edit a post "When should I edit posts? [...] Some common reasons for edits are: [...] to correct minor mistakes or add addendums / updates as the post ages" Through, maybe the example should be "This only works with Windows 8" instead. – Braiam Feb 19 '17 at 22:23
35

Guidelines for reviewing low-quality posts

Posts appear in the low-quality-post queue both automatically by the system's quality heuristics and by "very low quality" or "not an answer" flags from users. On most sites, both questions and answers appear in this queue, but on Stack Overflow, only answers do, as questions are instead reviewed in Triage.

Basic workflow

  1. Check if the post can be improved. If you can raise its quality above the threshold of acceptability, Edit it. Keep in mind that editing within the queue will be a unilateral Looks OK vote, so be careful with edits that just make minor improvements (“rearranging deck chairs on the Titanic”).

  2. If you think that an answer does not address the question at all or is incomprehensible, Recommend Deletion (see common reasons below). If you haven’t left an individual comment or upvoted an existing one, consider choosing an appropriate canned comment from the list. Note that these are really just canned comments, which have no further effect.

    If you think that a question should be closed, Recommend Close.

  3. If the above doesn’t apply, choose Looks OK. This is the correct choice for answers that are just wrong or for questions that aren't closeable.

  4. If you are unsure, Skip it.

Most of the time, the reviewer should not need domain expertise to perform the review.

If you have sufficient reputation to cast close votes, Recommend Close turns into Close and also casts a close vote. If you can vote to delete, Recommend Deletion turns into Delete and casts a delete vote. Both reviews count the same toward the review outcome.

Common cases

  • [QA] Spam or offensive posts: click the "link" to the post, and cast its corresponding flag. Do not "recommend deletion" or "delete" in the queue; as authors are able to undelete posts deleted in this queue, they can restore the spam or offensive post without a trace.

  • [Q] Close-worthy questions: Recommend Close brings up the regular close dialog.

  • [A] Comments posted as answers: This is common from users who do not have the 50 reputation required to comment, but feel they have something useful to say. Nonetheless, recommend deletion. In the exceptional case where the answer contains useful information but still makes no attempt to answer, consider flagging it for moderator attention and asking that it be converted.

  • [A] “Thank You” answers, “I’m having this problem, too” answers and different questions posted as answers: These are considered noise; answers must be actual answers. Recommend deletion and choose the corresponding canned comment. Consider leaving an individual comment to help with the choice of asking a new question or to recommend improvements on a possible new question.

  • [A] Link-only answers: These tend to break under maintenance of the linked reference. Users should be encouraged to include the essential parts of the solution in the answer's body. Note that, only if the answer is fully worthless without the link, it actually is a link-only answer. Also watch out for spam.

    • If the information behind the link is worth having, not already included in other answers and can be edited in, do so in quote markup (beware of copyright infringements, though).
    • If the link is helpful but it’s inherently impossible to edit the information in (e.g., if the link is to a video or copyrighted image), recommend deletion. If the answer would make a useful comment, consider flagging for moderator attention.
    • If the information behind the link is redundant to existing answers, recommend deletion.
  • [A] Answers that fail to address the question: If you evaluate the answer such, first check carefully whether there is a lack of clarity in the question that you and the answer’s author may have interpreted differently. Otherwise recommend deletion. Leave an explaining comment in both cases.

  • [QA] Gibberish: If the post is clearly not intended to be understandable, recommend deletion or closure as unclear what you're asking.

  • [QA] Incomprehensible posts: Improve what you can and leave a comment for the author. Vote to close questions as unclear what you're asking. Recommend deleting an answer, if what is understandable does not make for an answer.

  • [QA] Bad formatting, spelling, structure and language: Improve it or leave a comment to the author. If there is no other problem and the post is understandable, choose Looks OK.

  • [A] Wrong and unhelpful answers: If you can fix it without making an intrusive edit, do so. Otherwise, leave a comment explaining what’s wrong and possibly downvote. If there is no other problem, choose Looks OK.

  • 5
    for the record, suggestion on how to pick between Looks Good and Recommend Deletion is provided here: "1. Does the post attempt to answer the question? No Delete, Yes goto step 2. 2. Would it be possible for a reasonably-intelligent English-speaking person familiar with the topic to understand the solution being presented? No Delete, Yes Looks Good." – gnat Sep 20 '13 at 10:56
29

Guidelines for reviewing First Posts

Keep in mind that the user is new to your site, so they don't know all of the ins and outs of posting a question/answer. It's critical that you offer accurate and helpful guidance.

Questions earn votes according to their value to future users as well as the asker, and according to their answerability. A question that just asks "How do I ..." without clarifying the circumstances, showing what the asker has tried, or explaining the issues they are seeing with their current effort is not a useful question. You may improve it or vote to close it. Answers earn votes according to their usefulness, accuracy, and completeness. For example, an answer that consist on merely a link is not useful at all, and you can flag it as Not An Answer.

Like any queue, if you're not sure what to do with a post, you can skip it.


Common reasons to Flag/Close/Delete

For all posts

For questions

  • Check that the meat of the question is in the post itself and not hosted off-site (JSFiddle, the asker's broken production site, an article, etc.). The question should be written so that it makes sense even if the links break or change.
  • Does the question have all necessary information in a clear and focused manner necessary to provide an authoritative answer and is within the scope of your site?
    • Ask for the missing information to narrow the scope of the question, or reword the question so it fits the site scope.
  • Does the question seem like a question you have seen before?
    • Check the comments; they sometimes post duplicates
    • Go to the duplicate area in the flagging UI. See if there are any questions that are similar
  • Does the question show any sort of research value?
  • If they provide links, evaluate whether you think the question is spam. Wording like "I found one solution at link but am looking for others" may be an attempt to promote link.

Flag/Close:

  • Questions that have been already asked and answered before
  • A question that is asking multiple distinct questions, or asking a question that cannot be answered succinctly
  • A question that is not clear what it's asking about
  • A question that is too subjective, such as:

    • "Why does Technology A not do B?"
    • "What is the best C for my situation?"
    • "When will D be updated and what will be new?"
  • A question that does not fit within the site's scope as defined in its help center

For answers

  • Is the post a link-only answer?
  • Check the link if they provide one.
  • Is the person asking a new question?
  • Is the poster actually making an attempt to answer the question?

Flag/Delete:

  • Link only answers
  • Not relating to the question
  • Someone sending a "thanks" to another user
  • The original user posting the answer as the exact copy of someone else's answer

Don't focus on the actual answer itself. Focus on the formatting and the etiquette of the author.


Common reasons to edit

After determining that the post is one that will be useful to the community, take care of:

  1. Remove spurious greetings, declarations of urgency, assurances of having searched and tried stuff (especially if that stuff is nowhere to be seen in the question), promises to appreciate help, requests for links to tutorials for one who is just getting started and the like.
  2. Not enough paragraph breaks, or too many
  3. Identify an actual question, usually at the beginning or the end of the question. If it must be in the middle, consider highlighting it in some fashion.
  4. Lacking of appropriated formatting, like not formatted as code, whether inline or in blocks or quotations not properly identified as such
  5. Attempts at bulleted or numbered lists that don't use Markdown
  6. Raw links or "click here" or "this" links - the display text should be descriptive, like The MSDN Documentation or A Tutorial on Exceptions. Hover or follow the links to rule out spam.
  7. Pictures or code hosted offsite - open them in a new tab. If they're appropriate, bring them into the question. For code, you may need to know the language or technology to know what to bring in. If you don't know it, you can leave a comment instructing the author to make that edit.
  8. Spelling, grammar, and punctuation, as well as spacing oddities like space before comma
  9. Organization: many first timers have 3-4 paragraphs of talk, then all the code. Organize things correctly to increase readability and understanding of the question
  10. A title which actually describes the question
  11. Remove any sort of rudeness; make the post courteous and helpful.

After fixing all of that, if there is still more missing (for example what operating system is being used), then add a comment requesting the details be edited into the question. A comment to a new user that only asks a question will typically be answered in comments. Explain our normal procedures to them.


Common reasons to upvote

Some reviewers upvote first posts in the review queue that have nothing wrong with them, even if they would not upvote that same post if they just came across it while using the site. The usual explanation is that they want to encourage the newcomers and make them feel welcome. This is a valid reason for an upvote; if you feel that way, upvote the post before clicking I'm Done.


Common reasons to downvote

The best thing to do with bad posts in the First Posts review queue is to improve them. The next best thing to do is to close them so they won't accumulate answers until they are improved. Downvoting may give a signal to a new user that they're aren't welcome here; you might consider leaving a comment pointing them to tips on how to fix their post. If you want to downvote a first post, ask yourself if it wouldn't be better to close it or to fix it instead.

  • 2
    If a reviewer doesn't have domain expertise what should they do? It's hard for me to +1/-1 a python question when I have no idea if the answer is right even though it superficially looks good. – djechlin May 17 '13 at 22:12
  • 3
    @djechlin If you aren't sure what you should do, then skip the post and let someone who is more knowledgeable in that domain handle it. The First Posts queue is almost always empty on SO anyways, so there's no major pressure to process posts in that queue quickly. – Rachel May 20 '13 at 19:04
  • Askers must follow a link to even see it, Shouldn't it be Answerers? – Pikoh May 7 at 9:17
25

Guidelines for reviewing Close Votes

Basic workflow

  1. You may select filters to focus on a particular category. Selecting a set of tags you are familiar with will allow you to focus on questions within your own areas of expertise. There may still be many situations where skipping is vastly preferable over hastily forming an opinion.
  2. Each question will ask you "Should this question be closed as X?", however you may vote to close for any reason, or leave open. These reasons are based on previous close votes and automated algorithms, and usually accurately identify the "risk" area for the post.

Off-topic

Stack Overflow requires more than just being programming-related for a question to be on-topic:

  1. Questions about general computing hardware and software are off-topic for Stack Overflow unless they directly involve tools used primarily for programming. You may be able to get help on Super User.

  2. Questions on professional server- or networking-related infrastructure administration are off-topic for Stack Overflow unless they directly involve programming or programming tools. You may be able to get help on Server Fault.

  3. This question was caused by a problem that can no longer be reproduced or a simple typographical error. While similar questions may be on-topic here, this one was resolved 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.

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

  5. Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it. Most shopping list questions fall under this reason.

  6. This question belongs on another site in the Stack Exchange network. Remember there are numerous other SE sites the question may fit under. When you vote to close as off topic, you will be given a list of candidates it may be a better fit at. Only vote to migrate if it passes your judgment as a good quality question in its own right. We don't want to be passing poor questions to sister sites. If the question is a fit at an unlisted site, you may flag it for moderator attention, and a moderator may move.

  7. Custom reason. For users without enough rep to vote to close, this is shown as Blatantly off-topic (this question has nothing to do with programming)

See also: https://meta.stackexchange.com/questions/196815/why-is-my-question-off-topic-on-stack-overflow-even-though-its-programming-rel

Unclear what you're asking

The text in the closing dialog is self-explanatory: 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.

We regard our help center as the ultimate guide to what is and is not on topic. When in doubt, consult there.

Too broad

The text in the closing dialog is self-explanatory: Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question.

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.

Note Gorilla v. Shark questions almost always fall under this category. However, please note there are exceptions - in Gorilla v. Shark, Jeff uses the question, "Are Google+ Circles better UX for sharing among friends than Facebook Groups?" as an imperfect but potentially salvageable question.

Duplicate

  1. Remember we are asking whether an answer is found at the duplicate-linked question moreso than whether the questions are identical. You should look at the question linked and verify that it has an answer to the question being proposed for closure. If it doesn't, it should not be closed as a duplicate. (You can't vote to close questions as duplicates when the proposed target has no upvoted or accepted answer(s).)

  2. If the duplicate is closed with another reason, then evaluate whether the question is a duplicate question. If the proposed question is of better quality and worth leaving open, leave open.

  • 1
    This reads a lot like a copy of the documentation for the close reasons, and does little to address the specifics of the review situation and the queue workflow. Many other answers on this page are more helpful than this one. I'm not sure how it could be improved. Any suggestions? (Or just Be Bold and make those changes.) – tripleee Jan 28 '16 at 4:44
25

Guidelines for reviewing Reopen Votes

The items in the Reopen Queue may take more time to process than other queues. If someone votes to re-open a question, either community members disagreed, or the content of the post has changed in an attempt to improve it, so you will need to understand and evaluate the contention.

Basic workflow

Review the question as it is now.

  • Per the Guidelines for reviewing Close Votes, should the question remain closed? In short, does one of the five close reasons - duplicate, off-topic, unclear what you're asking, too broad, or primarily opinion-based - still apply? If so, vote to Leave Closed.
  • If not, vote to Reopen.
  • If the close reasons still apply, but you can edit the post in order to make it reopenable, click Edit and Reopen.
  • If you aren't sure, Skip.

However, keep in mind there was some contention. Either someone felt the close votes were misguided and voted to reopen, or someone attempted to improve the question and make it passable. If the post is edited after it was closed, it might cause the review to show the edits that took place, in order to make it more clear what was improved.

It will happen more often that you are unsure what to do with a question appearing in the reopen queue. Bear in mind these questions are difficult for everyone to evaluate, so we encourage you to take the time to research the question more rather than click "Skip" on the harder ones. The following questions may help your decision:

  • Do you see why someone voted to re-open the question? Understanding the reason can make you feel more sure you considered all angles and are not "missing something."
  • Has the question's content changed in an effort to improve it since then?

If "yes" to the second, but you still feel the question should remain closed, please consider leaving a comment explaining why the changes were insufficient. In many cases, an editor or the OP sincerely evaluated the content and tried to improve it to the best of their ability, and seeing the question remain closed will likely not help them learn our standards or how to improve the question. They also have no way of knowing that their question was reviewed for reopening, and just assume "nothing" has happened.

Tips for evaluating items in the Reopen Queue

  • Do check the close reason to understand why the question was closed in the first place.

    This is particularly important with duplicate questions, as when your question is closed as a duplicate, the OP gets a message to edit their post to clarify why it's not a duplicate of the linked question, so this may have occurred.

  • Do read the comments.

    Often the reason why the post was closed or is getting a reopen vote is listed in the comments, and that can help you understand what the community is trying to do with the question, and help you make a more informed decision.

  • Don't just review the edit, if an edit is shown.

    If the post is edited after being closed, the system might show you just the edits that took place after closure, rather than the whole post itself. Sometimes these edits might just be minor, not affecting the acceptability of the question but simply making grammar or formatting fixes. Don't just review them as "Leave Closed" just because the edit is minor; it might be possible that the closure wasn't warranted in the first place, or that the post can be edited to be reopenable. Be sure to evaluate the question itself, not just the edit.

  • Don't vote to reopen items that should be closed, but were closed with the wrong close reason (in general).

    If the item should have been closed, leave it closed, regardless of what the actual close reason says. Same goes if later edits address the given close reason, but a different one also applies or begins to apply. It's recommended that you leave a comment if there isn't one already explaining the correct close reason, especially in the latter case (e.g. "your question is no longer subjective, but it's still off-topic for this site").

    Note, however, that if the duplicate close reason applies and none of the others do, and the question is currently closed for one of the other reasons, do vote to reopen the question (and then later re-close it as a duplicate), because we would rather future visitors be routed to the correct answer than be stuck. If the question is closed as a duplicate, but a different target question is applicable, review as "Leave Closed" and flag for a moderator or ping a gold-badge user to have the duplicate target changed.

  • @Rachel can't tell if this is worth spelling as general guidelines, but at reopen reviews I also check revisions done prior to closure. Edits that salvage (or at least invalidate majority vote reason) can be done earlier than question is closed. – gnat May 16 '13 at 12:18
  • 1
    @oldPro you could have updated the template rather than creating a new one... – ben is uǝq backwards May 16 '13 at 12:29
  • @Rachel edited / augmented, please review my changes if you have the chance. – djechlin May 17 '13 at 16:35
18

Guidelines for reviewing Late Answers

Answers in the Late Answers review queue are also First Posts or very nearly so, since they are posted by new users, so apply all the steps for reviewing First Posts here.

Basic workflow

  1. Many Late Answers are spam or self promotion. A new user searches for a word or phrase and adds the answer "My product does that - check it out at link!" to an old answer, or dozens of them. Check the answer against the guidelines for self promotion. If it meets them, add a comment mentioning this, to reduce the chance of other reviewers marking it spam. If it does not, add a comment linking to them and encouraging an edit. Consider keeping the question open in a tab so you can return and flag as spam in an hour or two.

  2. Many Late Answers are non-answers, either thanking the author of the question or one of its answers, asking a new question, or asking for clarification from the author. Remember, the authors of these answers haven't gained the ability to comment, so they can't properly ask for clarification. Also, many users mistake Stack Exchange for a traditional forum, where it's okay to post "thank you" answers or new questions with an answer.

  3. It's important to check if the answer is really relevant to the question. If you don't know the topic well enough to assess this, avoid actions beyond simple editing for format.

  4. If you flag, you can leave one of several "canned" comments or your own. Unless there is an existing comment that covers the situation, do add one - the user needs to learn what they did wrong in this case.

Common reasons to Flag / Close

  • Spam
  • Well-intentioned "not an answer" from someone who needs to be educated about our site

Common reasons to Upvote

  • The answer is high-quality and correctly answers the question
  • Late answers are not "by def'n" first posts. Is it the case that only questions that are also first posts make it into the "late answer" queue though? If so then this should be made precise; if not, corrected. – djechlin May 17 '13 at 22:18
  • See meta.stackexchange.com/a/177553/147247 - late answers are from "new users" which while not quite as strict as First Posts, is "close to that" - you or I cannot post "Late Answers" by the definition of the queue. – Kate Gregory May 18 '13 at 20:56
  • Possible typo: 2nd line of #1 -- should "to an old answer" be "to an old question"? – fixer1234 Jul 16 '17 at 4:55

You must log in to answer this question.

protected by Shadow The Dragon Wizard Jun 13 at 11:16

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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