6

A couple of months back, I came across a answer which had a typo in it: How to show that a monad is a functor and an applicative functor?. I made this edit initially: https://stackoverflow.com/review/suggested-edits/3743582. It was rejected, and the only reason that made sense was that it was too minor. I don't agree with this at all because it is a typo that does not make sense.

Just today I stumbled upon the same answer that hadn't been updated so I made this edit: https://stackoverflow.com/review/suggested-edits/4350723. It fixes both the code and the explanation. These are both typos.

I can only assume that the speed of rejection in the second case is due to it editing code in an answer. I say this because after searching for reasons why other edits were rejected, it looks like fixing broken code is frowned upon. However, according to this community wiki: https://meta.stackexchange.com/questions/200336/when-should-i-make-edits-to-code this edit wasn't violating any dogmatic ideas.

I don't understand why both of my edits were rejected. The answer has two clear typos which need to be fixed. There is no explanation of what is wrong with my suggested edits, nor is there any suggestion as to how to improve them so they could be approved. If it was because of my poor edit summary (as it states in the community wiki), then shouldn't the reviewer hit the Skip button (as it also states in the community wiki)?

Can anyone provide some insight into these decisions? I really just want to know when it's acceptable to edit an answer.

Improve this question
6
  • 4
    While I'm sure you fixed a serious error, trying to correct logical or code errors on the OP's part through suggested edits is discouraged because of the many potential problems that come with it - we may not know for sure what the OP intended, a code change may introduce further problems or unintended consequences, etc. A comment to the OP asking to fix the problem might work better, or if it's big enough an error, an answer of your own. (That doesn't seem to be the case here though.)
    – Pekka
    Mar 16, 2014 at 15:12
  • 1
    The code change was exactly what was intended by the author. Look at the context of the change in the scope of the entire answer, not just the brief bit where the code was changed. @ehird is showing how to desugar that which was written directly above. It is not a semantic error, or some such, it is exactly a typo and should be fixed.
    – joneshf
    Mar 16, 2014 at 15:30
  • I'm sure what you say is correct. But edit reviewing is done by people who may not have the knowledge necessary to grasp this. It looks like a radical change to someone not familiar with that exact subject matter. That's by design - else there wouldn't be enough reviewers for each tag.
    – Pekka
    Mar 16, 2014 at 15:35
  • 1
    @Pëkka If they don't have the knowledge, they should skip, not reject.
    – Gilles 'SO- stop being evil'
    Mar 16, 2014 at 15:36
  • sigh then shouldn't those people doing the reviewing not attempt to approve or reject an edit? Not mad at you @Pëkka just frustrated with this system.
    – joneshf
    Mar 16, 2014 at 15:37
  • 1
    Yeah, I see the problem. I agree the ideal situation would be for everyone just to skip and wait for someone who knows the subject matter... but the standing rule, as far as I know, for what looks like a radical change is that they be rejected and I can kinda see how even a responsible reviewer would see this as one, even if they don't know the tag in question. Hmmm.
    – Pekka
    Mar 16, 2014 at 15:39

2 Answers 2

Reset to default
7

There are official rules regarding editing:

When should I edit posts? (…)

  • To correct minor mistakes or add updates as the post ages

Using the wrong name in an otherwise correct explanation is definitely a minor mistake.

Unfortunately, Stack Overflow is plagued by reviewers who reject edits they don't understand instead of skipping them, or who reject edits that make things correct in blatant contradiction with the rules. (And conversely, there are also many reviewers who approve anything in sight. Suggested edit review on Stack Overflow is a mess. Fortunately other Stack Exchange sites do a lot better.)

Improve this answer
8
  • 4
    I don't think this is a robo-reviewer issue. I might have (reluctantly) rejected the edit as well, assuming a radical change. (The review system as it is currently does not require deep technical knowledge in the tags you are reviewing stuff in.) But I agree the outcome was not satisfactory here - perhaps another argument in favour of limiting reviewing to tags you know.
    – Pekka
    Mar 16, 2014 at 15:41
  • 1
    @Pëkka It was obvious that this edit required some knowledge of Haskell to review. Anyone who doesn't know Haskell should skip, not reject. I don't think limiting reviews to tags is a solution though — a large majority of suggestions don't require any competence, and on sites other than SO or smaller tags it wouldn't work out. The real problem is reviewers who don't know what they should be doing (such as anybody who upvoted Jeroen's answer here which directly contradicts the official rules), and it's a self-perpetuating problem.
    – Gilles 'SO- stop being evil'
    Mar 16, 2014 at 15:44
  • I would have skipped in this case but in cases where I'd be replacing one whole symbol with another and I'd beleive myself to be 100% correct, I'd still abstain and put a comment instead.
    – Louis
    Mar 16, 2014 at 15:48
  • 1
    @Louis If you're sure about what you're doing, you should edit. If you're not sure, you should comment.
    – Gilles 'SO- stop being evil'
    Mar 16, 2014 at 15:50
  • FWIW, I upvoted @Jeroen Vannevel's answer not because I agree with it, but because it actually explains the mindset of the reviewers. I will not accept it, because I don't feel it's an acceptable answer to the reason it was rejected. And from the discussion here, yours is the most acceptable answer there can be. It was rejected because people don't know what they're doing. Thank you for confirming my suspicions.
    – joneshf
    Mar 16, 2014 at 15:55
  • @joneshf "people don't know what they're doing" is probably too harsh. Nevertheless, your suggestions were correct, I made the edit myself. Thanks for bringing it to attention.
    – Daniel Fischer
    Mar 17, 2014 at 1:07
  • @Daniel, thanks, you beat me to it. Unfortunately this comes up far too often (it seems like 1-2 times per week we get a post on meta about it, meaning it is likely happening far more and the user gives up trying). The only thing we can do is to make the edits as 2k+ users when we see these questions pop up, and help make the site a better place. I really wish we could get reviewers to pay attention though...
    – jmac
    Mar 17, 2014 at 4:04
  • @DanielFischer you're correct, that was not the right thing to say. Thank you for making the edit.
    – joneshf
    Mar 17, 2014 at 15:20
7

You are trying to change the answer, not necessarily improve it.

I don't know anything about what is being said there but if you feel like the content is wrong (this is not a simple typo) then you should leave a comment for the owner so he can decide whether a change is appropriate or not.

A typo is 'hella' instead of 'hello', it is not 'Monad' instead of 'Applicative'.

Note that you didn't fix a straightforward code typo: you changed the explanation that came with the code.

Improve this answer
8
  • Thank you for this response, it explains much more what's going on. It seems the lack of understanding the material is causing people to think that this edit is doing too much. If it helps, picture a hierarchy: Functor \supset Applicative \supset Monad. The answer states, "you can derive a Functor and Monad from any Monad". The intended meaning was, "you can derive a Functor and Applicative from any Monad". Also, perhaps typo was the wrong word. In any case, thanks for the explanation!
    – joneshf
    Mar 16, 2014 at 15:23
  • Also, thanks for the explanation for the second rejection. In this case, would an edit to fix only the code be acceptable, or still out of the scope?
    – joneshf
    Mar 16, 2014 at 15:24
  • To be honest you really shouldn't touch code. Higher rep users can get better away with it because they don't have to pass the review queue but it's usually something you do not want to involve yourself in. I would suggest to just leave a comment and avoid any drama.
    – Jeroen Vannevel
    Mar 16, 2014 at 15:32
  • 3
    There's nothing wrong with touching code or correcting explanations. Please read the official rules — “correct minor mistakes” is encouraged. @joneshf I'm sorry about your edits being rejected, unfortunately there are many suggested edit reviewers on Stack Overflow who reject edits they don't understand instead of skipping them like they should.
    – Gilles 'SO- stop being evil'
    Mar 16, 2014 at 15:36
  • 1
    @Gilles changing code is generally discouraged, though. When should I make edits to code? (But I agree this wasn't the case here)
    – Pekka
    Mar 16, 2014 at 16:26
  • 3
    @Pëkka No, it's changing code in questions (because it often leads to inadvertently correcting the mistake that the question was about). At the very beginning of the answer you cite: “Reviewing Code Edits: When in doubt, click 'Skip'. "Learn to love that Skip button."”
    – Gilles 'SO- stop being evil'
    Mar 16, 2014 at 16:32
  • 2
    Ah, fair enough. So editing code in answers is indeed encouraged, good to know. I stand corrected.
    – Pekka
    Mar 16, 2014 at 16:46
  • 2
    This is exactly the sort of edit that When should I make edits to code? was created for. Good edit, correcting a simple mistake and making a better quality answer, but rejected by reviewers who didn't even bother to think about it for 15 seconds before clicking reject.
    – jmac
    Mar 17, 2014 at 4:06

You must log in to answer this question.

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