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 curating 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 coming up for review 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


7 Answers 7


Guidelines for reviewing Suggested edits

Basic workflow

On large sites, before starting, try to set filters (little link on the top of the screen) so that you are shown edits on topics you know something about. It's easier and faster to evaluate edits to those posts.

  1. Review the differences between the original post and the suggested edit, and the edit summary above the differences.
  2. If there's clear evidence that the edit makes the post worse, that it doesn't solve critical issues, or that the changes to the post or the edit summary contain Code of Conduct violations, click either Reject or Reject and Edit. For Code of Conduct violations, raising an "in need of moderator intervention" flag on the post and explaining the issue is beneficial.
  3. If you aren't able to ascertain if the post is better or worse after the edit, click Skip.
  4. Verify if the suggested edit is complete. If there is anything else to edit, click Improve Edit.
  5. If the edit improves the post and there is nothing else that could use revision, click Approve.
    • If the buttons show as Approve and leave closed and Approve and reopen, follow the guidelines for reviewing reopen votes to determine whether the edited question should be reopened, and choose the appropriate option.
  6. If an approved edit addresses comments in a way that makes them no longer needed, flag those comments as such.

Common types of edits to Approve

  • Edits that attempt to add clarification to an answer, like “this doesn’t work in Windows 8”, or addendums to the post
  • Edits that fix grammatical mistakes or make the post easier to understand
  • 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

Approve and leave closed vs. Approve and reopen

On suggested edits to closed questions, the suggesting user will have the option to indicate whether their suggested edit resolves the close reason(s) and makes the question reopenable. If this option is selected, the Approve button will change to Approve and reopen and Approve and leave closed. Selecting the former option will add the question to the reopen review queue.

Your decision either way should be independent of your decision to approve the edit - only choose one of these two options if you would otherwise approve the edit regardless of the closure state of the question. If the question is reopenable but the edit falls into the criteria for any other button below, choose that option instead.

Follow the guidelines for reviewing Reopen votes to determine if the question in its suggested form meets the criteria for reopening; if so, select Approve and reopen, and if not, select Approve and leave closed. If you're not sure, choose Approve and reopen - all this button does is add the question to the reopen review queue, so if the question is indeed not reopenable, reviewers there will review it to that effect.

Common types of edits 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.
  • Edits which introduce text which would be a Code of Conduct violation or edit summaries which contain text which are Code of Conduct violations. (In this case, also flag the post being edited for moderator attention with a link to the suggested edit review, or one of your own posts if it's a tag wiki edit.)

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, there may be additional context that should be taken into account when reviewing an edit. One example is where the post's author has provided information in a comment or (other) answer and the editor is bringing that content into the post, and another example is when the editor is making changes to formatting or image descriptions that can't be easily seen in the rendered output view. These should be mentioned in the edit summary. You can click the question link (which will open in a new tab/window) to see the full context.

It helps if you know what the post is about: Sometimes an edit to an answer fixes minor mistakes that were 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
    Commented May 17, 2013 at 16:54
  • 2
    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
    Commented May 17, 2013 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
    Commented May 20, 2013 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
    Commented Feb 23, 2015 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
    Commented Feb 23, 2015 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. Commented Feb 19, 2017 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
    Commented Feb 19, 2017 at 22:23
  • If I find some typos/mistakes or grammatical errors which I can fix but still it need 6 characters to change to submit the request. How to fix that? Commented May 12, 2021 at 20:02

Guidelines for reviewing Low quality posts / Low quality answers

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; however, on sites with Triage enabled, only answers do, as questions are reviewed there instead. As such, this queue is named Low quality answers on those sites and Low quality posts on other network sites.

Basic workflow

First, check to see if the post is a question or an answer; it will be labeled as "Question" or "Answer" at the top. (On sites with Triage enabled, this queue will consist only of answers.)

  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, choose Recommend deletion or Delete (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, choose Recommend close or Close. (See Guidelines for reviewing Close votes.)

  3. If you are unsure about the post's quality, Skip it.

  4. If the above doesn’t apply, choose Looks OK. This is the correct choice for answers that aren't eligible for deletion, or for questions that aren't closeable.

Most of the time, the reviewer shouldn't 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 have the trusted user privilege, Recommend Deletion turns into Delete and casts a delete vote. Both reviews count the same toward the review outcome as the respective "Recommend" reviews.

(Note that even though trusted users can ordinarily only vote to delete answers scoring -1 or lower, they can vote to delete answers through the Low quality posts queue even if the answer scores 0. Answers with positive scores can't be voted for deletion, and so the button will still show as "Recommend Deletion" for trusted users if the answer has a score of 1 or higher.)

Common cases

  • [QA] Spam or rude/abusive posts: follow the link to the post and flag it as spam or rude or abusive. Do not take any actions in the review queue. This will make sure that the appropriate penalties are levied, and as authors are able to undelete answers recommended for deletion in this queue, they can restore the spam or offensive post without a trace. Once back in the review queue, skip the review item.

  • [Q] Close-worthy questions: Recommend close brings up the regular close dialog. See Guidelines for reviewing Close votes for when this applies.

  • [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 additionally flagging it for moderator attention and asking that it be converted to a comment, but still review as Recommend deletion.

  • [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 is 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, click Edit and 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 additionally 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 explanatory comment in both cases.

  • [QA] Gibberish, or posts in the wrong language: If the post is clearly not intended to be understandable, or is not written in English or the language of the site, recommend deletion or closure as Needs details or clarity.

  • [QA] Incomprehensible posts: Improve what you can and leave a comment for the author. If you can't improve anything, recommend closing questions as Needs details or clarity. Recommend deleting an answer, if what is understandable does not make for an answer.

  • [QA] Bad formatting, spelling, structure and language: Improve it using the "Edit" button 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 not editing, review the answer as Looks OK: answers that don't exhibit any problems other than simply being wrong or unhelpful should be downvoted, not deleted.

  • [A] Answers that violate site-specific policies: Some sites may have additional guidelines for deleting answers. For example, on Puzzling, answers that don't provide an explanation may be deleted, and on some technical sites, answers that are harmful when tried may be deleted. If the answer should be deleted as per site policy, recommend deleting it.

  • 7
    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
    Commented Sep 20, 2013 at 10:56
  • 1
    How should I review answers with code as image? It might help, but the recommendation for such questions is to delete. So what about answers? Commented Jan 12, 2021 at 9:48
  • 1
    How to deal with posts that only have some lines of code without any explanation and where I'm unable to improve the answer?
    – robsch
    Commented Apr 2, 2021 at 18:55
  • Further to what @robsch said: What about an answer that's super brief and without any explanation? On Stack Overflow, these seem to constitute a lot of the auto-flagged answers. Assume we're not a subject matter expert. Do we just assume that they're ok? Commented Apr 9, 2021 at 18:13
  • A quick idea: As long as the answer has low quality, allow upvotes but supress that the author gets the reputation points. On review there should be an option to let the author know that fact. S/he gets (back) the points if the answer or question is considered to be good enough. However, that rmight equire something like a re-review.
    – robsch
    Commented Apr 12, 2021 at 12:38

Guidelines for reviewing First questions/ First answers

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 consists of merely a link is not useful at all.

The basic workflow is simple: if the post deserves an edit (only), select Edit. If the author could benefit from some feedback, select Share feedback. If the post deserves any other action or combination of actions (voting, flagging, editing, commenting, etc.), perform the action(s), and select Other action. If the post doesn't need any action at all, click Looks OK. Finally, if you're not sure what to do with the post, please Skip it. One review from a user is enough to dismiss the task. See below for when you should take action:

Common reasons to Flag/Close/Delete

For all posts

For questions

  • Check that the main part 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 it 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; others 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.


  • 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?


  • 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 answer1

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 submitting the review.

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 (for questions), or flag them for deletion (for answers). Downvoting may give a signal to a new user that they aren't welcome here; you might consider leaving a comment pointing them to tips on how to fix their post (or by selecting the Share feedback review option). If you want to downvote a first post, ask yourself if it wouldn't be better to close it, flag it, or fix it instead.

1 On sites with review audits, sometimes the system uses prior highly-voted answers to check to see if users are paying attention and reviewing those positively. These audits appear with fake vote scores and authorship, so if you recognize having seen the answer in the past, you may believe that it's an exact repost of that prior answer, but flagging it as such will fail the audit. If you encounter such a post, click the "link" to the answer to check if it's actually a repost; if you're directed to the previous highly-voted answer rather than a new one, it's an audit, not a repost.

  • 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
    Commented May 17, 2013 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
    Commented May 20, 2013 at 19:04
  • Askers must follow a link to even see it, Shouldn't it be Answerers?
    – Pikoh
    Commented May 7, 2019 at 9:17

Guidelines for reviewing Reopen votes

The items in the Reopen votes queue may take more time to process than other queues. If a question is in the queue, either community members disagreed with the closure and voted to reopen, or a user has edited the question to address the close reason, 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 any one of the five close reasons - duplicate, community-specific, needs details or clarity, needs more focus, or opinion-based - still apply? If so, click Leave closed and specify whether the original reason it was closed with still applies or which other close reason applies.
  • If not, click Reopen.
  • If one of the close reasons still applies, but you can edit the post so that none of them apply, click Edit and reopen. (Unlike similar "Edit" options in other review queues, this action is not unilateral; this will count as a normal "Reopen" review once completed.)
    • On sites with "beta" reputation requirements, if you have enough reputation to vote to close but not enough to make edits, your edit will be submitted as a suggested edit. Other reviewers will not see your edit until it is approved.
  • If you aren't sure, Skip.

Keep in mind there was some contention. Either someone felt the closure was incorrect or 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 clearer what was improved. Be sure to review the whole question itself, not just the edit (see the third tip below).

It will happen often that you are unsure what to do with a question appearing in this 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 "Skip" the harder ones. The following questions may help your decision:

  • If someone voted to reopen the question, do you understand why they voted? Understanding the reason can make you feel surer you considered all angles and are not "missing something." The reopen voter may have left a comment indicating why they voted.
  • If someone edited the question and checked the box to add to review, has the question's content changed in an effort to improve it since when it was closed?

If "yes" to either, but you still feel the question should remain closed, please consider leaving a comment explaining why the changes were insufficient. In many cases, the author or an editor sincerely evaluated the content and either believed that the question should not have been closed or tried to improve it to the best of their ability, and seeing the question left closed in review will likely not help them learn our standards or how to improve the question. While the system will show the reason you and/or other reviewers selected for leaving closed, it's often useful to give additional details in a comment (i.e., why the edits failed to completely address the original close reason or why the same or another close reason applies to 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.

    When one's question is closed, the author gets a message to edit their post to make it fit within site guidelines, or to clarify why it's not a duplicate of the target 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, before selecting that the original close reason was not resolved.

  • Don't vote to reopen items that should be closed but were closed with the wrong close reason (unless it should instead be closed as a duplicate).

    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. Again, when reviewing to leave closed, there is an option to specify which other close reason applies (if the given one doesn't still apply). See also the above paragraph on leaving comments in case you still feel the question should be closed.

    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. While the dialog for reasons for leaving closed does have an option that the question is a duplicate, it doesn't have any option to indicate a duplicate target and so the notice will not serve visitors to the question with a clear direction to the answer.

    If the question is closed as a duplicate but is instead a duplicate of a different question from the one specified, review as Leave closed and flag for a moderator or ping a gold-badge user to have the duplicate target changed. In this case, do use the duplicate option in the reason dialog.

  • 1
    @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
    Commented May 16, 2013 at 12:18
  • 1
    @oldPro you could have updated the template rather than creating a new one... Commented May 16, 2013 at 12:29
  • @Rachel edited / augmented, please review my changes if you have the chance.
    – djechlin
    Commented May 17, 2013 at 16:35

Guidelines for reviewing Close votes

Basic workflow

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, and is highly recommended on large sites. There may still be many situations where clicking Skip is vastly preferable over hastily forming an opinion.

Each question will ask you "Should this question be closed as X?", however you may vote to close for any reason. These reasons are based on the existing close votes and recommend closure flags, and usually accurately identify the "risk" area for the post. (If the post only has recommend closure flags and no close votes, the reasons chosen by flaggers will only show in the review header, not in the close dialog itself.)

  1. Check to see if the question meets the criteria for any close reason, as outlined below. If you're sure that it does, click Close and choose a close reason.
  2. If the question does not meet the criteria for any close reason, click Leave open.
  3. If the question is closeable as written but can be edited to fit within the site's guidelines, click Edit. This counts the same as a Leave open review when submitted.
  4. If you're not sure whether a post is closeable (it isn't a clear-cut case, and you don't have enough knowledge of the subject to make a firm determination), Skip the item.

Reasons to close a post

The general explanations for close reasons are outlined below. Some sites may have more specific guidelines on when to use specific close reasons, so refer to their help centers and per-site metas for more information.

Community-specific reasons (including off-topic)

Each site has its own specific scope as to what questions are considered "good fits" for the site, and some specific types of questions may not be considered good fits even though they are related to the site's general scope. For example, on Puzzling, questions without a citation as to where the puzzle came from aren't good fits, and on Stack Overflow, questions lacking a clear example of code aren't good fits.

Note that some of the other close reasons can also apply to such questions, but you should close those with the community-specific reason that applies to them if one exists. For example, product recommendations aren't accepted on most sites as they are considered too subjective; while the "Opinion-based" close reason technically does apply to them, if a community-specific reason about recommendations exists, you should close with that. This is so that the author will be directed to more specific resources regarding their question.

You also have the option to vote to close with a custom comment reason as to why the question isn't a good fit for the site, instead of a canned reason. This is useful for questions that are blatantly off-topic (if no canned reason to that effect exists), or for questions that are just outside of a site's scope and could use clarification as to why they're not within it.

If there's clear evidence that a custom comment reason contains Code of Conduct violations, raising an "in need of moderator intervention" flag on the post and explaining the issue is beneficial.

Finally, if the question isn't a good fit on that site, but would be a good fit on another site in the network, you can vote it for migration. For more information, see What is migration and how does it work?.

We regard the help center of each site as the ultimate guide to what is and isn't within the site's scope. When in doubt, consult there.

Needs details or clarity

The text in the closing dialog mostly explains the gist of this reason: This question should include more details and clarify the problem. Use this close reason if it's not clear what the author is asking or what issue they're facing, or if the question is missing significant details that would be required to come up with an answer.

Needs more focus

The text in the closing dialog is self-explanatory: This question currently includes multiple questions in one. It should focus on one problem only.


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 more so 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).)

    • Note that some sites may have policies that the questions should still be identical or nearly-identical to vote as a duplicate (i.e. that questions that are different but have the same answer should not be closed as duplicates). Other sites (e.g. meta sites) may allow closing questions as duplicates even if they're not asking the same question, if an answer to the proposed duplicate addresses the question.
  2. If the proposed duplicate target is closed with another reason, then evaluate whether the question should be closed as a duplicate of that. If the question you're reviewing is of better quality than the duplicate target, leave open, and consider voting the other question as a duplicate.

  3. If a duplicate exists for a given question, but another close reason is also applicable to that question, you should close with that other reason instead. Consider leaving a comment on the question to the duplicate. This is because some closed questions are automatically deleted by the system, and because closed questions that are migrated from other sites are marked "rejected", but questions closed as duplicates are exempt from these.

On meta sites, the above also applies on most questions; however, you do have the ability to close questions as duplicates of questions that don't have an upvoted or accepted answer. Questions that report bugs or request features that have already been reported or requested in the past, but have received no answers, should be closed as duplicates of the prior requests. See this answer for more information on meta duplicates.

  • 2
    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
    Commented Jan 28, 2016 at 4:44
  • 2
    You state early on, "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. " How can I do this? And can it be done for other review queues? Commented Oct 20, 2019 at 13:12
  • 1
    Will you be able to see your OWN questions in a review queue? Instinctively I'd say no, but I'm curious... Commented Aug 2, 2022 at 16:48

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. In addition to voting or flagging, you can also leave a comment. 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 / Delete

  • Spam or rude/abusive
  • 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
    Commented May 17, 2013 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. Commented May 18, 2013 at 20:56
  • Possible typo: 2nd line of #1 -- should "to an old answer" be "to an old question"?
    – fixer1234
    Commented Jul 16, 2017 at 4:55
  • Any recommended way to deal with this post, encountered in the "Late Answers" review queue? stackoverflow.com/questions/52419840/… Commented Oct 18, 2019 at 14:12
  • 3
    The scenario I see most frequently with the Late Answers queue are duplicate answers. These aren't obviously plagiarized; instead, I just assume a new user saw the question, knew the answer, and quickly posted it without first reading the existing answers. These obviously aren't contributing meaningfully to the thread, but they don't otherwise violate the guidelines. What's the best way to handle these scenarios? So far, I've been leaving comments reminding the contributor to read the existing answers before submitting their own, but then marking them as Looks OK. Commented May 7, 2020 at 0:42

Guidelines for reviewing Triage

The primary goal of Triage is to quickly sort potentially problematic questions into categories that can be routed elsewhere. On sites where the queue is large enough (e.g. Stack Overflow), consider using a filter option to only get questions within your preferred list of tags.

Here are some rules of thumb based on the review options available:

Common reasons to Skip

If you aren't sure about the suitability of the question, skip it and move on to the next one. This should be your default option: there's no penalty for skipping, and it immediately makes the question available for others to review.

Common reasons to Skip include:

  • a topic which you're unfamiliar with, and the question is not blatantly unsuitable for the site
  • the prose is hard to understand but not necessarily impossible to read
  • extremely long and detailed, combined with either of the above

Common reasons to Flag

Use Flag for questions that are spam or rude/abusive, or questions that are closeable and cannot be salvaged by the author or others to be a good fit for the site. Follow the guidelines for reviewing Close votes to see if a question is closeable.

Common reasons to choose Needs author edit

Use Needs author edit for questions that are closeable in their current state, but which can be edited by their authors to be a good fit for the site. As an example, questions that include most required details but are missing one or more crucial details required to find an answer, such as an error log or mass of an object.

Common reasons to choose Needs community edit

Use Needs community edit only for questions that are good fits for the site but which simply require proofreading to fix grammar or formatting issues.

If you can you imagine yourself (not the post's author) editing the question to improve its current state, or another random editor with more knowledge of the specific area or more patience for proofreading posts doing so, this is the correct option. This is not the correct option to choose if the question needs an edit from the author: for that, choose Needs author edit.

Common community editing tasks include:

  • Correcting substantial spelling/grammar/formatting errors
  • Rewriting the title to better represent the question asked
  • Retagging the question to more appropriate tags
  • Incorporate key information from comments or mistaken self-answers

(These reasons are borrowed from another post.)

Common reasons to choose Looks OK

If the question is a good, on-topic question for the site, and doesn't have any issues that would need to be fixed by a fellow community editor or the author, choose Looks OK

This answer is originally from the guidelines for reviewing Triage on Meta Stack Overflow. This answer is being reposted here because Triage is now available on other network sites.

You must log in to answer this question.

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