From MusicBrainz Wiki

This is a proposal to change the current way of adding ARs to multiple tracks on a release.


Editors can add an AR to several tracks on a single release at the same time; this is a major time saver.

However, for each track a different “add AR” edit is added to the voting queue (and the edit history). This demands a lot more time to verify and vote on the edits. It is also more difficult to do so: an extra or a missing AR is hard to notice in a long list of different edits, especially on releases with many tracks, where edits may be split on several pages.


The editing system should be modified to group such edit lists in a single edit item.


Nothing needs to change in how editors add ARs to tracks on a release. (At least not for the problem described here.)


Instead of showing several “Add Relationship” edits, the edit queue will show a single “Add Relationships” entry for each editing operation. The description part of the edit item (the blue box in the current UI) will show “Add: [artist] [AR text] {all tracks|tracks [list]} of release:”, then will display the release in the same way it displays it for “Add release” edits. (When JavaScript is available, the release will be folded by default.)

The release will display track ARs such that:

  • ARs that have been added by this edit are highlighted in green (usual convention for addition);
  • ARs that exist already are displayed normally (transparent background);
  • ARs added by different edit are highlighted in yellow (the current convention for “edit in progress”);
  • if there are many ARs, some might be folded by default, but such that the newly-added AR is always visible. (Note that there can never be more than one newly-added AR for such edits.)

I have created a concept of the proposed page: show concept. (You can also see the HTML source, but that's not very relevant, I expect the actual implementation to differ.) This concept is based on the current “show edits” page. I have tried to keep all viewing functionality active (links, etc.); I've tried to disable the links that would trigger editing actions, but be careful in case I missed one. Note that the artists and release shown actually exist (the links are correct), but the real release has more tracks and ARs (I have removed the rest for brevity).

If the editor uses the “add ARs to tracks” interface, but adds a single AR, then edit will take the normal one-AR form.


I have no idea how edits are represented in the MB database, so I have no proposal here. Devs could use this space to discuss it, if needed.

I just note that old edits (those already entered) don't need to be changed at all.


Just like “Add release”, an edit may have errors. If they are large, the editor may cancel the edit and redo it.

But if the error is small, it is easier to just fix it with a subsequent edit. We must consider how to display this in the old edit, for the benefit of voters. A fix that just adds an AR for a track (missed the first time around) would just be displayed in yellow, as described above. For the other cases (deletion or modification):

  • The most expressive would be to add a “{deleted|modified} by edit #123” link after the affected AR.
  • The simplest would be to just display the “latest” state of each AR release. This means that deleted ARs would not be displayed (even if they are mentioned in the affected tracks list), and modified ARs would be highlighted in yellow (according to the above convention, this means another edit affects them). This is the current behavior of “Add release” edits, and I think is enough.

Future Work

If this proposal is liked and implemented, it can be later extended similarly: first to apply the same treatment for “Edit all”. Second, make a sort of “edit all” for adding all ARs in a single page (only for users with JavaScript). Third, combine the first two in a single page :)