Currently, when a user rejects and edits a suggested edit, Community♦ rejects it with the following reason:

This edit did not correct critical issues with the post - view the revision history to see what should have been changed.

The problem is that when I reject and edit, I would like to provide more feedback to the editor than just that. Sometimes some edits can be bad for one of the reasons mentioned in the list of reasons for rejecting, and I would therefore like to reject them for one of those reasons, but the original post contains some completely different issues that I would like to correct.

I currently see two solutions to this problem:

  • Simply reject the edit without editing and then hope that others also reject it and come back when they have done so. The problem is that I'm very likely to have forgotten all about it once this is done.
  • Reject and edit anyway and hope the editor understands why the edit was rejected. This could work if someone else has already rejected the edit, but generally not.

None of these solutions are really good, and when I face this situation, which one of them I choose depends entirely on the circumstances.

Here is one example of an edit that I rejected and edited but that I would have liked to give a more specific reason for rejecting. That edit formats unformatted code, which is useful, but it also removes a lot of code from a question. The code that it removed may or may not have been useful, but since the edit summary didn't mention anything about the removed code, I thought that it's better to keep useless information than remove useful information, so I rejected it and edited it to format the unformatted code myself. However, I would have preferred to reject it as "clearly conflicts with the author's intent" than "does not correct the critical issues with the post", because it does correct the critical issues with the post, it just causes other issues which may be even worse.

Here is another example of a suggested edit which I have never actually reviewed, but I think it's a good example to illustrate my point. This edit suggestion should clearly be rejected as vandalism. However, I think that the the indentation in the code is completely useless and should be removed (removing useless indentation is actually encouraged). If I would have got this suggested edit I would have liked to reject and edit with the reason "vandalism", which is currently impossible.

I therefore think that when rejecting and editing, the user who rejects and edits should have a choice of a reason for rejecting it, instead of always having the same reason. These reasons should be the same as those for simply rejecting an edit, possibly changing the formulation a bit or including the reason that's currently always chosen.

  • 10
    I think you overestimate the odds that the editor will even look at the rejection message, let alone care.
    – Servy
    Commented Mar 1, 2017 at 18:30
  • 3
    @Servy Maybe most of them don't, but some of them do. On Super User where I don't yet have the privilege to edit, I always look at the rejection message (in the rare cases where my edit gets rejected) and when my edit gets rejected and edited, I would really like to see the reason why the user chose reject and edit instead of for example improve. Commented Mar 1, 2017 at 18:36
  • @DonaldDuck - Best to come into Root Access to discuss those specific rejections. A single sentence isn't going to be able to explain the reason most rejections happen. I personally would not take the time to explain my rejection outside of the pre-offered reasons.
    – Ramhound
    Commented Mar 1, 2017 at 23:07