12

This post is part of a larger effort to create Help Center pages for each of the Review queues. You can learn more about this project in the overview post. These posts will be locked so that everyone has a chance to review each original draft and provide feedback in the answers. We will continue to collect feedback until November 9th, 2020.

We are looking for your feedback on this draft for the Suggested edits queue.

  • When reviewing this draft please consider the following:

  • What is essential to know about using this queue? Is there any information that’s missing or should be removed?

How do I use the Suggested edits queue?

Access earned at $Privilege-PostEditing reputation
The primary purpose of the Suggested edits queue is to review edits contributed by users who have less than $Privilege-PostEditing reputation and determine if the suggested edits are beneficial to the post. Suggested edits should focus on improving grammar, spelling, and formatting all while maintaining the author’s original intent.

For users with $Privilege-ApproveTagWikiEdits reputation, you may also see tag wiki edit suggestions in this queue. For more information about handling these reviews, see the approve tag wiki edits privilege page.

Basic workflow

Start by reading the edit summary and looking at the differences between the original post and the edit. Be sure to check the title (and tags, if a question) to see if they were edited and check the comments section for any information that the author may have included only in comments.

  • Approve if the edit improves the post and doesn’t need any additional edits.

  • Improve edit if the edit is good but incomplete, and use the edit window to fix any outstanding issues.

  • Reject if the edit is unnecessary, destructive, or counter to the original author’s intent.

  • Reject and edit if the suggested edit makes the post worse or doesn’t solve critical issues with the post and add your own edit - this will open an edit window allowing you to improve the post.

  • Skip if you’re unsure whether the post was improved or not

Common reasons to Approve

  • Adds additional information or clarifies existing answer.

  • Improves grammar, spelling or formatting of the post or other minor mistakes.

  • Edits in information found in comments.

  • Updates an answer if more information is available or something has changed.

  • Adds links to sources or citations.

Common reasons to Reject

When rejecting an edit, you’ll need to choose a rejection reason. These are a good outline for the reasons you may need to reject a suggested edit:

  • Spam or vandalism

    • adds irrelevant or unattributed promotional links or mentions of products.

    • damages or destroys the content of the post.

  • No improvement whatsoever

    • changes to content or formatting that are unnecessary or make the post more confusing.

    • changes to grammar, spelling, or style that are unnecessary.

  • Irrelevant tags

    • tags should clearly indicate the subject of the question; reject edits that add tags that are tangential or incorrect.
  • Clearly conflicts with author’s intent

    • changes a post to say the opposite, or something very different from what the original post read.
  • Attempt to reply

    • introduces a request for clarification or question to the post’s author that should have been a comment or answer.
  • Causes harm

    • This reason can be used in cases where a suggestion should be prevented but none of the above or several of the above apply. You should explain why you are rejecting the suggestion so that other reviewers can understand your action.

Some of the content of this page is adapted from information in our Meta Stack Exchange FAQ, which also contains more in-depth guidance if you are interested in reading more about this queue.

Other drafts

To review other drafts in part of this project, please see below:

Stack Overflow only:

2
  • I don't think it's a good idea to post on November 2nd and set the dead-line to November 9th. It's unreasonable to expect volunteers to consider an issue on such short notice. – bad_coder Nov 14 '20 at 7:57
  • 1
    @bad_coder being posted doesn't mean they're uneditable. We need them active for the review suspension change and there's not been any changes suggested that are earth shattering changes. – Catija Nov 14 '20 at 12:57
13

makes changes that are too big and should be made only by the author

This is dangerous; there's no clear definition for what is "too big", nor can there be - in many cases an effective edit on a question pending closure must change every word in it in order to bring it into compliance with site norms; that need not conflict with the author's intent however; it merely indicates that the author did not know how to ask their question in an appropriate fashion.

Heck... Even edits that only correct spelling and grammar may change most of a post in cases where the original author is not yet comfortable writing in English, or formatting with Markdown. These are still very useful edits!

The "size" of an edit is at best a heuristic; a human reviewer should always strive to understand the effect of the edit.

See also: intent, magnets, and reaping where you did not sow

7
  • 1
    Yeah... it's hard because even huge edits that change everything about the post... character-wise, don't necessarily change the post so much that it shouldn't be accepted since the bones and purpose of the post is still there. I'm open to other phrasings. Or, maybe the bullet point isn't necessary at all? – Catija Nov 3 '20 at 15:26
  • I don't see a need for the paragraph; would instead focus more on elaborating the one above it, on intent. E.g., drop the "very different from what the original post read" bit and aim for something more like, "very different from the author's goals". Maybe include an example or two... – Shog9 Nov 3 '20 at 17:53
  • I don't think it's about the "size" of the edit so much as it is, perhaps, the scope. Say it's unclear what a question or answer is referring to; it could be intending to ask X, but it could just as easily be intending to ask Y instead. Then, a separate user (not the original poster) suggests an edit that changes the question/answer to focus on one possible reading (e.g. X), without asking the original poster if that's what they're asking about in the question (or what they're intending to say in the answer). That effectively changes the meaning without consultation with the OP. – V2Blast Nov 3 '20 at 22:47
  • Even that can be appropriate, @V2Blast - there are questions out there now where every answerer essentially picked Y, but searchers still find when seeking X... – Shog9 Nov 3 '20 at 23:24
  • @Shog9: Ideally, IMO, those kinds of ambiguous questions should be closed even before anyone has answered them (though having answers that just guess at the ambiguous meaning of the question is even more of a reason to close) - and answers based on a guess of the author's ambiguous intent (before the question has been clarified by the querent) should probably be downvoted and told to wait for clarification by the querent. – V2Blast Nov 3 '20 at 23:32
  • Ideally... But, this frequently becomes a perfect vs good situation. A years-old question, long ago answered satisfactorily, which is now causing confusion... Can be easily made less confusing while keeping the utility via an edit; why not do so? – Shog9 Nov 3 '20 at 23:34
  • I've removed it - I couldn't come up with an alternative that made sense. – Catija Nov 10 '20 at 21:04
11

Reviewers should be reminded not to approve edits that inline images of text (code, quotes, error messages, output, etc.)

Part of the reason new users can't inline images themselves is so that they can't include screenshots instead of properly copying the relevant text into their question or answer (see Why are images of text, code and mathematical expressions discouraged?). Unfortunately, people often "helpfully" inline these images via edits.

Such edits are often approved, when they should be rejected (ideally informing the editor and the original poster why such images are discouraged).

1
  • We'll discuss. This is on the cusp of being too much detail for the average reviewer. We don't really have a reject reason for it, even, so it doesn't have an easy bucket to fit into. It may be better served as the "additional info" that is found in the FAQ. – Catija Nov 10 '20 at 21:05
9

Should we say something about how to review tag wiki edits here? I.e. mention that you will come across those things in this queue if you have enough rep and you should look for... when reviewing them.

For instance the most common problem I find in tag wiki edit suggestions is plagiarism, especially with an initial edit suggestion. We've not mentioned that at all here.

5
  • I had thought about this. I wasn't sure since the vast majority of people who see this post may not have the required rep to care about them... so it might be better to have this info attached to the 10k privileges somehow? – Catija Nov 2 '20 at 22:35
  • It's 5K for tag wiki edits. You could always have a sentence or two mentioning them and then link to a specialised wiki edits page with the complete editing approval guide for tag wiki edits. – Robert Longson Nov 2 '20 at 22:38
  • 3
    Good idea. Let me see what I can poke at. Thanks – Catija Nov 2 '20 at 22:44
  • 2
    How about something like "There are additional concerns when reviewing Tag Wiki edits to prevent plagiarism. For more information on these edits, see the Tag Wiki edits FAQ on MSE."? – Catija Nov 3 '20 at 15:35
  • @Catija that works for me. – Robert Longson Nov 3 '20 at 15:52
9

It needs to be clearer when an edit should be rejected for being too minor

Here's an example review (note: the diff is slightly misleading as it shows a later version of the question text; see revision history for details). It fixes a typo in the title of a question, when that typo was actually repeated many times in the post body (along with other typographical issues). It was approved, presumably because the title being spelled correctly is an improvement for people searching for the question, even if it would have been much better if the entire post had been fixed properly. A CM overrode the approval of the edit and replaced it with a much better edit that did fix all the problems.

These guidelines, as written, imply that this edit should be Approved ("Improves grammar, spelling or formatting of the post or other minor mistakes.") or Improved ("if the edit is good but incomplete").

Should such edits be approved now? If not, could the guidelines be clarified to make this clearer?

Note: I don't have a strong opinion on what the right answer should be, I just want it to be clearer.

6
  • How did the suggested edit overcome the minimum 6 characters length? I thought that limit was made to avoid trivial edits/those types of situations – Mari-Lou A Nov 3 '20 at 12:42
  • @Mari-LouA I believe that restriction only applies to body edits. Since this edit only touched the title, it did not apply to it. Regarding preventing trivial edits, I've certainly seen users make useless body edits as well: one user suggested a large number of edits capitalizing only the word "I" and the name of an IDE. – Ryan M Nov 3 '20 at 12:43
  • Does that mean even the addition of a single comma or an apostrophe is sufficient for an edit to enter the queue? – Mari-Lou A Nov 3 '20 at 12:45
  • For the suggested edit queue, I believe so, as long as the edit is to the title. – Ryan M Nov 3 '20 at 12:47
  • 1
    The reject and edit reason specifically covers this, I think - "Reject and edit if the suggested edit makes the post worse or doesn’t solve critical issues with the post and add your own edit" I'm hesitant to start talking about "too minor" as I don't personally feel that's a rejection reason. I want to focus on an edit clearly failing to fix things (as in your example) that should have been caught. If it's the phrasing here that's confusing, happy to rework it. – Catija Nov 3 '20 at 15:41
  • Too minor isn't a reject reason, and frankly at this point SO should take whatever volunteer time it can get with edits because there's a lot of work to do. Rejecting a partial improvement is OK if somebody goes back and improves the rest of the post, but I don't think it's particularly smart to reject (not "reject and edit") a "minor" edit and then leave a flawed post to linger in that state forever (which I've seen a bit too often). Straight up rejecting a minor (but valid) edit is saying "Thanks for trying to improve SO, I don't have time to fix mistakes, just leave it". – jrh Nov 5 '20 at 14:04
6

Minor proofreading/grammar issues:

good but incomplete and use the edit window

This should have a comma after "incomplete," as it joins two independent clauses.


with the post and add your own edit - this will open an edit window

This should be an em dash: "...you’re not certain—don’t be afraid...", as it joins two independent clauses. There should probably also be a comma before "and add" for the same reason as above.


Updates to an answer if more information is available or something has changed

This is a complete and total style nitpick and this isn't actually wrong, but it would be more consistent with the other bullet points if it removed the "to" (and if the bullet points were consistent about periods at the end).


Changes an answer's explanation or code to a completely different meaning or solution

This looks like it was supposed to be under "Clearly conflicts with author’s intent" and was accidentally put under "Causes harm"

3
  • a regular dash with spaces around it is an acceptable alternative for an em-dash and doesn't require me to use special characters. :D – Catija Nov 3 '20 at 15:48
  • @Catija: At a glance, the quoted text seems to be a hyphen, not a dash. "A regular dash with spaces around it" would instead be an en dash, which is just as correct as an em dash without spaces around it. :P – V2Blast Nov 3 '20 at 22:54
  • I'm not sure if the help pages use the standard Stack Exchange markdown renderer, but if so, one can simply write — to avoid the need for special characters. That's what I did in my post (it doesn't work in comments, though). – Ryan M Nov 3 '20 at 23:34
6

The details of "Causes harm" are a bit off. We're not just using that reason to inform other reviewers — the primary goal is to educate the user suggesting the edit. Also, the final sentence should be properly connected to the previous sentence. Perhaps this works better:

You should explain why you are rejecting the suggestion so that the author of the edit and other reviewers can understand your action. For example, that it changes an answer's explanation or code to a completely different meaning or solution.

(As a side note, 'code' is a bit technology-oriented. Yes, more than half of the network is technology-oriented, but stil ...)

2
  • I... think that it may be an error. That sentence matches author intent better than causes harm? – Catija Nov 2 '20 at 22:19
  • I too realized there's another problem, more than just a grammatical one. – Glorfindel Nov 2 '20 at 22:22
5

Would it make sense to add some advice for how to handle edits that are, in themselves, not bad, but fall into the inappropriate polishing category? For example, what should the reviewer do if a well-meaning but misguided editor changes:

i lost me troosers where is it is anyone knows

to:

I have lost my trousers. Does anyone know where they are?

I think the answer given by animuson is about as good as it gets; could a shortened version of that be included in the help text?

Of course, there will be far more such edits made to less extremely off-topic posts. And a similar situation would be minor (but good) 'cosmetic' changes to closed questions (such as markdown format corrections to a duplicate).

5
  • 1
    This is also a problem on language sites, fixing the spelling is not enough to make an off-topic post on topic and approving the edit (which may even have 3/4 close votes) bumps it to the top of active page. – Mari-Lou A Nov 3 '20 at 12:58
  • An issue is that, other than rejecting with "Causes Harm" and leaving a custom comment, there is no built-in mechanism for informing the editor (likely a new contributor) why their action is wrong. It seems a little unfair to 'punish' their well-intentioned corrections. – Adrian Mole Nov 3 '20 at 15:04
  • The editor is also a user who needs to learn what questions are on-topic and which are not. Knowing how to use SE requires patience, and a certain humility. Overall, it's a steep learning curve . – Mari-Lou A Nov 3 '20 at 15:28
  • @Mari-LouA Indeed. But an extra 'reject reason' along the lines of "Insufficient improvement" (with a suitable short note) would be nice, IMHO. But that's maybe beyond the scope of the current round of changes. – Adrian Mole Nov 3 '20 at 15:30
  • 1
    Your first comment encompasses most of my concern, there's not really a good reason for rejection (based on our current reasons). And, even animuson seems somewhat ambivalent about what the correct action is (and jmort has a strong competing argument)... so with that and my feeling that this may be too specific for a help page, I think I'll recommend this be in the FAQ for now until/unless we can find a better way to include it in the UI. – Catija Nov 10 '20 at 21:12
2

Reviewers should be informed how to handle edits that translate content

This may need to be site-specific, as I believe different sites have different policies around this.

One common mistake in suggested edit review on Stack Overflow is approving edits that translate posts into English when there is no indication that the asker understands English. This is considered a bad practice, as the asker is unlikely to be able to engage with feedback or answers in order to determine if they solve the problem.

Currently, the only way for reviewers to discover that such edits should be rejected is to find that Meta post. It would be ideal if this were more prominent, such as in a help page for the queue.

1
  • This is certainly a concern but I have a similar response to the one I left on Adrian's answer. – Catija Nov 10 '20 at 21:13
0

My improvements are in block capital letters

  • Causes harm
  • This reason MAY be used where an EDIT should be REJECTED BECAUSE none or TWO OR MORE of the above apply. PLEASE explain why the SUGGESTED EDIT NEEDS TO BE REJECTED so that AUTHORS and REVIEWERS WILL understand your REASON. FOR EXAMPLE: “Changes THE explanation” or “CHANGES code to a completely different solution.”
2
  • Is authors on purpose plural? Do you mean both the OP and the user who suggested the edit? – rene Nov 3 '20 at 14:02
  • 1
    @rene that's a possible interpretation, which also works. The plural form in this instance has a generic meaning, it's short for "all authors". – Mari-Lou A Nov 3 '20 at 15:25

You must log in to answer this question.

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