Uploaded image for project: 'MusicBrainz Server'
  1. MusicBrainz Server
  2. MBS-8379

Encourage merging over deleting to preserve MBIDs

XMLWordPrintable

    • Icon: Task Task
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • None
    • None

      The idea of permanent IDs is supposed to be one of MB's core principles. However, right now, we don't really encourage people to preserve MBIDs and it's generally much easier to delete MBIDs than preserve them. If we care about having permanent IDs, we should try and avoid all unnecessary deletion of them - it needs to be easier to do the right thing (merge duplicates) and harder to do the wrong thing (delete duplicates).

      Some possible and probably controversial ideas:

      • Update/expand https://musicbrainz.org/doc/Merge_Rather_Than_Delete and make it much more visible to inform/remind editors about it, e.g. add bigger warnings to delete pages, add a link reminding voters about it when displaying delete edits. If people don't understand why they should try to preserve MBIDs, they definitely won't try to or encourage other people to.
      • Make all adds auto-edits, so that new things can't be cancelled or voted down, only manually merged or deleted. Right now it's far too easy to delete MBIDs for a duplicate by voting it down or cancelling because it's much faster than merging it. Just because an MBID was only recently created doesn't mean nobody is using it. Information is available immediately from the WS and within an hour from replicated servers, so an MBID can be in use by someone else from the moment it's created and allowing people to vote down or cancel these edits encourages deletion of these MBIDs.
      • Stop automatically deleting empty entities and require manual merging or deletion instead. Having empty entities be automatically deleted gives people no reason to bother merging now-empty duplicates, because it is always easier to do nothing than to do something. We should instead identify the situations which result in empty entities and try to find solutions for it, e.g. if the user changes the release group for a release and that would result in an empty release group, ask if they want to merge them instead.
      • Make edits which merge entities easier to apply than those which delete entities. Right now, they both have identical criteria, so there's no incentive to choose one over the other. If a delete, for example, always stayed open for at least a full week or required a higher number of votes or always required a minimum number of votes, merging would be easier/faster to apply.
      • Make merges easier to enter. Right now the interface is rather slow and cumbersome to use, you have to manually navigate to both entities in order to merge them and you can only have one open merge process at a time. If you could just click "Merge" on the entity's page and have it pop up an inline search pre-filled with a list of entities with similar names, it would be a lot faster to do, since most of the searching would usually already be done for you.
      • Make trivial merges easier to apply, e.g. a merge for an empty entity with no obviously conflicting information could be auto-editable/approveable.
      • Display more information about merge edits and stop requiring edit notes for obvious merges. Right now you're required to add an edit note for merges, which leads to lots of people just saying things like "duplicate", because they don't feel they have anything useful to add. If merge edits were smarter and could tell people what's the same and what's different, we could require edit notes only for non-obvious merges.
      • Make open merges and deletes more visible, e.g. by having special pages for them along the lines of https://musicbrainz.org/edit/open so that people can easily find them to review them.
      • Explicitly state somewhere that permanent IDs are one of our core principles and add something to the Code of Conduct about following our core principles. (This point is something I think Ian would probably be better at expanding on, hopefully he understands what I mean here)

      This will quite clearly need multiple tickets if we want to implement any of it, I mostly just wanted to dump a load of thoughts somewhere and hopefully trigger some discussion about whether we still care about permanent IDs (hopefully yes) and if so, what we can do to discourage deletion of them.

            Unassigned Unassigned
            nikki nikki
            Votes:
            8 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:

                Version Package