The problem

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!

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:

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.

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.

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)?

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 😉

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.