11

Last year, after complaints that it sounded too hostile, the suggested edit rejection reason for "no improvement whatsoever" was changed — to replace "fails to make" with "does not make". It now reads:

This edit does not make the post even a little bit easier to read, easier to find, more accurate or more accessible. Changes are either completely superfluous or actively harm readability.

This still seems unnecessarily harsh to me.

Some alternatives:

  1. This edit doesn't make the post easier to read, easier to find, more accurate or more accessible. Changes are either superfluous or harm readability.

    (Took out "even a little bit", and "completely", as they unnecessarily put an emphasis on the magnitude of the edit's failing.)

  2. This edit doesn't make the post easier to read, easier to find, more accurate or more accessible.

    (Removed the second sentence because it just repeats what the first sentence says.)

4
  • It is meant to be harsh. Users who get that message should be aware that they should improve their edits. They are wasting review effort.
    – rene Mod
    Commented Dec 9, 2015 at 22:38
  • @rene Mods at skeptics are using it in situations where they don't want to be harsh, though, because they don't have any other option. They said the only reason they used this is because "it's part of the system". chat.stackexchange.com/transcript/message/26043762#26043762
    – user311000
    Commented Dec 9, 2015 at 22:39
  • It is improved a year ago and Shog9 answer basically re-iterates my first comment but then much better and friendly worded. The message is the same.
    – rene Mod
    Commented Dec 9, 2015 at 22:44
  • 1
    @rene The mods at skeptics are not aware that this was supposed to be harsh: chat.stackexchange.com/transcript/message/26045628#26045628
    – user311000
    Commented Dec 9, 2015 at 22:49

1 Answer 1

10

I think the real problem is that these canned edit rejection messages are written for two completely different audiences, and the resulting compromises end up being good for nobody:

  • On one hand, the messages serve as guidance to reviewers on which reason to pick. From this perspective, the harsh wording of "no improvement whatsoever" is perfectly understandable — it's trying to get reviewers to stop overusing this rejection reason, like they did with the old "too minor" wording.

  • On the other hand, the exact same message is also shown to new editors when they go and see why their edit was rejected. In this context, the wording — deliberately designed to be strong and to belabor the point, so that reviewers would get it — comes across as incredibly harsh and gratuitously offensive, especially since there's no clear indication that this is a canned message, and that the reviewer didn't just spend several minutes typing and polishing that shiny ball of condensed condescension.

So, what can we do to fix this?

Obviously, we can keep tweaking the wording of the message to arrive at a better compromise, but it's never going to serve both of these two conflicting goals well. Instead, we should do something to separate those two purposes better. Here's a couple of ideas:

  • Add a "(canned message)" label to the canned messages when they're shown to editors. Yeah, that'll look kind of ugly, but it's probably the simplest fix. And we already do something like that for the automated comments from VLQ / NAA review, so at least there's precedent for it.

  • Create a help page explaining each of the standard rejection reasons (and more generally, how to suggest good edits) in more detail, and include a link in the messages to that page. Title it something like "Why was my suggested edit rejected?". The general parts could probably be based on the current edit privilege description page, but it should also provide more specific guidance on what each of the canned rejection messages means, and how and when it should be used. In any case, just the presence of the link should hopefully serve as a cue to editors that those rejection messages are boilerplate.

  • Split the messages into two parts: one that is shown in the review results, and is aimed to guide the editor towards improving their edits, and a second one that is only shown to reviewers in the "Reject" popup, and provides more specific guidance on how and when to use that reason.

    This may end up cluttering up the review popup a bit, since we probably do want to show both messages there. Hopefully, though, splitting the messages in two would also let both halves be shortened somewhat, since they no longer need to make so many compromises in wording. (It could also be a possibility to hide one of the messages initially, and only show it for the currently selected reject reason.)

    For example, here's how I might split the "no improvement" reason that's been the focus of the discussion here:

    "This edit does not make the post any easier to read, easier to find or more accurate."

    Only reject edits that make no improvement whatsoever or that actively harm readability. Minor edits that do improve the post in some way should not be rejected.

Of course, these suggestions are neither exhaustive, nor necessarily mutually exclusive.

2
  • 2
    Ps. I originally posted this as an answer to this earlier feature-request about the same thing (now marked as status-completed after a trivial wording change), mainly because I didn't realize that request was from last year. Now that this request is no longer closed as a duplicate of the old one, I've deleted my answer there, and reposted it here. Commented Dec 24, 2015 at 7:43
  • We definitely want to show the exact text (very likely in quotes or otherwise formatted distinctly) so reviewers are under no illusions as to exactly what they're saying. (I personally use userscripts and userstyles to collapse unselected dialog options down to titles, so I'd favor that as well, but I have no very serious objections to making the base consistent with other uses and leaving it to customizations to make it more compact.) Commented Dec 24, 2015 at 7:49

You must log in to answer this question.