There has long been a conflict between those who want to make it easier to add data to MusicBrainz and those who dont. The argument goes if we make it easier to add data we will have too much data to review, and therefore wont be able review it properly so bad data wil be able to creep in more easily.
I understand this argument, but (especially as a software developer) find it annoying having to navigate MusicBrainz interface to manually add data that could be added quicker and more accurately programatically,
So I have an idea why not make it easier to get data into MusicBrainz automatically but make some kind of review mandatory before it goes into MusicBrainz proper, then we can concentrate on finding data and then reviewing it rather than inputting it ?
I’m not sure if this is what the OP has in mind here, and my apologies if this reply is off-topic:
I think an offline tool with a clean and easy to understand interface would be a blessing.
A user could then take all the time he needs to learn it and populate it, and then upload the whole release when he’s happy about it.
Also, it would probably be easier to tune and maintain such a tool for different levels of user cases, and add or change features, depending on user feedback and experiences.
It’s probably a psychological thing, but the online entering and editing, and it’s complications for me is still a hurdle which—among other reasons—has prevented me from starting to add releases.
I imagine such a tool probably can’t be 100% offline, since it would require some checks and suggestions for entering correct content, but still, for someone like me, an offline tool would be much more inviting and comfortable.
I also alreay have a suggestion for it’s name: Dracip
But if a vote is mandatory then there is reduced risk of bad data.
If it is easier to add data (so less time taken) , then more time for voting. Currently adding data is so painful and slow that there is little time for an editor who adds data to vote on data, if they could add their data more easily then maybe would be more likely to free up some time for voting…
I doubt we have few voting editors because people don’t have the time, I suspect it’s more because adding artists/releases/etc has a direct benefit to the editor (they can now tag their music locally), whereas voting usually doesn’t have this effect. Voting also requires an intimate knowledge of rules and style guidelines, IMO it feels significantly more intimidating and “painful” than entering a fresh release (esp. when assisted by tools such as seeder scripts).
Framing not allowing API editing as making it harder to edit is misleading IMO. It is only “harder” for the relatively few people who want to do automated editing.
Well firstly how do yo know its only relatively few people.
Secondly, if those people could then make tools as suggsted by hiccup then that would be easier for others.
Thirdly, manual editing is hard as well e.g try and add a few releases at the same time and they can be added without tracks being added, adding Classical is extremely cumbersome.
Your first and second point are already addressed by release editor seeders though, the only difference being that it keeps a MusicBrainz-controlled interface between the editor starting the process and the release being added (i.e. we don’t trust the editor seeder unquestioningly).
I’m having a hard time imagining scenarios where adding multiple releases at the same time is an unreasonable amount of work (outside of classical releases, which I do accept are a pain point right now, but that could be improved with less radical changes). The only thing I can think of are mass-imports either from other databases or online stores/their APIs, which is problematic for reasons that have already been mentioned elsewhere.
It is, because if I have three releases ready to do and I seed each release on a new tab at the same time chances are one will be added without tracks.If I add them each in turn there is some wait before submitting and it completing.
That sounds like a bug, so if that’s the problem, then the bug should just be fixed. Is the bug reported in Jira, and if so, are there clear steps to try to reproduce it?
I’m pretty sure you can seed the relationship editor (you can certainly seed relationships for the mini-editors on artist/create and whatnot, at the very least). It’s probably either undocumented or very underdocumented, though.
