Unable to improve answer because edit reviewers are rejecting for questionable reasons [duplicate]

Question

I've always had a hard time getting reviewers to approve my edits pending peer review. It's very often either "too trivial" or "too much change", with "should be a comment" thrown about here and there. How do I hit the silver lining?

Just today, in this post, I thought I would improve the accepted answer by adding some useful information that would help the next person. In the process, I also decided to improve the formatting a little bit:

Android code won't generate R.Java after cleaning

I suggested this edit first with the following comment:

improved formatting, add footnote about errors that can be ignored

Within seconds it was rejected 3:1, so I thought I'll try again, this time with this comment:

(why reject? I'm trying to add some useful information here so that the answer is more clear to someone who would encounter the same problem again. how is this edit "minor" or "trivial" or "not substantial"?) improved formatting, add footnote about errors that can be ignored

Again it was rejected 3:1, with one of the rejects explicitly saying "Should be a comment instead.". I would argue against this saying that making the extra information a comment would defeat the purpose of a website like StackOverflow, where seekers of answers should be given correct and complete answers.

In this specific case, the phrase "Make sure you don't have any errors" is misleading, because in the Eclipse IDE, even after other errors have been fixed, the error which I was talking about will still remain, which can only be fixed by doing the step that follows it ("Fix Project Properties") or the instructions in the second paragraph (modify XML file and save). This is what led me to suggest the edit to make the answer more complete and comprehensive, so the next person does not have to sift through the comments for such a valuable piece of information.

I think very often, peer reviewers at SO are rejecting suggested edits too harshly, too quickly and without fully understanding the original problem and the context in which the edits have been suggested. They seem quite often to follow a gut feeling when making decisions (how can you reject an edit so quick within mere seconds of posting it?) rather than analyzing the question/answer properly, understanding the context and thinking about whether the suggested edit is actually something worth keeping.

Suggestion:

I hope the SO/SU community can improve on the peer reviewing process so that actual useful edits are not lost in your battle against useless ones. Perhaps reviewers should be forced to spend some time reading the original question and the original answer, and deciding whether the edit adds valuable piece of information that could be helpful to the next person who has the same question. (This would mean edits can't be approved or rejected within seconds of viewing them, but the reviewer could be delayed by a minute or two* - I believe this will reduce the chance of impulse reviewing as the wait will encourage the reviewer to use the time productively.

* The time to wait could be tied to the caliber of the reviewer: a new reviewer could be given 3 minutes of wait; a learning reviewer 2.5 minutes; a graduated reviewer 2 minutes; a seasoned reviewer 1.5 minutes and a veteran reviewer 1 minute (the minimum wait for any reviewer).

Alternative Suggestion (courtesy CodyGray and Mr.Wizard):

The edit queue could be filtered based on tags of questions on which the edits were made, meshed with the top five? tags the user had been most active on (their past questions and answers combined, with answers bearing more weight and high-voted/accepted answers bearing even more weight). Those edits which had lapsed a couple of hours or a day without review could be placed in the unfiltered queue for anyone with enough reputation points to review them even if their top tags do not match the tags in the question. Both the filtered and unfiltered queues should be made available to the users with enough rep to see the review queues, without any specific restriction towards one or the other.

Answer 1

The problem here is that you're asking the people reviewing the suggested edits queue to judge the technical accuracy of your additions to the answer. Since the site's domain is so extensive (there are a lot of programming languages and frameworks)^*, there is little to no guarantee that the people who review your suggested edit will understand what you're trying to add. They have no way to tell whether it is obvious and trivial as you assert here, or whether it's out and out wrong.

So instead of trusting you and clicking "Accept", or recognizing their inability to accurately judge the merits of the edit and clicking "Skip", the majority of folks are clicking "Reject" and arguing that you should do little more than fixing typos and improving formatting.

The good thing about that is that it means anyone is qualified to review a suggested edit—you don't need any particular knowledge about the post's topic. The bad thing about this is, as you point out, that it makes it impossible for users without full editing privileges to contribute anything substantive to an existing post—the only improvements they can make are cosmetic.

Joel's words from 2008 are as true today as they were then: the purpose of this site is to accumulate superior answers to a diverse array of programming questions. There is no reason why you should have to post a second answer just to add some additional background information or a helpful hint.

But it just doesn't always work out in practice as elegantly as it sounds in theory. What you have to understand is how many genuinely awful edits get suggested and end up in the suggested edits queue, fatiguing and jading the reviewers. If it looks like you've suggested one of these bad edits, your edit gets rejected. In this particular case, your edit might have been a gem, but it was hidden among so many ugly rocks that people just assumed it was ugly, too. Honestly there are still so many bad edits getting approved that I'm hesitant to suggest that we should be more lenient in the edits that we accept. It's a much easier guideline to tell people that they should just not accept anything that changes the meaning of or adds additional content to the answer. The reviewers can understand that, and it'll lead to the right decision 80–90% of the time.

So what's the solution? Focus more on contributing your own content in the form of answers. That will earn you reputation, and it won't take long to get to the 2,000 reputation that you need to make edits that go beyond cosmetic. Invalid edits can always be rolled back if a mistake is made, but the idea is that we trust people with full edit privileges to make the right call on their own edits, using both the information they know about the post's topic and the site's guidelines.

---

^* This explains Mr. Wizard's observation that edits of this nature are better handled on smaller sites (read: not Stack Overflow), where the size of the suggested edits queue is more manageable and more users have broadly-applicable domain knowledge. That's great for those sites, and that's why we focus so much on community building with the Stack Exchange 2.0 platform. But Stack Overflow redefines the notion of "critical mass", and I don't see this problem being solvable there.

Answer 2

@CodyGrat's answer is spot on, but I wanted to reinforce something that I don't think he highlighted enough.

The idea of editing vs commenting vs answering has been debated since the site was new and is still finding its niche (and thanks to Mr Wizard for finding these links):

• Editing versus answering?
• Is it OK to edit a correct answer for fullness instead of answering?

Both suggest that editing to add content in encouraged. However, this seems to run against the current behavior (or does it?)

If you haven't noticed there is something that is not discussed or even mentioned at all in either post, suggested edits (although Joel Spolsky's answer does lay the foundation). That's because suggested edits didn't exist at all until January 2011. Before then, the only edits were full edits, not subject to peer review. At that time, editing to add relevant content was actively encouraged. This is also part of the idea behind Community Wiki posts, it lowered the editing bar to let anyone edit it/contribute to it and the post became a community owned post rather than one that "belongs" to the original poster.

Fundamentally, suggested edits have different unwritten rules, especially on Stack Overflow due to the volume of incoming posts, that have been refined over the years and what it comes down to is that "how to edit" is different than "how to suggest edits". Clear rules on reviewing edits hits on some of the key points from the reviewer side for suggested edits. Ultimately, your added content fails on several of these items, so they were right to be rejected based on the current rules.

The idea behind suggested edits is was to help moderators and the users with full edit privileges keep the site clean by cleaning up grammar, spelling, etc. Before suggested edits existed you only had three options, (1) flag, (2) comment, or (3) post on Meta Stack Overflow. This made it very difficult to fix posts that had grammar or spelling mistakes, in fact users were not encouraged to use (1) and (3) unless it was a serious problem. Suggested edits though were not intended to lower the bar for any kind of editing because edits need to be reviewed my multiple people to ensure they are correct.

But once you hit 2000 rep, then the "rules" relax as the community "trusts" you enough to know what you are doing and to make good edits. The kind of edits you want to make should wait until you hit the 2000 rep barrier and then they are more acceptable. Note that I said more acceptable as changing the meaning of posts through editing is still not encouraged, but adding some additional information or adding some relevant code is perfectly acceptable.