The major updates in today’s release are:
- Non-auto-editors can make auto-edits to their release additions within 1 hour of adding them.
- There’s a way to report editors for bad behavior, from their user profiles. The reports will be sent to our account admins. We’d prefer people use this method from now on for reporting unresponsive editors, or for any Code of Conduct violations. Account admins have also received an easy way to restrict a user’s editing/voting capabilities.
- Auto-editors can change a release’s data-quality level via auto-edit. Previously, this was always put to a vote. We still don’t display release quality as well as we could (currently it’s only visible in the release sidebar). Low-quality releases can be found via our edit search, though.
- Everyone can enter “Add recording” and “Remove alias” edit types as auto-edits.
- Edits to events can be searched via our edit search interface (thanks chirlu).
There were a lot of comments on last release’s blog post saying that it’s harder to review release additions now that they’re auto-edits, and worrying about database quality suffering due to this. The next server release should allow showing auto-edits entered within the most recent voting period (7 days) in your subscribed editor/entity edit listings (MBS-8647), and hopefully a way to hide auto-edits you’ve reviewed from these lists (MBS-8654) to get them out of your way. I hope these and future changes can strike a balance between allowing people to see and remove releases that are clearly wrong or non-existent, vs. encouraging merging/fixing existing releases rather than voting them down.
The git tag for today’s release is v-2015-11-30 and the complete changelog is below.
Bug
- [MBS-8460] – Add to collection link on entity page doesn’t show the collection name
- [MBS-8636] – Adding duplicate entities to a series causes an internal server error
- [MBS-8639] – Instrument merge gives ERROR: duplicate key value violates unique constraint “link_attribute_pkey”
- [MBS-8641] – Release editor breaks with “error: 0” if a submitted edit throws a NoChanges exception
- [MBS-8648] – Historic relationship edits no longer display the source entity
Improvement
- [MBS-1880] – Allow an editor to apply edits without voting within a short timeframe after his/her ‘add release’
- [MBS-8208] – Add a way to report a user to an admin
- [MBS-8271] – Add a way to prevent a user from editing/voting which doesn’t involve removing the email address
New Feature
- [MBS-8645] – Allow searching for edits to events
MetaBrainz Blog 
This seems like band-aids that really don’t address the core problem, if not exacerbating them (as if the edit system wasn’t already opaque enough)
Did we even have a big problem with releases being deleted?
“encouraging merging/fixing existing releases” – Who is being ‘encouraged’ to do this? I thought not having enough voters was already an issue? I’m sure those 10 people (or whatever) have the time to fix everything instead…
Anyway, I certainly don’t have time, so I’ve reported the careless editor I’ve been tidying up after over the last week or two, but this may as well be automatically done for every new editor, since MB now combines an impenetrable set of guides, FAQS and documentation with zero encouragement or method for any editor to improve beyond editing to their personal preference.
I quickly finished off a concept that has some ideas in it re. easing people into MB with User Classes, which could perhaps be tweaked to make it so that day 1 editors aren’t all-powerful, yet later on editors are given a smoother and more queue free ride:
It’s a bit complicated though, so my other idea, more in line with the current changes, is to remove the functionality to edit entities, only add new ones, and then MB can have HEAPS AND HEAPS of MBIDS! No need to vote on anything either!
With that I’ll consider my input (real and sarcastic!) done, unsubscribe from MB mails, and check back monthly or so to see if some kind of real action regarding this has come up. Cheers.
Thanks for the concept, I see some good ideas in there. 🙂
> This seems like band-aids that really don’t address the core problem, if not exacerbating them (as if the edit system wasn’t already opaque enough)
I don’t think making release additions more visible again, or making it easier for people to fix their releases, will exacerbate any problems, so you’ll have to be more specific.
> Did we even have a big problem with releases being deleted?
Well, only a small percentage of releases were being voted down, which was one of the arguments for making them auto-edits (reducing the size of the edit queue in the process). But if you search for the subset of “Add release” edits that have at least 1 no vote, I think there’s a way to categorize most of them:
(1) Releases that duplicate existing ones. See http://wiki.musicbrainz.org/Merge_Rather_Than_Delete
Improving duplicate detection and making merges easier are works in progress.
(2) No source given. This is especially a problem when there are no details to distinguish the release from existing ones, or when there’s no evidence the release exists at all after a basic search. The release can still be removed in that case.
On the other hand, there’s no excuse to mass no-vote all of an editor’s releases without even looking at them, just because they have a history of being unresponsive. You can see examples of that, including cases where the release exists if you do a Google search.
(3) A source is given, but doesn’t match what was added. It can be removed per (2) if necessary, or the original editor can be asked to fix it. Otherwise, if someone cares about the data, they will fix it.
(4) The release exists but has mistakes in the titles, artist credits, etc. Someone who cares about the data will fix it, even if they don’t own the release, but if it’s voted down, will it ever be re-added?
> “encouraging merging/fixing existing releases” – Who is being ‘encouraged’ to do this?
Everyone.
> I thought not having enough voters was already an issue? I’m sure those 10 people (or whatever) have the time to fix everything instead…
The number of voters has always been an issue, but especially in relation to the size of the edit queue. I hope that really destructive edits and edits that make existing data worse will receive a higher percentage of votes/review/attention, without preventing people from seeing/removing really wrong additions.
> don’t think making release additions more visible again, or making it easier for people to fix their releases, will exacerbate any problems, so you’ll have to be more specific.
The reason new users add things incorrectly, over and over and over, is because MB has hundreds of functions and guidelines that are impenetrable on day one. Things like data-quality level are another layer of complexity that do nothing to help the problem, except for maybe a few high-level users who use it for some kind of personal editing system. If new users automatically had their edits marked as low quality for a period, or maybe a ‘low-quality’ button right on the edit queue, and then those releases were more visible on the interface somehow, it could be useful, but I haven’t seen it used so far, and I doubt it’s going to be used in future. Not only that but it represents another thing for the current small core group of voters/ watchers to do, which is exactly the complaint about these changes.
The edit queue is another confusing element as it stands, and I look forward to seeing how you’re planning to explain the current system of what is/isn’t an auto-edit to a new user (or any user who hasn’t read the blog)…
(1) could not be less helpful right now
(2) it takes substantially more effort to research and fix someone’s awful additions than to add a new one. A new user with a lot of time on their hands will single-handedly take the quality of the DB down a notch. You guys are specifically saying “it doesn’t matter, someone will just have to fix it”. Not only does that put an impossibly heavy workload on the small hardcore userbase that has somehow gained the skills and knowledge required to do so, it also means that these problematic editors will never gain those skills and knowledge. The graph of the future is a steadily rising number of low-quality editors (through no fault of their own) and a dwindling number of hardcore users expected to fix everything.
(2)-(4) not “everyone” is being asked to fix these edits, “everyone with the skills and knowledge” is being asked to fix these edits. Which is a very small group of people who apparently don’t want to (or can’t) be doing maintenance work 24/7 with no end in sight.
Not disagreeing that things are difficult and confusing. I wish more people with coding knowledge had time to contribute to musicbrainz-server and help improve things. I’m doing what I can to improve our infrastructure so we can start making heavy UI improvements. Gentlecat is working on in-site communication right now.
I think the problem is too many people with coding knowledge being involved 😉
Guess the only message here is to wait for the upcoming changes that will fix things TM
I really don’t think the ~2–3 people usually on a server release are too many. I wish we had at least twice that many developers working on musicbrainz-server. Definitely not less.
The problem I was pointing to in my post is that 100% of the developers on a server release are (it seems) back-end nerds. Not that there are too many people involved overall.