Category Archives: Community

MHD San Francisco 2014

MusicBrainz is represented at Music Hack Day San Francisco 2014 this weekend!

If you’re a hacker who is participating, this page collects a number of interesting things about MusicBrainz that lets you get started with MusicBrainz easily.

If you’d like some help with MusicBrainz, come see Rob in the the back of presentation area. Rob is the guy with the crazy hair and the bright orange t-shirt.

Have fun!

MusicBrainz Meetup: Chicago, IL, USA, 25-26 January 2014

In case the name didn’t tip you off, this is rather more casual of a get-together than our usual summits, but for those of you with the inclination, a free weekend and a decent way of getting to Chicago: we discovered that our fearless leader Rob was going to be in the same city as one of our developers (bitmap) and figured we’d fly me (the other developer) in too and make a thing of it! We’ll be hanging out in-person through January 25-26, plus probably part of the evening of January 24th, and we’d love to have you join us.

We don’t have much by way of details, at present, in part because this is quite informal. However, if you’re interested, we have a wiki page with arrival times for those of us with plane tickets already, and which we’ll update with any other plans we end up making. If you’d like to come, please add yourself!

The BBC unveils a service that tweets to artists when their music is played…

… and it is built using MusicBrainz data! Michael Smethurst, a good friend of MusicBrainz, hacked up this service in the space of 2 days and writes:

The original idea came from a friend whose music occasionally gets played on Radio 1, 1xtra and 6Music. Almost always he missed this and either found out later from a friend or never found out at all. But he does use various bits of social media (including Twitter) to make contact with fans and promote his releases and live appearances.
. . .
To power online music services such as BBC iPlayer Radio, Playlister and /music the BBC uses metadata provided by MusicBrainz, a community maintained music encyclopedia. If you use Twitter and you’re a music artist or an agent or a publicist or similar and would like now playing notifications you need to check that your Twitter account handle is in MusicBrainz.

Thanks for creating such an awesome service, Michael. I know MusicBrainz contributors love how the BBC uses their data — I wish more people made such creative use of our data!

Fire damages the Internet Archive

A fire at the Internet Archive (our friends!) has caused $600,000 in damage. Fortunately no one was harmed and no data was lost:

A fire at the Internet Archive’s San Francisco scanning center has destroyed an estimated $600,000 of digitization and scanning equipment. Fortunately no one was injured in the blaze, but the property damage has ruined “some physical materials” that were yet to be digitized, and restricted the nonprofit organization’s ability to record the history of the web.

MusicBrainz just donated $50 to the Internet Archive and asks you to consider making a donation as well.

MusicBrainz Summit #13

Over the weekend, 17 MusicBrainz fanatics got together at WikiMedia’s German headquarters to discuss the immediate future of MusicBrainz. And in short – we had a blast! A tremendous amount of topics were covered, and we feel this was one of the most productive summits we’ve had so far. From genres to acoustic properties, to internationalization, to artist & label artwork, an incredible amount was discussed.

MusicBrainz Summit #13 Atendees

From left to right: ijabz, CatCat, ianmcorvidae, reosarevok, ruaok, navap, santiissopasse, Anders Arpteg (Spotify), LordSputnik, ocharles, warp, fractalizator, Freso, Mineo, kepstin, JonnyJD

A summary of all topics covered and points discussed can be found on the wiki, with thanks to diligent note taking by everyone who attended. As you’ll see, a lot of topics are now actionable, so hopefully work will begin to move forward with these. While it remains unclear what the solution is to some topics, the constructive conversations around them is helping us slowly move forward in the right direction.

Of course, it wouldn’t be a MusicBrainz summit if it was work work work – there was plenty of mayhem and play too! On Saturday we had our summit meal at Max & Moritz – complete with a police escort due to some unfortunately timed protests. A novel twist for a group meal… yet oddly consistent with the fresh and unpredictable nature of MusicBrainz.

ruaok takes a hard earned break... on Freso!

ruaok takes a hard earned break… on Freso!

We also want to thank our sponsors who made the summit possible. Thank you to Spotify and Google’s Open Source Programs Office! Your support paid for some airfares, our lodging, summit meals and a large pile U-Bahn tickets. And of course, a big thanks also goes to Wikimedia Germany and in particular to Lydia Pintscher for baby-sitting us all weekend and also for making awesome introductions to other people to help with specific summit topics.

Thanks again to everyone who attended. Until next year!

New MusicBrainz EU download mirror

With the help of Freso and then generous support from Denmark based open source hosting provider dotsrc.org the MusicBrainz downloads (data and apps) are now available in the EU (FTP too!).

This should make data downloads quite a bit faster than trying to download them across a trans-atlantic link.

Thank you very much to the folks at dotsrc.org for setting this up and hosting it and for Freso for making this connection!

MusicBrainz Summit 13: Berlin, Germany 21 & 22 September 2013

After we were not able to confirm space in our previously agreed city, we started looking for alternative places to host our summit and Wikimedia Germany in Berlin graciously agreed to host us!

This means that we’re going to hold our annual MusicBrainz summit at Wikimedia Germany in Berlin on September 21 and 22. However, please note that space is limited to 20 people, so if you’re interested in attending, please sign up as soon as you can!

Please take a look at the summit wiki page and then add yourself to the appropriate places in that page if you’d like to come.

I’m looking forward to seeing familiar and new faces!

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!

Updating our privacy policy

A number of bugs have been piling up pointing out inconsistencies in our privacy policy. We’ve realized that the existing privacy policy is quite brittle with respect to our fast paced server development cycle. I’ve edited the privacy policy in an attempt to future proof the policy while not eroding anyone’s privacy. The revised policy has already had some community review and now I would like to cast the net to a wider audience for review.

However, I would like to set the stage carefully here: This is not a call to re-write our privacy policy or to nit-pick it to pieces. I am trying to nail down the open bugs and ensure that our privacy policy reflects our current actual activities. So, unless you find an actual problem that needs to be addressed, I am not likely to make any further changes to the revised policy.

That said, here is the list of bugs I’m trying to close: MBS-5708, MBS-5709, OTHER-144, OTHER-145, MBS-5942, MBS-5948.

Here is the new privacy policy that should fix the bugs above. Compare that to our current policy and also have a look at the diff of the wiki markup between the two pages.