It's more than just discouraging, each rejection has impact on the user suggesting the edit as it might lead to a ban.
The above is no longer true, as of June 4th 2013:
We now completely ignore any suggested edits that were rejected by the Community User when determining whether someone be banned from reviewing suggested edits
This is a blessed change, ...
We now ignore any suggested edits that were rejected by the Community User due to an edit conflict when determining whether someone should be banned from submitting suggested edits. These rejections are annotated with a description of what happened:
Aside from rejecting "concurrent" edits, the Community User also rejects edits that are ...
An old question, but still extremely relevant, and with a much easier answer 4 years on (did I mention that I love the new update? :D ):
At the top right of the screen, click on your user profile icon. This now takes you to a page like this (sorry, this is my first meta.stackexchange post, so there's no activity on this site for my profile right now).
Rejected edits do have a consequence; sufficient bad edits will land you with an edit ban.
However feedback is always a good thing and I would support increased feedback. Expecially as failed reviewers cannot be @replied to to give manual feedback directly on the edited post itself.
However, a rep penalty may have the opposite effect to what you hope. If ...
When choosing to accept/reject a suggested edit there are two elements you should consider
Did the edit improve the post
Was the edit sufficient to justify the reviewers time.
The Edit didn't improve the post
This is clear: reject in this case
The Edit did improve the post
This is more nuanced, the aim here is always to get the best overall result for the ...
We sprang into action upon observing this problem, and less than 4 years later a solution is in place - post authors can now override the decision on suggested edits, accepting or rejecting edits even if the reviewers previously decided on something else.
You have edited code in an answer.
It seems to me that if you think your title is really better and worth having edited in order to improve the post, you shouldn't have stopped at the title. There were things in the post itself which could have used help, too. Again; applying the standard you appear to have applied when making the title edit in the first place. In that regard, I agree that ...
Your edit is completely superfluous.
The extra info is not "extra" or optional as it gives advice to a good practice.
Putting P.S doesn't make the post even a little bit easier to read either (=no improvement).
I don't think the original title was the worst part of the post:
Essentials C# framework 3.5 book from Mark Michaelis, errors in code from the book
And I especially don't think your title change was good:
Error using List
In fact, I think the suggested title made the post worse as it said nothing about the actual issue.
If I clicked a question ...
Editing code in answers1, except to fix obvious typos, is discouraged by a portion of the community. This premise is based on the idea that you are changing someone's work to something that it isn't, and that person, not you, will feel the impact (in terms of downvotes) if your edit is not correct. Because of this, many reviewers will reject almost all ...
Yes, this was the wrong approach. See this answer from Bill the Lizard (emphasis mine):
If you want to bump an unanswered question that's fine. That's a feature. Just make sure your edit improves the question in some measurable way. ... Very frequent bumping with no visible change to the question will probably result in it getting flagged and locked.
I'd chalk this one up to the reviewers not being careful. I could perhaps understand a rejection without a clear description of what the problem was. Many editors are not as diligent as you have been in writing a description of the edit. But even that is not the case.
There is no problem with the edit being unclear in the "rendered output" view, while ...
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 ...
In my opinion, the best attitude in this scenario is...
...of the "Those fools! They rejected my work - MINE! I'll show them, I'LL SHOW THEM ALL!" type.
...followed by a concerted effort to garner full editing privileges. So that you can show them all.
Sadly, it's due to an issue with how the suggested edit is rendered in the review queue. The review queue doesn't render the same way the actual page is. In that queue it appears, to the untrained eye, that it was working before, and that your edit double-encoded the values. When looking at the tag wiki normally one can see that your edit is in fact ...
Is there any threshold for rejected edits that causes one's reputation decrease or some other loss?
No. You can't lose reputation from rejected suggested edits, as you never gained reputation from them in the first place (they would need to be approved not rejected for that to happen).
What can happen is that the accout will get banned from suggested edits ...
It's an incorrect rejection, but also an easy mistake to make. It's not immediately obvious that the code you are adding is not your own, and you just moved it from the OP's fiddle to the question text (which is a good thing).
I would hope that reviewers would pay a bit more attention to edits, but... it's always better when the mistake is rejecting a ...
Editing someone's incorrect code is not a good practice. If you think the answer has some issues, you can comment on the answer. If the author don't reply you, you can downvote the answer and add your own answer with valid code. So reviewers mostly reject such edits.
You changed a title from something that actually tells me a fair bit about the post to something that tells me almost nothing about the post. It's quite a bit worse than the previous one, which makes both rejection reasons entirely justified.
Your new title doesn't even make sense. There is no List in his code for him to have problems with. In addition ...
According to this page in the help center, putting information from comments into a post is a good reason to edit. In my opinion, edits like those are great edits.
From that help center page:
Common reasons for edits include...[t]o include additional information
only found in comments, so all of the information relevant to the post
is contained in ...
The issue present here occurs when:
You (a user with full edit priviliges) are looking at a question page.
User B submits a suggested edit to a post on that page.
You click "edit" and get either the full editor or inline editor.
You make changes, submit the edit.
This results in what you noted in your question:
The editor is pre-populated with ...
I'm not sure what you mean by your distinction between pressing "this is a bad edit" button and also not allowing it. A reviewer has only three options: approving an edit, rejecting it (pressing the "bad edit" button, I guess), or improving it with a further edit. But.
I'm struggling with how to respond to this. Let me just ask it this ...
You can't appeal rejected edits. The best thing to do in this case is to leave a comment below the post (once you have sufficient rep), pointing out what you think is a problem. Code-edits are rarely accepted.
The wiki suggestion you made doesn't explain the usage of the tag.
It explains git-core - that's not what tag wikis are for.
Bullet point 4 of the guidelines:
Provide basic guidance on when to use the tag
Now, re-reading, the problem is that the guidance is buried at the bottom of the edit. It should be at the top. As commented here, it should also ...
I like the idea (I actually made a post on the very same subject myself a few days ago), but penalizing them with reputation subtraction is not a good idea.
I can see several issues with that:
Incorrect judgement by the community subtracts reputation when it shouldn't (with the amount of poor reviewers, this is a real issue).
As Richard remarks: friendly ...