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-06-10

Another week, another release! This release is mostly bug fixes, but I’m sure a lot of people will be happy to notice that we have finally resolved MBS-357. That’s right – we no longer have a single clear text password in the MusicBrainz database. We’re sorry that it took so long, but at least it’s finally been done! Other than that, this release mostly builds on top of the new schema change features, and provides bug fixes for things that have regressed.

Many thanks to Michael Wiencek, Nicolás Tamargo and the MusicBrainz team for their work in this release. Here’s what’s changed:

Bug

  • [MBS-6007] – JSON release webservice doesn’t include works
  • [MBS-6179] – Sorting a collection by catalog number sorts ‘8BP117’, ‘8BP126’ and ‘8BP127’ in the wrong order
  • [MBS-6260] – Dates and countries are displayed inconsistently
  • [MBS-6263] – Adding an area without ISO 3166 codes shows blank values in edits
  • [MBS-6264] – Languages/Scripts statistics have an empty "Last updated field"
  • [MBS-6297] – Can’t create relationships from areas to other entities from the area page, but only from the other entities’ page
  • [MBS-6325] – Moving a release with a release date into an empty release group does not provide it with a date (sorting doesn’t work)
  • [MBS-6326] – ModBot is unable to close some edits as they still use ‘country_id’
  • [MBS-6334] – Release editor: loses join phrases and artist credits when switching to tracklist tab
  • [MBS-6355] – 502 displaying relationships for prolific artist
  • [MBS-6357] – Track/medium tables have indexes/constraints with bad names
  • [MBS-6370] – Beta: Inline search can load duplicate results
  • [MBS-6377] – Track ACs appear changed but the edit isn’t submitted
  • [MBS-6385] – Strange results when pasting an area URL in the inline search
  • [MBS-6409] – ModBot leaves translated edit notes
  • [MBS-6441] – Release (date, country) are blank when displaying a disc ID
  • [MBS-6443] – Ascending and descending sorting of releases in a collection results in the same order

Improvement

  • [MBS-357] – Don’t store passwords in clear text
  • [MBS-4962] – Slave servers should cache heavily due to hourly update process
  • [MBS-6203] – Only allow recognised URLs for relationship types which are for specific sites
  • [MBS-6233] – Ensure SecondHandSongs links are added at the right level
  • [MBS-6300] – Link to countries in country statistics
  • [MBS-6301] – Consider linking to areas {artist,release,label} list in country statistics
  • [MBS-6347] – Show parents somehow for underlying areas
  • [MBS-6358] – Add basic area stats display
  • [MBS-6362] – Improve how release data is displayed in Google searches
  • [MBS-6371] – Extend Wikipedia and Wikidata autoselect to areas

New Feature

  • [MBS-6269] – Expose track identifiers in the webservice
  • [MBS-6270] – Expose track identifiers on the website

The Git tag for this release is v-2013-06-10.

New Guidelines for Recordings

We got this from Ben, who has been in charge of taking this discussion forward:

Since the beginning of the year there has been a lot of discussion about recordings and what exactly they should be used for. After several meetings on IRC and a couple of huge topics on the style mailing list, we’re finally ready to bring in a new definition for recordings, and new style guidelines to go with it!

The new recording definition can be viewed at http://musicbrainz.org/doc/Recording

And the accompanying style guidelines are at http://musicbrainz.org/doc/Style/Recording

The new guideline brings significant changes to the way recordings should be used, so all editors dealing with recordings should take the time to read it.

As a short summary, recordings are now never produced solely through copying or mastering. This means that recordings shouldn’t distinguish between different masters of some audio – in general, a recording will correspond a particular mix or edit. In addition:

– AcoustIDs and ISRCs have been removed from the guideline – they are mostly irrelevant for managing recordings under the new definition.
– Guidelines for audio channels have been introduced.
– Existing guidelines have been expanded.
– Several in-depth examples have been added to explain how recording should be used.

Also, as a result of these changes, the recording-recording remaster relationship type and the artist-recording master relationship type have been deprecated.

Thanks to everyone who was involved on mb-style and in the IRC meetings for your excellent ideas and contributions!