I recently got curious about whats been going on with my edits, and thanks to: How can I see all my rejected edits?

I can see whats been happening. In particular, I can see: https://stackoverflow.com/review/suggested-edits/1155043

Here my edit is pretty basic: I've tried the code, it didn't work, I realised that "arrayWithObjects must be nil terminated" and I've gone ahead and edited the answer. There were no comments about the question/answer to cloud the issue. I'm sure my edit was useful and correct, and the rejecting editors have got it wrong.

Note the official documentation: https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSArray_Class/NSArray.html and especially the bit:

A comma-separated list of objects ending with nil.

I don't particularly care about that, but I thought that this might be a good opportunity for SO to do some useful self review.

I notice that the rejecting editors have a pretty high rejection rate. In particular, one editor has "approved 283 edit suggestions and rejected 262 edit suggestions", another
"approved 191 edit suggestions and rejected 141 edit suggestions" and the other "approved 621 edit suggestions and rejected 358 edit suggestions".

I'm not sure what the payoff would be for making numerous edit rejects(?) Perhaps camouflage for some naughtiness(?) Anyhow, anyone know whats up with this?

I've had a quick look at: Is anyone monitoring people rejecting good edits or approving bad ones? BTW.

  • 3
    Why the down votes? Please explain. – iPadDeveloper2011 May 23 '13 at 4:24
  • 1
    Just to be clear, I am not whinging about my rejected edit. I don't care about that at all. I put this up because I think it is very clear that my edit was good, and this could be a good "test case" for SO to examine its procedures. – iPadDeveloper2011 May 23 '13 at 4:28
  • 1
    another down vote with no explanation. Quite annoying. Is that helpful I wonder? – iPadDeveloper2011 May 23 '13 at 4:43
  • 5
    meta.stackoverflow.com/faq#vote-differences. In particular, I'll bet folks are disagreeing with the general allegations of bad faith you're making. – Michael Petrotta May 23 '13 at 4:45
  • Have you read meta.stackexchange.com/q/164448/172431? I think the accepted answer is a commonly held point of view. – madth3 May 23 '13 at 4:56
  • Fixed it, please verify it now, I'm not an obj-c guy. – Lance Roberts May 23 '13 at 5:01
  • Pointing out that the highest rejection rate (in my question) is ~92%. SURELY something is up with that!? Surely the majority of edits are well motivated and improve answers(?!) – iPadDeveloper2011 May 23 '13 at 5:08
  • @Lance. Thanks for that. I see you missed one ,nil (in the first arrayWithObjects), as did I in my edit! – iPadDeveloper2011 May 23 '13 at 5:12
  • @iPadDeveloper2011, ok, got it, check me. – Lance Roberts May 23 '13 at 5:13
  • Where do you see 92%? – Michael Petrotta May 23 '13 at 5:19
  • 1
    @madth3 Yes, I did read meta.stackexchange.com/questions/164448/… (when people started down voting this question). However I think my edit did "keep the integrity of an answer intact." I just fixed a bug in the answer. Despite apparent disagreement here, I still think my edit was pretty clearly a useful one and should quite clearly have been accepted, if good precesses were followed. – iPadDeveloper2011 May 23 '13 at 5:21
  • meta.stackexchange.com/questions/181327/… - don't change code in suggested edits. Reviewers aren't supposed to know all the languages out there. – Mat May 23 '13 at 5:21
  • 1
    The thing is "minor". Fix a stupid typo like an obviously misspelled variable name is ok. Changing semantics isn't. Adding that nul changes semantics. – Mat May 23 '13 at 5:47
  • 1
    @iPadDeveloper2011: The correct response to an answer with incorrect code is an answer with correct code. I realize there's a great temptation to fix bugs in the code of an answer, but that's not the approach you should take; rather, improve the quality of the question/answer, and if you feel that the answer is wrong, post your own. – Makoto May 23 '13 at 6:05
  • 1
    @Makoto. The problem with the process is that everyones time is wasted. I find your attitude somewhat appalling! A reviewer, not understanding the code, should reject because other reviewers might know even less and accept an incorrect edit!!?? – iPadDeveloper2011 May 23 '13 at 23:39

Frankly, I'm concerned that two out of the five votes were in favor of this edit rather than against it.

So, I take the "edits won't change the meaning of a post" doctrine when editing/approving edits. Why this particular one was rejected (and should've been, in all honesty) was twofold:

  • Your edit changed the meaning/semantics of the answer in a way that could have been addressed with a comment, or a more up-to-date answer, and
  • Your edit was considerably minor. There was only a few things added, and the noise from the "edit" dialog wouldn't have been necessary (we can place that sort of thing in the "reason for editing" box).

As for rejection rate, as of this writing, I've approved a paltry 270 edits. I've rejected 364. Yes, the ratio considerably high, but I hold edits to high standards. Is there a payoff? Not in the form of any gamification, but I feel that questions that need editing are getting their just attention, and that poor edits aren't reducing the usability of questions or answers.

|improve this answer|||||
  • Pah! You can't have it both ways! If my edit changed the meaning/semantics of the answer, it wasn't minor, and vice versa. The truth is I made minor changes that could save people major headaches (debugging their code). I think that is pretty much the entire point of SO. Also, pah! I could have made a comment, or added an answer, but I didn't. Reviewers should not expect SO users to be familiar with nuances and vagaries of SO. The question reviewers should be asking themselves is "does the edit improve the answer?" If you cannot be sure the answer is "NO", you should not reject. – iPadDeveloper2011 May 23 '13 at 6:11
  • In future, I will post new answers or comments rather than change code (now that I am familiar with this weakness in the SO system). However you weaken SO by rejecting similar edits by uninitiated users. – iPadDeveloper2011 May 23 '13 at 6:15
  • 2
    @iPadDeveloper2011 Changing code in a suggested edit is usually a bad idea. Adding whitespace is fine, but change the code? This requires that the reviewer knows that this edit is correct. Does an edit improve the post is not a valid reason to accept a suggested edit. In fact, I (and many others) reject suggested edits as too minor that only fix a spelling mistake while keeping 5 others there. There is nothing wrong with a rejected suggested edit. And IMHO there are too many accepted edits that should be rejected (and I even rollback the worst accepted edits that I see). – Johannes Kuhn May 23 '13 at 8:00
  • @Johannes. Perhaps I should say "significantly improves". Certainly fixing a bug in supplied code is a significant improvement. I understand that there may be some users who attempt to manipulate the system by making frequent (unnecessary) edits, which may be the sort of thing you are alluding to. I do think it is very poor form if reviewers (on a programming forum) are rejecting edits that make improvements to code on the basis that they do not understand the code. – iPadDeveloper2011 May 23 '13 at 8:50
  • 2
    @iPadDeveloper2011 I'd reject your edit for the following reason: Too minor: While you add a nil to one of the arrayWithObjects, you don't do that on the other (why?), therefore not fixing everything (that can be spotted easily). I hate the "edit: xyz" lines. There is a revision history for exact this purpose. I'd had to improve your suggested edit, remove the edit and adding the other nil too. But because I'm not familiar with Objective-C, I don't. Too summarize: his was not a good suggested edit. It could probably make the answer better, but not substantive. – Johannes Kuhn May 23 '13 at 11:04
  • @JohannesKuhn. Although my edit is not as clear cut a test case as I would like, I still submit that it is a "good edit" because it removed a bug in the answer (and gave very good clues about the other bug). The best outcome of a review would have been the improved answer (with nils, and no edit comment) we now have. Although your reasons for rejecting the edit may be valid, my strong impression from this discussion is that they were not the reasons why the edit was rejected. It was rejected largely for the sin of "editing the code in the answer". – iPadDeveloper2011 May 23 '13 at 22:50
  • @JohannesKuhn: I wouldn't reject this for being too minor, but I would reject it for being invalid. Changing code in any way within an answer invalidates the answer, but doesn't make the edit minor, per se. – Makoto May 23 '13 at 22:51
  • 2
    @iPadDeveloper2011: No, it's not a good edit. The "reject for invalid edit" reason spells out that the edit was, "...incorrect or an attempt to reply to or comment on the existing post." Regardless of the correctness of the new code, you were replying/commenting on the existing post in a manner that changed the semantics/meaning of the answer altogether. Don't use your edits like that. Answer the question yourself if you think another answer is wrong. – Makoto May 23 '13 at 22:53
  • I think people are trying to pick holes in my edit in an attempt to justify the unjustifiable: the practice of rejecting edits simply because code was edited and "reviewers can't be expected to understand code." Lets face facts: that is an ugly, ugly monstrously bad process. Revealing that is the payoff from this discussion. – iPadDeveloper2011 May 23 '13 at 22:59
  • 1
    At what point did we say that there was a misunderstanding of the code? I can only recall stating that the semantics of the code were changed in an invalid fashion, and that the edit was invalidated due to that. That is all I'm arguing. I maintain, and I will remain absolute on this, that if you feel that the code in an answer is wrong, then post an answer with the correct code. – Makoto May 23 '13 at 23:03
  • @Makoto. Fixing bugs in the answer doesn't change the meaning of the answer. I was happy with the answer, it helped me. There were just some problems with it. I thought the original answerer deserved the credit, and posting a similar answer would look like a rip-off. Also, there is little point in telling me "not to use my edits like that". Naturally I won't as I now understand the finer nuances of SO in this respect. However that doesn't make this bad process correct, or useful. – iPadDeveloper2011 May 23 '13 at 23:06
  • @Makoto. Again, yes, I understand that is the best way to interact with SO now, as it stands. I have been educated by this discussion. However the bad process remains. – iPadDeveloper2011 May 23 '13 at 23:08
  • 1
    Now I see the disconnect. You view the process of editing questions/answers as fixing bugs. That's not correct - that's what one does with pet projects :). The idea is to preserve existing knowledge, while cleaning up grammatical errors - misspellings, poor sentence flow, structure, and formatting. All of these greatly help improve the clarity of the post without changing any of the original intent or original syntax. – Makoto May 23 '13 at 23:10
  • @Makoto. We have a different view. Its all about the code. From stackoverflow.com/about "Use edits to fix mistakes, improve formatting, or clarify the meaning of a post." I believe the original intent of the answer was to provide a correct and helpful answer to the problem. – iPadDeveloper2011 May 23 '13 at 23:34

The edit you made to the code may or may not have been good. I don't work in Objective-C, so I can't say. But the edit comment:

Edit: arrayWithObjects must be nil terminated.

...doesn't add anything to the answer, and shouldn't be there (Lance's shouldn't have been in there either). The edit comment by itself (which you added too, good) is enough.

An edit like that should either be rejected or (better!) edited to remove the comment.

As for the latter half of your question, I salute those who care enough to reject edits they don't feel are appropriate. My accept/reject ratio when reviewing is about 1.8 to 1, and that feels about right to me. It's certainly not "camouflage for some naughtiness". Though I like that phrase.

|improve this answer|||||
  • Yeah, I just put that "Edit:..." bit in for consistency with what was already in the answer (from the previous accepted edit by Lance, which the editor did not "care enough" about to correct). Whatever you think about that however, the code in the answer after my edit was correct. Before my edit, it was not correct (and it is not correct now). Surely it is irresponsible to reject an edit that corrects buggy code in an answer on the basis of disagreeing with an added note. – iPadDeveloper2011 May 23 '13 at 4:37
  • @iPadDeveloper2011, like I said, editing to remove the comment would have been appropriate. I would have skipped myself, since I couldn't judge the correctness of the code. But there's a higher bar for suggested edits on Stack Overflow than "normal" edits. As a former dev said, "Processing edit suggestions is not a free process, it cost eyes, distraction and time. We want quality in the queue, so high standards is a good first step." – Michael Petrotta May 23 '13 at 4:38
  • 1
    I submit that, because my edit corrected a bug in the code (and did little else), it (significantly) improved the answer, and so should be accepted (by policy). I do agree that the best review would have been to accept the edit, then remove the comment. – iPadDeveloper2011 May 23 '13 at 4:50
  • 1
    I think SO users care about correct code, that will work. A short answer, that is to the point, and contains correct code, is a high quality answer, regardless if it contains inappropriate comments about the edit. (I note at that point I did not understand SO editing process, so was just copying the previous accepted edit). Those comments do not significantly impact on the correctness or usefulness of the (edited) answer. – iPadDeveloper2011 May 23 '13 at 4:58
  • Leave a comment to point out the issue. Changing code in a suggested edit should pretty much always be rejected. Reviewers can't be expected to know all the details and subtleties of all the languages and frameworks out there. – Mat May 23 '13 at 5:23
  • 1
    @Mat, I usually skip those suggested edits if I can't be pretty sure that the code is good. – Lance Roberts May 23 '13 at 5:24
  • @Lance, Mat. I think there are pretty clearly 2 camps here, as expressed in your comments. I also think the approach Lance suggests is the best one for SO. – iPadDeveloper2011 May 23 '13 at 6:22
  • "Camouflage for some naughtiness"... think I can use that to get my wife to spend some time camping? – Andrew Barber May 24 '13 at 3:39

For many it's easier to reject than just improve. Posts that can be improved, should be, and if the original edit didn't help, you can uncheck the helpful box.

I've edited the answer now.

The best way to avoid the problem in the future is to get 2000 rep so you don't have to make suggested edits.

|improve this answer|||||
  • 4
    "The best way to avoid the problem in the future is to get 2000 rep so you don't have to make suggested edits." Could you tell me why I get chills reading this sentence? Because I don't see this rejected edit as a "problem". – Makoto May 23 '13 at 5:14
  • 1
    @Makoto, It should have been improved by taking out all the "EDIT" text. – Lance Roberts May 23 '13 at 5:14
  • I don't disagree at all - that'd be a more substantial edit. But that's not what I'm hung up on. I'd love to know what "problem" you're referring to in terms of this edit, though. – Makoto May 23 '13 at 5:16
  • @Makoto, the "problem" of having your edit rejected. Sure it's relative, but it was obviously a problem for him. – Lance Roberts May 23 '13 at 5:17
  • I think there is a problem if edits that improve answers are rejected. Procedures that tend to cause this to happen are a problem. SO is useful and successful largely because it makes it easy for people to post useful,helpful content. I think there is a principle here that you shouldn't mess with. I won't be caught out like this in future, but others will... Reviewers are mistaken if they believe they are improving SO by rejecting edits that improve answers. It should be the main aim of reviewers to avoid doing this. – iPadDeveloper2011 May 23 '13 at 6:32
  • @iPadDeveloper2011: To your point...an invalid edit that is rejected is just as helpful as a solid edit which is accepted. Reviewing the quality of posts does help the community, in a very big way - we preserve the original knowledge, while occasionally fixing up one or two grammatical mistakes. That's the overarching thrust of the edit system. – Makoto May 23 '13 at 22:55
  • @Makoto. Yes, but what to do about the big "grey area" between "clearly bad" and "clearly good." I submit that if an edit falls into your "grey area" because "you don't understand" (the code or whatever), rejecting the edit cannot be justified. Also, surely we must believe that the vast majority of edits are "good" and "well intentioned" and "improve the answer" and so the vast majority of them should be accepted (if not, something is seriously wrong with the system). – iPadDeveloper2011 May 24 '13 at 0:12
  • @LanceRoberts I find this answer, particularly the last sentence, highly worrisome. The concept is that once you have 2000 rep you will have had enough experience on the site to know what type of edits are acceptable and what are not, and that if your edits did need to be reviewed they would (largely) be accepted. It does not mean that you no longer need to follow the guidelines of the site. Understanding the guidelines for how edits should be suggested is important because those expectations stand even when you reach 2000 rep. This post is encouraging people to violate those guidelines. – Servy May 24 '13 at 3:28
  • 1
    @iPadDeveloper2011 "surely we must believe that the vast majority of edits are "good" and "well intentioned" and "improve the answer"" No, we must not. I wish this were true, but alas it is only a tiny majority of edits that are suggested are "good". I think you'll find that the majority of the editors making valuable edits are regular users who have been around for long enough to earn enough reputation to not need to be reviewed. Very high quality editors tend to get the appropriate rep particularly quickly. – Servy May 24 '13 at 3:31

From SO about page

Our goal is to have the best answers to every question, so if you see questions or answers that can be improved, you can edit them.

There are no instructions about not editing code. This being the case, reviewers should be accommodating to edits that appear to improve answers. In particular, it should be a prime consideration of reviewers to avoid unnecessarily rejecting edits that improve answers. If you don't understand the code, leave it for someone else to review!

Rejecting edits that improve answers hurts SO on 2 fronts:

  1. It reduces the quality of content on the site and, importantly,

  2. It discourages users from making edits.

There may be weaknesses in the SO system that require redress here. I guess it is simply [easier/safer/more profitable in some way] for a reviewer to reject an edit they are unsure about, than:

  1. leave it for another reviewer;
  2. accept it and risk censure, or;
  3. to improve on the edit.

There currently seems to be a culture whereby reviewers feel they are justified in rejecting an edit simply because code is changed see this, for example. I believe this conflicts with the SO goal, as stated in the about page.

|improve this answer|||||
  • Hey, here is an idea. How about a "Would be more suitable as an alternate answer." Option for reviewers? If an edit were rejected with this as the majority reason, the edit could then be automatically posted as an alternate answer (and the editor notified accordingly). In that way, SO would not loose potentially highly useful edits, and reviewers who didn't understand the code would have a more constructive "out". – iPadDeveloper2011 May 23 '13 at 8:55
  • You are more than welcome to propose that feature if you would like. That said, I think you'll find that it's simply not such a common situation that it warrants the amount of dev time/effort that would be needed. It's much more effective to simply inform users about when they should edit and when they should post a new answer. Now that you've learned what is appropriate you will (hopefully) not be submitting edits that should be new answers anymore; you'll know that you should simply comment or post a new answer, and no content will be lost. – Servy May 24 '13 at 3:34
  • @Servy. Perhaps I will simply not make any further contributions to SO. That would be even simpler. If code edits are going to be routinely rejected, end users should definitely be informed about that (eg. in how to edit info. and elsewhere) Failing to do so, and rejecting such edits out of hand is such a snub! – iPadDeveloper2011 May 24 '13 at 4:49
  • I've replied to you in several comments about this issue, but again I see the disconnect. There is a difference between improving the quality of the posts, and improving the quality of the code within the posts. I've belabored the point about exclusively editing the code, or "correcting" the code - if it's incorrect, the right response is an answer with the correct code. When you can see and agree with that, then your contributions will be warmly and openly welcomed by the community. – Makoto May 24 '13 at 6:13

You must log in to answer this question.

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