I’ve tried that, but as soon as I re-edit the new recordings, the edits go into purgatory for a week. It’s just the same if, for example, I make a typo (eg. release date), and then correct it, it goes straight into moderation for a week.
These are a feature request (recordings), then a bug (release date).
- Feature: When the same editor edits its own created entity within one hour after creation, it should be auto edit — extending this feature to other entities than releases (like here recordings), would be nice as well (MBS-8134)
- Bug: Editing release event in the next hour after creating the release, should be auto as the other release edits (MBS-8905)
I wonder whether there is even the need for the golden one hour, and if the creating editor should just be allowed to edit?
The original editor can be as wrong as anyone else. Their only advantage is that they in most cases won’t confuse multiple different versions.
It would be no good if an original editor coming back to their release after some rightful cleanup in surrounding releases would then make edits no longer valid but still auto.
It’s difficult to explain for me.
I would say 24 or 48 hours would be good.
I would think anything that only that person has edited should be auto.
It makes sense. Otherwise there is an argument that as soon as I add anything to MusicBrainz, it should immediately go into moderation, regardless of whether it is an edit, or a new addition.
The change to not have new additions go through the edit queue is a new one, and has caused a lot of problems for voters.
I think auto edits for something no-one else has touched is a good idea though.
What kind of problems? I’m honestly curious.
[quote=“psychoadept, post:29, topic:160688”]
What kind of problems? I’m honestly curious.[/quote]
The quality of edits from new editors has dropped significantly.
Now an editor will add hundreds of releases to whatever standards they wish for personal use, ignore messages, and although they might eventually get hit up by a community manager, leave hundreds of hours of work to correct things - things that would be much much quicker to add fresh.
A counter question - what’s the point in making new additions auto edits?
The information is available on the database straight away either way.
So perhaps new editors need to meet the approval of the community, by demonstrating that they can edit to a certain standard?
If the data is (generally) correct, but formatted badly, imperfect data is better than no data (so it shouldn’t just be rejected). If the data is generally just wrong, the release can always be removed, and it takes only slightly more effort than before (but that’s not that common). If the new add is a duplicate, it should be merged (and the MBID, which is already available in any replicated servers and elsewhere, redirected) rather than rejected (and the MBID lost).
The first and third of these issues were a big part of why the change happened (to avoid people just downvoting things that should be dealt with in a different way). Another reason was that it cuts down on the voting queue in a way that makes actually destructive edits (that can’t just be undone with ease) more visible and likely to get attention.
Dissuading work arrange relationships
That’s all true, but it doesn’t change my point that new editors now have no reason to learn the ropes.
Formatted badly, imperfect data is what we’ll be seeing a lot of, with no end in sight.
[quote=“reosarevok, post:32, topic:160688”]
If the new add is a duplicate, it should be merged[/quote]
After a few weekends (tens of hours) of merging and fixing releases I stopped bothering with some editors. I reported them so that the people who decided this was ‘no big deal’ could do the merging instead, but instead nobody does it.
There’s other ways to give destructive edits more attention.
This seems like a better approach. Which brings us back to my suggestion of a “trusted editor”, who has demonstrated a certain level of competence/cooperativeness.
I am not sure but I think I already saw pending release add edits by limited editors.
But maybe they had simply checked the “make all edits votable”?
I think the suggestion would involve making the limited editor status last longer or require more work to get out of.