31

In response to: Pending approvals: allow for adding reasons to rejections we will be implementing rejection reasons for suggested edits.

This means each time you reject an edit you will be able to select why.

Benjol already started collating a list.

However I feel we need a bit more feedback on copy and options.

What should the suggested edit rejection reasons be?

| improve this question | |
  • 3
    Do we also get an other field? Would this also cover tag wiki suggesteds? – random Sep 20 '11 at 23:13
  • @random I am not sure, I want to see how far we get with canned messages – waffles Sep 21 '11 at 0:56
  • 1
    @waffles: Sticking solely to canned responses will not get us very far. There are infinitely many ways for a suggestion to not be helpful and often doesn't occur one at a time. I think canned responses should be considered a convenience to those who wish to leave the feedback. Having an other response should be a necessity. – Jeff Mercado Sep 21 '11 at 7:13
  • Please see the edit to my answer, just got frustrated with a Tag Wiki suggested edit on SO. – Lance Roberts Oct 7 '11 at 3:47
  • 1
    Please give us a reason for rejecting a Tag Wiki Excerpt edit that has too much information for an excerpt. – Lance Roberts Oct 15 '11 at 5:27
19

These are comments that I've wanted to leave. It's quite a long list, so I've made it two-level, arranged as forget it, do something else, and try again. I'm still toying with the order. Many reasons apply only to tag wikis or don't apply to tag wikis, so I've split my presentation into two lists.

Questions and answers

  • Not a good suggestion
    • Your suggestion changes too much from the original post. [this is kind of the fallback case]
    • This is not clearly an improvement, let the original poster have his way.
      [For style issues, or when an edit is about opinions rather than correcting something that's objectively wrong. This wording could use some improvement.]
    • You claim to be fixing a factual error, but the answer was correct. [only for answers]
    • Vandalism [covers spam, editing to add insults, editing to delete contents, afdshfdsga, …]
      [Should this raise an automatic flag if the user isn't anonymous?]
  • Please try again
    • This edit is too minor. Please fix more of the obvious issues.
    • This edit introduces more issues than it fixes. [should generally be accompanied by a short indication of which is the good stuff and which is the bad stuff]
  • Do not use the edit button to reply to an answer. [answers only]
    • This should have been a separate answer.
    • This should have been a comment.
    • Please update your question instead. [only if the editor is the asker]
    • Please upvote the answer if you liked it, and consider marking it as accepted. [the last bit, only if the editor is the asker]
    • Flag to merge user with asker [if the editor is not the same user as the asker but clearly the same person] [no rejection message, but instead raise a flag requesting an account merge]

Tag wikis (excerpts and bodies)

  • Not a good suggestion
    • This is not an improvement.
    • Vandalism [covers spam, editing to add insults, editing to delete contents, afdshfdsga, …]
  • Please try again
    • Your edit introduces more issues than it fixes. [should generally be accompanied by a short indication of which is the good stuff and which is the bad stuff]
    • Your proposed content does not adequately describe the main use(s) of the tag. [a common issue with tags that have different immediate meanings to different crows, such as many TLAs]
    • Your proposed content is copied from an external source. Don't do this.
      [Technically a subcase of the previous one, but a common one. Usually the external source is Wikipedia, and it's both a license issue and an issue with the selection of information. On SO, suggested tag wikis for products sometimes are ad copy written by the company or project.]

On free-form reasons

At least the “please try again” category, if not all of them, should have an optional free-form field in addition to the canned reason. Ideally, this free-form field should be available when accepting as well (“thanks, but next time please remove ‘thanks’ as well”).

I'm undecided about allowing an “other” category. I can't think of a reject reason that doesn't fit here, and I've rejected something like 800 or 900 suggested edits across Stack Exchange. I haven't trawled through my whole history to write this post though, so it's possible that I've missed something. “Not an improvement” is pretty broad anyway. I think I've covered all the reasons that have been mentioned in this thread so far.

Ancillary remarks

While you're at it, please implement the long-awaited Reject and Improve button.

| improve this answer | |
  • 3
    You might want to wrap the last line in <h1> and <blink> so that the team will see it. – Lorem Ipsum Sep 21 '11 at 0:26
  • You just need to be careful that you're not telling the user to do something he can't (i.e. This should have been a comment)... – Benjol Sep 21 '11 at 4:59
  • 2
    @Benjol why not? In these cases the user needs to be told what they're doing is wrong and why it is wrong. If they can't do the correct alternative for their action that's unfortunate, and it would be best to make it clear that the correct method is something they may yet have to earn (eg, link to the privilege pages or something), but we should be telling them what's correct ready for when they do earn the privilege to do so. – DMA57361 Sep 21 '11 at 11:25
  • @DMA57361, that's pretty much what I mean :) – Benjol Sep 21 '11 at 12:42
6

Seems like Benjol's list should be replicated here:

The reasons could be (loosely inspired from here):

  • Timid edit: Always strive to improve as much as possible with each revision - if you can't, then leave the task for someone who will.
  • Violent edit: Your edit has gone too far, and changed the meaning to the point where it is probably no longer relevant.
  • Backwards edit: Your edit has introduced new quality issues which weren't there in the original.
  • Aggressive edit: You are simply using the edit tool to insert completely new material, rather than updating anything currently extant. A better choice would be a comment or a new answer.
  • Pedantic edit: The edit doesn't really improve the quality of the post, but focuses on trivial or even potentially controversial details (e.g. 'correcting' British/American spellings).
  • Spam edit: the edit doesn't have anything to do with the answer; it is spam.
| improve this answer | |
  • This could also be edited into the question body. – jscs Sep 20 '11 at 23:11
  • 2
    I have a concern around the wording, it is a bit on the "aggressive side. – waffles Sep 20 '11 at 23:12
  • 2
    @waffles: Agreed; I definitely think the titles ("Timid Edit", etc.) should be left off in the final copy, for one thing. I read them as just being for discussion's sake. – jscs Sep 20 '11 at 23:17
  • Does voting up my own list count as cheating? (Thanks Josh). I think that the titles could be left for the reviewer, as it makes the list easier to scan quickly. You could leave them off for the person on the receiving end. – Benjol Sep 21 '11 at 4:49
4

I'm very glad to hear this is coming. Benjol's list looks good. The only further items I can suggest would be:

Risky Edit -- This suggestion changes the code in a question, which may not be such a good idea.

Also, for "Backwards Edit" particularly, I'd like a sentence's worth of space to point out the specific quality issues that were introduced. I've seen some added "Thanks" and such in the queue and it'd be nice to be able to say "Don't do this or that, please."

| improve this answer | |
  • +1, I constantly reject edits on questions/answers for changing code inappropriately. Huge pet peeve. If it's bad code in a question, answer the question. If it's bad code in an answer, leave a comment. – user7116 Sep 23 '11 at 3:08
3

I just rejected a suggested edit, because the editor thought that text shouldn't duplicate between the excerpt and the main section of the tag wiki (missing the meaning of the word excerpt).

I've rejected other tag wiki edits because they put too much in the excerpt, or left out needed tag information (meta stuff on how to use the tag).

I've also had to reject some tag wiki edits that were completely incorrect about the tag they referenced.

So some Tag Wiki Suggested Edit reasons:

  1. Tag Wiki Excerpt should usually be a concise subset of the Tag Wiki.
  2. Tag Wiki Excerpt needs more tagging instruction
  3. This text does give a true description of this tag.

Of course, a lot of the normal suggestion reasons will also work for Tag Wiki edits.

EDIT: Now that I've got to use the reasons, I see the real need to be able to enter a more specific reason, so that the editor is educated on what they need to do better. It's especially important for Tag Wiki edits, since most editors won't qualify to improve them and fix problems they see.

| improve this answer | |
2

Just to add my support to Lance and Gilles' answers and call out explicitly what they imply: I think that Suggested edits for tag excerpts and wikis probably need special treatment.

(For instance, one problem that is specific to these is that "something is better than nothing" (or is it?). In the case of other edits, there is something to revert to, but when I'm looking at a Tag excerpt which ignores pretty much all the guidelines, but where there was nothing before, I'm never too sure what to do.)

| improve this answer | |
1
  • suggested edits left other obvious errors/issues
  • changed fundamental information
  • attempt to communicate with author: use comments!
  • attempt to add new question: ask your own question!

Needs better wording, but those are the ones that immediately come to mind.

| improve this answer | |
  • 4
    I wonder if rejections are inbox worthy, that way it teaches – waffles Sep 20 '11 at 23:11
  • 4
    @waffles: Rejections should be searchable at least. Right now it's impossible to find links to rejected edits. You either have to memorize it or use the limited history in the suggested edit page. It should be listed in the user's profile somewhere. Something like under a proposed edits and have filters for showing approved, rejected and pending. – Jeff Mercado Sep 20 '11 at 23:14
  • 1
    Well, I'd certainly like to be alerted to an edit that didn't cut it. I wonder if people who get a lot of rejections wouldn't get annoyed at it, though. Then again, if they're getting rejected that much I suppose their edit privs will be revoked soon enough. – ale Sep 20 '11 at 23:14
  • 2
    @AlEverett, they'll only get annoyed if they can't work out why. That's why I'm totally in favour of this feature (rejection reasons), because we can educate a hoard of new 'talent'... And if the ones who don't want to be educated give up in disgust, so much the better. – Benjol Sep 21 '11 at 4:57
  • @Benjol: I don't disagree. I'm actually in favor of these showing up in the inbox. I was just trying to make sure that all angles were considered. – ale Sep 21 '11 at 12:43

You must log in to answer this question.

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