2

Why was my edit rejected? All three reviewers said:

This edit is incorrect or an attempt to reply to or comment on the existing post.

Really? Come on! I am nearly at the point of abandoning "edit" all together. My new edit-defensive strategy may soon become: Copy the original answer's markdown and paste into a new answer with my corrections. I would view this as somewhat harmful to this website and its culture, but it would offer greater protection to my edit and time invested.

There are exactly two lines changed in this edit.

  1. Remove call to method which does not exist: impl.getDOMImplementation() -> impl As the original code stands, it will not compile.
  2. Remove duplicate line: hints.put(ImageTranscoder.KEY_DOCUMENT_ELEMENT_NAMESPACE_URI,SVGConstants.SVG_NAMESPACE_URI);

That really rustled my jimmies!

Improve this question
14
  • 5
    Rule of thumb: if the code in an answer wrong, comment and perhaps downvote. Reviewers of suggested edits cannot be expected to review your edit on technical grounds.
    – Martijn Pieters
    Aug 8, 2013 at 14:54
  • 24
    Another rule of thumb: Don't ever change code in a question, you could be destroying evidence of where the question asker went wrong.
    – Martijn Pieters
    Aug 8, 2013 at 14:55
  • 6
    Your new edit-defensive strategy is exactly what you should do. Suggested edits don't turn wrong answers into right ones.
    – Kate Gregory
    Aug 8, 2013 at 15:00
  • 1
    For the sake of balance though, there are those with a somewhat more lenient attitude towards code edits in answers: meta.stackexchange.com/a/190641/161198
    – Bart
    Aug 8, 2013 at 15:05
  • @KateGregory: "Suggested edits don't turn wrong answers into right ones." I am confused. In this case: Does my suggested edit not turn this answer into a right one?
    – kevinarpe
    Aug 8, 2013 at 15:17
  • 2
    @kevinarpe it is trying to, and that's why it's being rejected
    – Kate Gregory
    Aug 8, 2013 at 15:27
  • 6
    @MartijnPieters No, this is an edit in an answer, which is a completely different case.
    – Gilles 'SO- stop being evil'
    Aug 8, 2013 at 15:30
  • 2
    Please give this question a more descriptive title.
    – Jeremy
    Aug 9, 2013 at 0:50
  • @Arjan: No, I did not mistake it for a question; suggested edit reviewers cannot be expected to review the edit on it's technical grounds.
    – Martijn Pieters
    Aug 9, 2013 at 14:27
  • I meant your "Another rule of thumb", @Martijn. It's totally unrelated, I'd say.
    – Arjan
    Aug 9, 2013 at 14:28
  • @Arjan you're right, my comment was misleading
    – ಠ_ಠ
    Aug 9, 2013 at 14:28
  • @Arjan: It is related to my first comment; talking about editing code in general.
    – Martijn Pieters
    Aug 9, 2013 at 14:32
  • Very well, @Martijn. Both ಠ_ಠ (meanwhile deleted) and you fooled me into thinking it was an edit of a question, but once I followed the link I could no longer undo my comment upvote. I'm tempted to think I might not have been the only one, but no worries.
    – Arjan
    Aug 9, 2013 at 14:41
  • 4
    @MartijnPieters Your first comment is contrary to the core guidelines of Stack Exchange. If there's something wrong with the answer and you can fix it, you should edit it and not comment. Comments are not recommended for (…) suggesting corrections that don't fundamentally change the meaning of the post; instead, make or suggest an edit. When should I edit posts? … To correct minor mistakes. The author of the answer is notified of the edit, by the way.
    – Gilles 'SO- stop being evil'
    Aug 9, 2013 at 19:17

4 Answers 4

Reset to default
9

My new edit-defensive strategy may soon become: Copy the original answer's mark-down and paste into a new answer with my corrections.

That's a great thing to do when you come across an answer that is close, but has several important problems with its content. An alternative would be to comment on the post and have the author correct their own content.

Personally I usually wait to post a competing answer until the author either doesn't bother to correct the mistake, or explicitly tells me they think their solution is right and that my change would be wrong. That the author can make such a decision is exactly why such changes should not be made in an edit. At the end of the day the content of the post is credited to the author; they are responsible for it.

Note that if you do provide a competing answer based on an existing one it's important to attribute the content properly. Include something along the lines of, "Below is the solution provided here by Author, but with X and Y changed to account for Z".

Improve this answer
7
  • 7
    Why in the world would it be better to post a completely duplicate answer with one or two minor changes, as opposed to just fixing the original answer? This makes absolutely no sense to me, and stands in utter violation of the whole mission of Stack Exchange. Remember the part about collaborative editing and working like a wiki?
    – Cody Gray
    Aug 9, 2013 at 7:00
  • 5
    The comment and edit guidelines say that when there is a minor mistake in an answer, you should edit it and not comment. Comments are not recommended for (…) suggesting corrections that don't fundamentally change the meaning of the post; instead, make or suggest an edit. When should I edit posts? … To correct minor mistakes.
    – Gilles 'SO- stop being evil'
    Aug 9, 2013 at 7:50
  • 3
    @CodyGray Precisely because the change isn't minor. The change is rather significant. The fact that the change is significant is exactly why it should be posted as a different answer. The idea of collaborative editing is to improve a post while maintaining the intent/meaning/content of the original author. An edit that dramatically changes the meaning of a post should be rejected, which is why there's a rejection reason exactly for that. An edit should help make the OP's intentions and content shine without changing it. Obviously this is all completely different for a CW post.
    – Servy
    Aug 9, 2013 at 13:40
  • 4
    You think it was the person's intent to post code that didn't compile because of a call to a non-existent method? Or perhaps it was their intention to have a duplicate line of code? I don't know, I'm not seeing this as a major change.
    – Cody Gray
    Aug 9, 2013 at 13:55
  • @CodyGray Given that the person wrote out the method, I'd say that it was their intention to do something, yes, especially the added function. The duplicate line may or may not have been intentional, that's harder to say. As to what his intention was, I don't know enough about the subject to say, but it doesn't seem like he'd "accidentally" write out a function that doesn't exist when nothing needs to be done. If it doesn't exist it would seem much more likely that something needs to be there. Regardless, you should notify the author of the mistake and let them resolve it.
    – Servy
    Aug 9, 2013 at 14:00
  • 4
    @Servy But the change is minor. It does respect the intention of the author: evidently the author typed the code directly into the browser window, and he made a couple of minor mistakes. Furthermore, changing code that doesn't compile into change that does compile can only be an improvement. The author is notified and can review the change at his leisure.
    – Gilles 'SO- stop being evil'
    Aug 9, 2013 at 19:16
  • @Gilles "changing code that doesn't compile into change that does compile can only be an improvement" No, I reject that premise. What if the code doesn't actually work, even though it compiles? It can often be better for it to not compile at all, so as to make it clear that it isn't working, than to simply remove a large section of code entirely in order to get it to compile. Perhaps the OP intended to copy a line and then change it a bit, and forgot to make the change. Removing the dup removes that placeholder. If he mis-typed the name of the method removing it entirely isn't right.
    – Servy
    Aug 9, 2013 at 19:21
8

You aren't supposed to edit code in someone's question (or answer, really). The main reason being, your edit could (and in this case certainly would) cause the functionality to change, making it harder to diagnose the problem. Instead, you should mention that there is a duplicate line and that the method doesn't exist in a comment (or answer, if you think that's the root of the problem)

Improve this answer
6
  • 7
    This is all true for questions, but not for answers. Your rationale about "diagnosing the problem" isn't even applicable to answers. Answers shouldn't need their problems diagnosed, they should be complete and appropriate solutions to the problem. If they are missing something, or there has been a mistake made, that should be improved by an edit.
    – Cody Gray
    Aug 9, 2013 at 7:02
  • @CodyGray Fair enough. However, if there's something wrong with the answer, I feel it's better to tell the answerer, so that they understand their mistakes, rather than just changing it and not telling them why it was wrong. I guess it's not quite the same as the whole "diagnosing the problem" issue, but it's a similar situation.
    – StephenTG
    Aug 9, 2013 at 13:38
  • 2
    @StephenTG On the contrary, if there's something wrong with the answer and you can fix it, you should edit it and not comment. Comments are not recommended for (…) suggesting corrections that don't fundamentally change the meaning of the post; instead, make or suggest an edit. When should I edit posts? … To correct minor mistakes. The author of the answer is notified of the edit, by the way.
    – Gilles 'SO- stop being evil'
    Aug 9, 2013 at 19:13
  • 1
    @Gilles That's certainly a legitimate way of interpreting that, but the way I see it, fixing the code to make it actually work changes the fundamental meaning of the post. I see that recommendation as being intended to ward off comments about formatting or spelling. I wasn't sure if you got notifications of an edit or not, so I suppose that the answerer won't be unaware of your correction. However, they might still be unaware as to why you made the correction
    – StephenTG
    Aug 9, 2013 at 19:19
  • 3
    It is pretty obvious that the answerer made an unintended mistake (duplicate line and duplicate method call), so I don't think the suggested edit changes anything fundamental about the code or the post.
    – Old Checkmark
    Aug 9, 2013 at 19:21
  • 1
    @OldCheckmark Fair enough. Consider this answer more of my general stance on the issue rather than kevinarpe's specific situation.
    – StephenTG
    Aug 9, 2013 at 19:23
7

Sometimes reviewers make mistakes. That may well be what happened in this case. I don't know, I am not qualified to judge the veracity of your edit, as I am not a Java programmer nor do I know anything about the framework that is used by the code in the answer. As a result, I would have chosen to "Skip" while reviewing that edit, not "Reject".

If I were knowledgeable about the answer's domain, I would have made a decision regarding the veracity of your edit. If it were correct or otherwise an improvement over the original answer, I would have clicked "Accept". If it were incorrect or merely stylistic with no apparent practical benefit, I would have clicked "Reject" and typed a custom rejection reason that explained my rationale.

I have no idea if the people who reviewed and voted on your edit made the right call or not. I don't know if they're knowledgeable in the answer's domain, I don't know if they read and considered the suggested code improvement carefully, and I don't know enough to second-guess their decision for myself.

But I do know that this same type of mistake is commonly made. Consider this edit, proposed yesterday to one of my answers by the user Zurb while I was away. Three different people rejected this edit for the same reason that they rejected your suggested edit:

This edit is incorrect or an attempt to reply to or comment on the existing post.

But they were wrong. The edit was certainly not incorrect—it was the original answer that was incorrect. I bungled my closing braces (a common problem when writing code in a simple textbox, without auto-completion or syntax checking), and the resulting code was just straight up wrong. The base class method should always be called in this example, and it wasn't the way I had written the code. A simple fix, just rearrange the braces. I had also forgotten that the IntPtr type can't be directly compared to a bool, likely a result of spending more time working in C++ lately. The editor caught that as well, submitting a perfectly valid and appropriate fix: an explicit conversion to an integer.

Nor was the edit an "attempt to reply to or comment on the existing post". There are no "replies" to answers, just additional answers. And it would have been the height of insanity to post these corrections as a new answer. It would have plagiarized far too much of my work, and added nothing whatsoever to the question. It also would have left my answer in a poor state, demonstrating wrong code, which was especially bad considering that my answer had already been accepted by the asker.

Sure, I guess Zurb could have posted this as a comment to my answer. But why? Then I would have had to go through the typical parade of comment notifications in my inbox, find his comment, read and understand what he was saying, reevaluate my own code, and fix the problem myself. All for what? Certainly not because my answers are "off limits" to other people. That would contradict the FAQ, which says that the site is collaboratively edited, with the goal to make the content as useful and accurate as possible. I don't have the option of making my answers "off limits" to others even if I wanted to, and I certainly wouldn't want to, because that just makes more work for myself. It's not a homework assignment, I'm not learning anything by being forced to go back and fix my own bone-headed mistakes. I already know better, I just mistyped. No different than had eye mispelled a wod. (Please fix those if you see them, they make me look dumb.)

At least the system notifies me of when people have made an attempt to improve my contributions. That way, even if the editor doesn't get the credit, I still have a way to fix my mistakes and make the site a little bit better resource for everyone.

Improve this answer
7
  • Your example is dramatically different from the example in the OP. In your case it's clearly just a minor typo. Neither fixing it nor leaving it dramatically changes the quality of the answer. Additionally, fixing it isn't really changing the intent or meaning of your answer. Because of that, it's an appropriate edit that I would have approved. The suggestion of the OP is different by a matter of degree. It's not fixing a typo or changing the post to clearly be what the author intended; it's a significant semantic changing of the meaning of the answer.
    – Servy
    Aug 9, 2013 at 13:37
  • 3
    Leaving it would dramatically change the quality of the answer: it makes the sample code wrong! You only know that this was a typo because I told you it was. Otherwise, the same argument would apply: it radically changes the meaning of my answer. And it does, it changes when/how the base class method is called. That's a big deal. An important thing to get right. Which is why the fix was so important.
    – Cody Gray
    Aug 9, 2013 at 13:57
  • In your case someone can easily take a sample code snippet with a brace missing at the end, throw it into the compiler, see that a brace is missing, and just throw one in. It's such a common issue that it's just not hard to resolve. Yes, it improves the post to add it, but no it's not dramatically changing the meaning or intention of the post to do so. A typo (i.e. missing letter) in a variable name also make a code sample (usually) not compile, but fixing it still isn't really changing the meaning of the answer. This falls into that category.
    – Servy
    Aug 9, 2013 at 14:02
  • It wasn't missing, it was in the wrong place. Or that's the way I explained it, because I have inside information. Really, from the perspective of the reviewers, he moved a function call from one scope to another. The point is, it was objectively wrong and there was a revision suggested that fixed the problem.
    – Cody Gray
    Aug 9, 2013 at 14:04
  • Okay, that's correct. It doesn't change my argument though. It's still an error trivially indicated by the compiler, and your intention is still rather obvious to someone trying to use the code, unlike the case in the OP. Knowing that something is wrong is simple enough (for the first case, although even that isn't true about the second), but knowing what to do about it isn't. The author's intention isn't clear, so an editor deciding on their behalf as to how to address the problem isn't appropriate; the author should be doing that.
    – Servy
    Aug 9, 2013 at 14:07
  • 4
    Really? This is seriously blowing my mind. So like if you work on an open source project, you don't think anyone else can check in fixes to code that you've written? You think it's the obligation of future contributors to run blame and figure out who originally wrote the code, contact them, and get them to fix it themselves? For what purpose? Because they might have meant something else? Fine, if they did, they can go back and change it to better reflect what they meant. But in the meantime, the code works [better].
    – Cody Gray
    Aug 9, 2013 at 14:10
  • 2
    That's an entirely different situation that is in no way relevant to the current thread. In an open source project nobody owns anything; it's all just community code. On SO, when you post an answer is your answer. You are responsible for it's content, and you are accepting the consequences for it's correctness or incorrectness. (Unless the post is community wiki, which is the case where edits such as the OP's would be valid.)
    – Servy
    Aug 9, 2013 at 14:12
6

When your edits are going to be reviewed by others, you need to make it as easy as possible for reviewers to recognize that your edits are correct. Reviewers won't necessarily take the time to fully understand the original text and how your edits change it, especially if you're editing code. As the editor, it's your job to help the reviewers understand.

The comment in your edit is simply "fixed code." That's a lousy edit comment. How is anyone supposed to understand anything from that? The contents of the edit already show that you changed code, and it's assumed that any edits are going to fix things, so your edit comment really carries no information.

If you're removing the call to getDOMImplementation because there's no such method, then say so. If you're removing a duplicate line, then say so. You would have had a much better chance of having your edit accepted with an edit comment like this:

removed duplicate line. impl has no getDOMImplementation method; it's already the implementation.

I disagree that copying someone else's answer and then modifying it slightly is an appropriate thing to do. That's what editing is for.

Thank you for editing the answer you did. I'm sorry it didn't get approved. Please don't let this discourage you from contributing future improvements.

Improve this answer
4
  • 4
    +1 for mentioning about the lousy edit comment. If reviewers looked closer (and a descriptive edit comment would definitely help with that), it's not hard to see the duplicate line of code and the duplicate method call. I'm kinda concerned how strongly people are defending the reviewers.
    – Old Checkmark
    Aug 9, 2013 at 19:16
  • 2
    I strongly disagree that the editor should be made to leap through hoops to make changes that anyone who understands the language would be able to evaluate as a positive change. If you cannot determine if a change actually 'fixed code' then there is a skip button you can avail yourself of. It is a far more difficult task to fix syntax in an answer than it is to review the edit, so asking the editor to jump through hoops will disincentivize that sort of hard work. That makes SE a worse place.
    – jmac
    Oct 10, 2013 at 1:52
  • And yet that's the way things are, @Jmac. Do you have a suggestion for what to do about it?
    – Rob Kennedy
    Oct 10, 2013 at 2:47
  • Yeah, implement bounties for editors and give part of any bounty to the person (people) who accept or improve good edits. Alternatively, penalize bad edits somehow to create an incentive to skip ones you don't know (like penalizing wrong answers on a multi-choice test to discourage guessing).
    – jmac
    Oct 10, 2013 at 3:12

You must log in to answer this question.

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