Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 158 Stack Exchange communities.

What is meta?
Here's how it works:
  1. Any Stack Exchange user can ask a question
  2. The community provides support, votes on ideas, and reports bugs
  3. Your voice helps shape the way Stack Exchange operates

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.

Review Queues

Return to FAQ index

share|improve this question
@minitech Before making this "official", I'd work through the close vote section which still explains the old close reasons. – slhck Sep 14 '13 at 21:06
@minitech Thanks for the faq tag; I just edited the Close Votes answer, and placed a bounty to help improve it (also asking for community input about the future of this post.) – bfavaretto Sep 16 '13 at 19:20
@bfavaretto You shouldn't actually award it, especially to that answer. The user who would actually receive the reputation there has contributed literally nothing to that particular answer other than posting a basic template with no information in it and certainly isn't worthy of a bounty. I'm all for using bounties to attract attention to a FAQ, but actually awarding it a) doesn't reward the users who actually contributed any content and b) makes a certain answer within a group of answers stand out more than the rest. We have rep-agnostic voting to bump the most relevant ones to the top. – animuson Sep 17 '13 at 1:31
@animuson You're right, I checked the revision history of all answers, and none looks particularly deserving of the bounty. It's a pity, I expected to return the +500 to the community somehow. I'll see what I'll do. Could you edit the bounty notice to remove the part where I say the bounty is going to that answer? Thanks. – bfavaretto Sep 17 '13 at 3:27
@bfavaretto Moderators do not have the ability to edit the bounty notice. I could remove it and you can re-issue it if you'd like to remove that part of the text. – animuson Sep 17 '13 at 3:29
@animuson That sounds like a mess, it will be gone in 7 days anyway... Then we can just wipe the comments. But thanks. – bfavaretto Sep 17 '13 at 3:41
Based on this conversation on Meta.SO, should there be an edit to encourage users to skip questions and answers that they don't fully understand? – Kevin Apr 26 '14 at 21:55
@Kevin Yes, I believe so. Please feel free to add that yourself if you have a phrasing suggestion. – bfavaretto Apr 26 '14 at 22:22
If management are happy with this faq (and the faq tag being present suggests they are), can we have an (even more) link, linking to here, added after the existing (more) link (or at the end of the pop-down that is displayed by it) when reviewing? – Mark Hurd Jul 11 '14 at 6:38
up vote 52 down vote

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.
  2. Check if there is any reason to reject the edit. If you find any, Reject or Reject and Edit.
  3. Verify if the suggested edit is complete. If there is anything else to edit, Improve Edit.
  4. Otherwise, Approve.

Common reasons to Reject

  • Edits that introduce formatting (code, bold or italic) where such additions just don’t make sense or don’t make any difference. Reject as no improvements whatsoever, vandalism or causes harm, depending on the case.
  • Edits that change an answer’s explanation or code to a supposedly better alternative. Even if the proposed solution is better, it should be added as a comment or a separate answer. Reject as clearly conflicts with the author’s intent. If the edit summary specifically mentions that these changes are from a comment by the author of the post, the edit can be accepted.
  • Edits that attempt to add clarification to an answer, like “this doesn’t work in Windows 8”, or add further questions to an answer should be rejected as attempt to reply.
  • 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 the author’s intent or causes harm.
  • Edits that plagiarize content from an external source without proper attribution. Reject as causes harm. (Always check for plagiarism from common sites such as wikipedia when a tag wiki/excerpt is created!)
  • Edits that add content that doesn’t belong (e.g., “thanks in advance”, “please help me”, “SOLVED” in the title).
  • Edits that add irrelevant tags.
  • Edits that change URLs to link to unrelated content (hover changed links to make your browser show the actual URL) should be rejected as spam or vandalism.

Explicitly check URL changes: This is an easy way to sneak spam in, so do not assume a link update is correct without verifying.

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 the language: Sometimes an edit fixes a minor typo in the code 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 the language. 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 should mostly 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, rejecting for violating the author's intent is rarely acceptable.

share|improve this answer
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
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
@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

Guidelines for reviewing First Posts

Keep in mind that the user is new to Stack Overflow, so they don't know all of the ins and outs of posting a question/answer.

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 errors 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, a link only answer is not useful at all, and you can flag it as Not An Answer.

Common reasons to Flag/Close/Delete

For Questions

  • Check for code, provided that it is a question that can have code. Code hosted offsite (jsfiddle, the asker's broken production site) is inappropriate. Askers must follow a link to even see it, and it is likely to change over the lifetime of the question, invalidating answers given earlier.
  • 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.


  • Duplicate questions
  • Questions that are just the user going on a rant
  • Questions only asking for a usable block of code and not seeking to understand the reason that it works, commonly known as send me teh codez
  • A question that is unlikely to ever help a future viewer
  • A question that is not really asking a question
  • A question that is asking something that cannot be definitively answered, 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?"

For Answers

  • Is the post a link only answer?
  • Check for the instance of code if they provide a link.
  • Is the person asking a new question?
  • Is the poster answering the question?


  • 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 (similar to a thanks)

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. Code not formatted as code, whether inline or in blocks
  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. Since their rep is generally 1, downvoting won't reduce their rep; its impact is entirely emotional. If you want to downvote a first post, ask yourself if it wouldn't be better to close it or to fix it instead.

share|improve this answer
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
@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

Guidelines for reviewing low-quality posts

Questions appear in the low-quality-post queue both by algorithm and by very-low-quality or not-an-answer flags from users.

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 (“repainting the titanic as it sinks”).

  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.

  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. If you can vote to delete, Recommend Deletion turns into Delete.

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.

  • [Q] Closeworthy questions: Recommend Close brings up the regular close dialogue.

  • [A] Comments posted as an answer: 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. If the answer would actually be a constructive comment, consider flagging it for moderator attention.

  • [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 (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 and 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 are asking.

  • [QA] Incomprehensible posts: Improve what you can and leave a comment for the author. Vote to close questions as unclear what you are 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.

share|improve this answer
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

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.


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:

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: There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.

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.


  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.

share|improve this answer
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 at 4:44

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 - Exact Duplicate, Off Topic, Not Constructive, Not A Real Question, Too Localized - still apply? If so, vote to Leave Closed.
  • If not, vote to 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 open, or someone attempted to improve the question and make it passable. It will happen more often that you are unsure what to do with a question appearing in the re-open 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.

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.

  • Do check the Revision History.

    Was an edit done to address the reason it was closed in the first place? The edit may have been done prior to the question getting its last close vote, so don't forget to check the earlier revision history.

  • Don't vote to reopen items that should be closed, however were closed with the wrong close reason.

    If the item should have been closed, leave it closed, regardless of what the actual close reason says. Although do leave a comment if there isn't one already explaining the true reason why the question was closed. Furthermore, if the question is a duplicate and is closed for one of the other reasons, do flag for moderator attention and explain, because we would rather future visitors be routed to the correct answer than be stuck.

share|improve this answer
@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
@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

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

  3. 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
share|improve this answer
This answer is a placeholder; feel free to fill with appropriate content. – Robert Harvey May 16 '13 at 20:30
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 - 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

You must log in to answer this question.

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