Upcoming feature: contested edit extension

The next release (a week from Monday) will include a useful new feature: extending the expiration of edits that receive ‘No’ votes! I’d like to take a bit to explain how it’ll work.

The problem

Especially since the amount of time edits stay open was reduced to 7 days, but also before, several problematic situations could arise when edits were contested:

  • If voters cast ‘No’ votes shortly before the expiration of the edit, the original editor may not have time to respond to the concerns before the edit closes. As a result, it’s generally been considered bad etiquette to cast ‘No’ votes right before an edit expires unless the edit is particularly destructive.
  • In a somewhat related case, sometimes an edit can get many ‘No’ votes in short succession. Since 3 unanimous ‘No’ votes will close an edit, the period between the first vote cast and the edit being closed can be as short as an hour, which is certainly not enough time for the original editor or other voters to respond.
  • It’s also occasionally possible for edits to be put at risk of failing without an email being sent. Specifically, the current code only sends an email on the very first ‘No’ vote. Therefore, if a voter votes ‘No’ early in the voting period and later changes their vote, a second voter later voting ‘No’ would not result in an email being sent. However, a tied vote or a majority of ‘No’ votes will result in an edit being closed, so even a lone vote can tip the balance.

The solution

In light of all of these problems, the next release will work differently to give editors time to respond to votes against their edits.

In short: editors will always have at least 72 hours (three days) to respond after the first vote against their edits.

More specifically, and more technically:

To address the third point above, the emails for ‘No’ votes will now be sent whenever the count of ‘No’ votes goes from 0 to 1. That is: if two people vote ‘No’ with neither changing their vote in-between, only one email will be sent. But, in a case like the one described above, where an early ‘No’ vote is superseded and the total count goes back to 0, a subsequent ‘No’ vote will send a new email.

To address the second point above, ModBot will not reject an edit before its expiration time due to three unanimous ‘No’ votes unless 72 hours have passed since the earliest ‘No’ vote (that is, the vote which resulted in an email being sent). If the expiration time passes or an edit has three unanimous ‘No’ votes after 72 hours, the edit will be closed as usual.

Finally, to address the first point above, when new ‘No’ votes are cast close to an edit’s expiration time, the edit’s expiration time will be extended to allow 72 hours for response. This extension will, once again, only happen when the total count of ‘No’ votes goes from 0 to 1 – so only when an edit becomes contested and previously was not.

In total, these changes should hopefully ensure that editors are better informed about edits that are in danger of being voted down, and given sufficient time to respond to voter concerns.

In summary

First of all, this change will be fully live on Monday, June 24th. Before then, votes cast on the beta server may result in a small number of edits having their expiration times extended, but it won’t happen on the main server or for the majority of edits.

While editing: Rest assured you’ll be informed and given time to fix problems with your edits!

While voting: Don’t worry too much about casting ‘No’ votes when edits need improvement. Certainly be ready to supersede your votes if things do get fixed up, but if you find an edit in need of fixing just before it closes, or which already has a bunch of recent ‘No’ votes, don’t hold back or vote differently to give the original editor time to respond. This should take care of that for you!

Happy editing!

Server update, 2013-02-11 and an important notice regarding edits

We’ve just finished pushing out another two weeks changes to the MusicBrainz web site. While this release is predominantly a bug fix release with a few small improvements, we’ve made a fairly substantial change to the way edits are applied.

As of this release, all subsequent edits entered will have an expiration period of 7 days – a reduction from the previous 14 days. We’ve made this change in order to reduce the time that editors have to wait for changes to be applied, which should lead to an improved user experience; and we’ve also made the change to hopefully try and make the edit queue a little bit more managable. This change is exploratory, so if you find it counterproductive, we’d love to hear your thoughts. IRC, the forums and the mailing lists are all good channels to voice your feedback.

Also, we have finally made the switch to GitHub. While the existing repository URLs will continue to work, they will no longer be updated. If you want to stay up to date with the latest code, make sure to update your checkout information.

Many thanks to Frederik “Freso” S. Olesen, Michael Wiencek, Nicolás Tamargo and the rest of the MusicBrainz team for their work on this release. Here’s what’s new:


  • [MBS-3457] – Direct search results incorrectly reports a recording as "standalone"
  • [MBS-3962] – Edit search doesn’t really exclude artists with "is not"
  • [MBS-4522] – Empty annotations are not merged correctly
  • [MBS-5144] – The MusicBrainz logo in the top-left corner has a different background color than the rest of the header
  • [MBS-5395] – "Actions" column on alias page is too narrow for translations
  • [MBS-5432] – Internal server error when editing cover art
  • [MBS-5434] – Inconsistent terminology: primary/secondary types and type/extra types
  • [MBS-5506] – Edit search for "My vote is not" does not work as expected
  • [MBS-5525] – Blank edit relationship type edits
  • [MBS-5566] – No more autoedit mark ?
  • [MBS-5567] – Internal server error entering remove cover art edit
  • [MBS-5617] – "new image goes here" is not translatable
  • [MBS-5650] – ISE when attempting to approve already-closed release group edit
  • [MBS-5655] – It’s possible to "Remove [a] release label" although there’s none
  • [MBS-5696] – ModBot can fail to close ‘edit artist’ edits that violate uniqueness on (name, comment).
  • [MBS-5698] – Some move disc ID edits display nothing for the old release
  • [MBS-5700] – Subscribers aren’t removed when a user deletes their account
  • [MBS-5705] – Rows in the appearances section of the artist relationships tab are sometimes one column too short
  • [MBS-5719] – The track number of the last track on some 2-disc releases is missing
  • [MBS-5724] – Sort/copy name missing for work aliases
  • [MBS-5728] – Possible to enter ‘edit release group’ edits that fail to apply due to spaces in artist credits
  • [MBS-5732] – Empty labels don’t warn for deletion pending
  • [MBS-5740] – Useless "select all" checkbox on Release Duplicates tab
  • [MBS-5742] – Editing a work without JS on will enter a silent remove ISWC edit
  • [MBS-5748] – Not possible to "Approve" an edit where yours is the only "No" vote
  • [MBS-5750] – Subscriptions report filtering ignores labels
  • [MBS-5754] – Editing recordings from tracklist does not work if "Release Duplicate" is chosen
  • [MBS-5762] – "Work Type" and "Work Language" incorrectly left blank for "Merge Works" edits when viewing predefined edit searches
  • [MBS-5763] – Edit release edits not properly translated
  • [MBS-5764] – Work language column in the stats links to releases
  • [MBS-5770] – There is no constraint on release_label that either (or both) the label or catalog number are not null.
  • [MBS-5771] – Add utamap.com (うたまっぷ) in the lyrics URL white list
  • [MBS-5774] – "Vote on all edits" is not translatable
  • [MBS-5776] – Cover art types are not being translated on the cover art tab
  • [MBS-5777] – Users’ work ratings page has no title
  • [MBS-5786] – i18n: secondary RG type labels on overview are untranslatable
  • [MBS-5788] – No edit is created when trying to submit/attach a DiscID
  • [MBS-5791] – ISRCs can’t be removed
  • [MBS-5797] – Internal server error if the Wikipedia link is not really a Wikipedia link


  • [MBS-1413] – Make profile bios support WikiFormat
  • [MBS-1774] – Webservice: expose UUID for AR type
  • [MBS-3535] – Stack traces should mention which server was handling the request
  • [MBS-4880] – Add Help/Info about How "Merge mediums and recordings" works
  • [MBS-4902] – Add Google+ links to the sidebar
  • [MBS-5505] – Add j-lyric.net to the lyrics whitelist
  • [MBS-5605] – Ratings on collection pages
  • [MBS-5707] – Add autoselect for IMDb URL relationships for labels
  • [MBS-5727] – Disc title missing from edit relationships page
  • [MBS-5767] – Add an index on (editor, id DESC)
  • [MBS-5775] – Update Facebook URL cleanup to use https
  • [MBS-5779] – Remove useless nbsp on common-macros.tt
  • [MBS-5798] – Normalise wikisource URLs to http
  • [MBS-5803] – Add autoselect for SecondHandSongs artist URL


  • [MBS-5757] – Consider diminishing time edits stay open
  • [MBS-5766] – Open up /release/ and /work/ in robots.txt
  • [MBS-5810] – Add Open Library to the other databases whitelist

The Git tag for this release is v-2013-02-11.

Collaboration of the Month: Dire Straits

The current Collaboration of the Month is Dire Straits, please give up some of your MB time to help tidy-up this artist’s discography. A list resources and things that need to be done are at this wiki page and you can discuss specific issues on this forum topic.

We are also trying to come up with a better name for the project, one that won’t cause confusion with other uses of the term “collaboration” in MusicBrainz. If you have any ideas, please voice them here.

Edit of the Week: Crediting featuring artists

And yet another edit that caused a little controversy:

Edit 5607659

The voting is a bit one-sided at the moment but it seems that working practice has outpaced guidelines again. The FeaturingArtistStyle has always been the bone of contention (see SG5DisasterRelief for example) – now the question is if AdvancedRelationships as a mean of crediting of what an artist has actually done on a release (in NextGenerationSchema-talk: “what it is”) are shifting the “feat.” in track titles to a role where it only credits “what it says”, that is when the artist intended to credit guest appearances prominently on the cover.
The con is that the presence or non-presence of “feat.” on covers barely expresses artist intent because it is done by cover designers and mostly the artist doesn’t have a say in the design.

Edit of the Week: Previews of Upcoming Releases

I always wanted to revive this column but never found a controversial edit that was interesting enough / didn’t have too much flame notes.

I always wanted to revive this column but never found a controversial edit that was interesting enough / didn’t have too much flame notes. So, here we go:


What’s it about? Well, in short: if an artist releases a song on their website that is likely or said to appear on a release in the future, then is this a legal non-album track or not? Of course it’s also possible that it will definitely appear on a release but in another version.

So, shall we wait until the release is out and then only add it as a NAT if it’s a different version or should we just add it and later delete it if necessary (the guidelines state this)?

Edit of the week

This is the first of (hopefully) a series of posts on interesting or dubious edits (moderations). I don’t know if I’ll be able to deliver a post on a regular basis; the word week in the title might be misleading 😉 Any way, I’d welcome suggestions for edits to discuss.

This first attempt was inspired by edit #4229934, an Add Album edit for artist Sesame Street. Although the edit conforms to the style guidelines, there was an objection: Sesame Street is a so called bogus artist. There simply is no person or group of people performing under that name. Since the album being added is a music release, it is a valid MusicBrainz entry and is therefore ‘allowed’ to be added, even if the album artist is a fictitious artist.

Still open for discussion is the question what a valid fictitious artist is, and what is not. Sesame Street has proven its validity; a lot of albums are released under this name. But what about the different Sesame Street characters like Kermit, Bert, Ernie, etc. and the characters from the television series South Park? It is impossible to formulate a definition and rules for artist names that capture all people, bands, orchestras, fictitious artists and special purpose artists like [unknown], [no artist] and [anon.]. The only certainty is that Three Flute Players and a Singer of the Atutu, Baule and that sort of ‘artists’ definitely do not deserve an artist entry in the database 😉

Happy editing.

More Wikipedia stuff

This is an excellent piece on cooperation and politeness at Wikipedia — I haven’t finished reading it yet, but for anyone who is thinking about improving MusicBrainz’s voting system, this should be considered required reading.

I for one, am finally seeing the light on Jamie Munro’s Survival of the Fittest proposal and how it should let us avoid some of the problems/issues/discussions that Wikipedia is currently encountering. I think it may be time to tackle that after I get the new tagger on solid ground.

Editing Guidelines on the Wiki

After moderating my way into the top five moderators / top ten voters, I’ve decided to slow down my moderating, and spend more time trying to provide advice and help for new moderators.

On the Wiki, I’ve been working on a collection of pages that I hope will form the basis for Editing Guidelines that complement the current Style Guide. Where the Style Guide tells you how entries should look when they are done, the Editing Guidelines are intended to tell you the best way to get there.

Continue reading “Editing Guidelines on the Wiki”