All Collections
Enterprise
Content
Reviewing—a Deep Dive
Reviewing—a Deep Dive

Guidelines for reviewing posts in SOE.

L
Written by Loren Alldrin
Updated over a week ago

Applies to: Enterprise

This documentation is for Stack Overflow Enterprise. Free, Basic, and Business users can access their documentation here. Find your plan.


Overview

The review queues contain posts that may need further action from the community, such as editing, 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.

NOTE: We use the generic word "community" in this article, not to be confused with Stack Overflow's Communities feature.

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 reviewing Suggested Edits

  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 accept the edit. If you find any, click Accept.

  3. Verify if the suggested edit is complete. If there is anything else to edit, click 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, click Skip.

Common reasons to Accept

  • Edits that attempt to add clarification to an answer, like “this doesn’t work in Windows 11”, 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 improvements whatsoever, vandalism, 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 the author’s intent.

  • 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 what the post is about: Sometimes an edit fixes a minor mistake 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.

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.

Guidelines for reviewing First Questions and 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 consist of merely a link is not useful at all, and you can flag it as Not An Answer.

First Questions—things to watch for

  • Check for context, provided that it is a question that should have. The context 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 has 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 lacking information, to narrow the scope of the question, 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.

Common reasons to Flag/Close First Answers

  • Questions that duplicate an existing question

  • Questions that are just the user going on a rant

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

First Answers—things to watch for

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

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

Common reasons to Flag/Delete First Answers

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

Guidelines for editing first posts

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

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

  • Not enough paragraph breaks, or too many

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

  • Lacking of appropriate formatting, like not formatted as code, whether inline or in blocks or quotations not properly identified as such

  • Attempts at bulleted or numbered lists that don't use markdown

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

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

  • Spelling, grammar, and punctuation, as well as spacing oddities like space before comma

  • 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

  • A title which actually describes the question

  • 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 first posts

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 first posts

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.


If you need further support or have questions, contact your site administrator.

Did this answer your question?