I'm a bit skeptical if we should do a ranking like this... especially if we really want to punish "Canceled edits". I would veto this. But I think something like "badges" (only reward, not punish) would be kind of cool. I'm setting this to "Decision required", because it clearly needs discussion, and can't be implemented right away.

http://chatlogs.musicbrainz.org/musicbrainz/2012/2012-10/2012-10-12.html#T09-09-55-488100

Indeed, I think the three negatives are not well chosen because they introduce unfairness between automods and non automods.

• automods can't fail votes (autoedits are not votable).
• automods rarely fail for other reasons because those fails are usually due to pending queue bugs (autoedits are not pending).
• automods rarely cancel (autoedits are not cancellable).

Furthermore automods will even get more positives instead of those three negatives.
If an edit is bad, that will produce a fix edit which makes it double positive.

edit let's see if what I said is really true :

"bad edit" case	Normal editor	Automod
voted down	-10	+2
failed other reason	-1	+2
cancelled	-5	+2

bad auto edits (+1) are seen usually long time afterwards and will generate a second fix autoedit (+1).

edit end
Other than that it's funny.

I don't think this is happening with the current edit system, first of all.

However, with NES I think a more interesting possibility arises – as I understand it, NES should make it much more possible to determine a metric this way: for every edit a person makes, how much of that edit is still reflected in the current version of the entity? For editors entering primarily good data, this will work well – if the data is good, it won't need correction and thus more of a given edit will remain reflected in the current version. Since NES also supports a more concrete notion of reverting edits, the "bad autoedit" case is mitigated better as well – if an edit is fully reverted, even if by the same person, the source of that data is the former editor, not the person who did the reverting. It also distances the metric from the specifics of the edit system, basing it, instead, on the data itself.

The one potential problem I see here is that editors who are adding data in "unknown" areas of the database will be rated more highly, since their edits have much less chance of getting reviewed or corrected. However, I'm not sure this is actually a problem: in an area where data is more sparse, it makes some sense that editors would be more highly 'rewarded' for providing any data.

In any case, I think this is an interesting idea, but it needs a lot more thought/work – it may be many years away.