MetaBrainz Foundation Community Blog
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!
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!
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.
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:
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.
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!
Based on the feedback we’ve collected over the last few months, we’ve updated our privacy policy and made it live on our site.
For the history of how we arrived at these changes, please see this blog post and previous posts linked in that post.
UPDATE: If you’d like to see what changed, take a look at the diff of the page.
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.
We’ve been scheduling more meetings for discussing various complex topics, but communication about those dates has not been clear. In order to fix this, we’ve created a community curated calendar:
http://calendar.musicbrainz.org
reosarevok, nikki, ian, ollie, warp and myself can put things onto the calendar. If you have something you’d like to have added to the calendar, please ask one of these folks.
Recently we’ve received two bug reports that point out two inconsistencies in our privacy policy:
If you care about our privacy policy, please take a moment to read these bugs and comment on them. Thanks!
As you’ve probably seen around the net today, Aaron Swartz, Internet Hero has committed suicide.
Aaron Swartz has spent most of life working to improve the Internet and to preserve freedom on the net. Many people are speaking to his awesome accomplishments in the last 10 years of his life, but I’d like to take a minute and reflect on his earlier years.
I was one of the fortunate people who met Aaron when he was still 15 — we first met up in Washington DC for O’Reilly’s P2P conference. Since he was a minor, his mom was accompanying him. Never mind that she had a broken leg at the time — she was so dedicated to her son that she traveled with him to allow him to participate in things that most minors couldn’t even imagine.
Before I met him in person, Aaron was an active contributor to MusicBrainz. When I started my first mis-guided attempts to create an RDF based web-service, he worked with me to improve the schema. He helped me understand RDF (damn that RDF spec!) and helped me fix the schema until it actually worked properly. Aaron was always looking for new and interesting things to do, so once his mission with MusicBrainz was done, he moved on to bigger and better things. And the things he did — simply amazing that one person can accomplish so much in so little time.
Aaron and I shared one passion — making data open and accessible. His means were always more aggressive than mine; he often chose the faster, more risky approach. I usually favor the slow-and-steady-will-win approach. Regardless, the events that led up to his suicide leave me deeply unsettled about the current state of affairs.
Aaron, thank you for being the instigator, shit-stirrer, advocate and dissident you were. I appreciate everything you’ve done during your short stay here in this troubled planet. May your next journey be more peaceful!
Thank you to Cory, Larry and Brewster for your kind words.
UPDATE: Here is a link to the paper Aaron wrote about MusicBrainz.
Last weekend approximately 20 dedicated MusicBrainz fans and customers all got together at Universitat Pompeu Fabra, Barcelona to discuss all things metadata. Now that the weekend has passed, and everyone is back at their respective homes, I can fill you in on how this fantastic summit went. We talked about a lot of topics at the summit, and I encourage you to read the extensive notes that Ian took (a huge thanks!) if you’re interested in all the details.
Friday was a lazy day while people arrived, but we did spend a bit of time at the summit venue. We got an introduction from Music Kickup – a new Finnish startup which offers a cloud based record label for artists. Spotify presented their ingestion process, which was helpful as at MusicBrainz we’re beginning to plan the new Ingestr project.
On Saturday we got under way with the summit proper. Brewster Kahle from the Internet Archive spoke on how the Archive works, and its plans going forward to try and archive even more about music. The general motivation is to provide listeners with more ways to explore and discover content, and the Archive are looking for ways that MusicBrainz can help with its linking its metadata to the Archive’s content.
Next, we moved on to discuss the Artist Image Archive – or more generally, adding more images to MusicBrainz. The conclusion was here that this is certainly a wanted feature, and we would like to try and use Wikimedia Commons to store public domain/CC-licensed artwork and fall back to the Archive for other content. We also lightly talked about adding label images, and the Archive are again happy to host this content if that’s needed.
While waiting for the full CompMusic team to be present, we outlined Ingestr, a forthcoming MusicBrainz tool to work with dumps of metadata. CompMusic then presented what they are working on, and how it ties in with MusicBrainz. They are currently storing some data outside the MusicBrainz schema, but would love to store as much as possible inside our database (and we’d love that too!). They are interested in adding more information to works, such as ragas and talas for Indian classical music.
The final topic on Saturday was to try and get some ideas going on how we want to store events, locations and venues inside MusicBrainz. No conclusions were reached here, but there was a lot of excitement and considerations and what we want to store, with the suggestion that some of this work might make a fantastic Summer of Code project next year.
We picked up on Sunday, and dived straight in with a discussion on bringing multiple release countries/release dates back to single releases, with a consensus that this should be done. Work here will probably resume in February, with the next schema change.
Dynamic work attributes were next on the agenda, and we sketched out a plan on how we can add new attributes to works that don’t depend on schema changes. This should allow us to add ragas and talas for the CompMusic folks, but also many other interesting properties. Again, work on this one is looking likely to begin again for the next schema change.
Much like Summit 11, the instrument tree came up again. People were in agreement that we want richer data about instruments, and making them entities that can be used in relationships (including between instruments) is probably the way to go.
nikki outlined her proposal on data quality, and we all spent a bit of time discussing what we’re trying to achieve with data quality, how to overcome the social problems with the word ‘quality’, and so on.
Warp bought up the problem of capturing series of releases in MusicBrainz, and we discussed how to solve this problem (for example, consider the ‘Dubstep Allstars’ series of releases). We agreed that the best way to move forward is to introduce the idea of ordered series, and deal with unordered series later.
The difficult topic of box sets came up, and while we didn’t make a clear decision on how to solve this problem, people had the chance to explain solutions as they see them, and everyone has a good understanding of both the challenges of box sets and the information that we’re trying to capture.
Like in Summit 11, we once more discussed the hard problem of genres, as these have become something that customers are increasingly requesting. We outlined all the various solutions that other projects use (such as SoundCloud, Music Kickup, and SoundUnwound). This topic didn’t reach any type of conclusion, but it was good to have some cross-pollination of ideas.
We wrapped up the day with some social topics, and ocharles started a discussion on how we can better promote ourselves and communicate our new features. There was a lot of energy in this discussion, but some of the key ideas were – more community interaction on blog posts, a clear ‘checklist’ of what to do when we release big features. kepstin also volunteered to look at rewriting the landing page with something more interesting than the static page we currently have.
The summit has proven once again to be a fantastic experience, not just for the quality of discussions, but also the level of interaction between participants. With the Saturday group meal, socialising at the apartment and continued discussions during breaks at the summit itself, it was great to see people chatting, laughing and generally having a great time.
Thanks to everyone who came for making the summit what it was. We hope to see you all again next year!
MusicBrainz will be attending the Google Summer of Code mentor summit, and we’d love to have some stickers to hand out, so our fellow open-source friends can show off how cool we are. Sadly, we don’t have the skills to actually make the designs to send off to get printed… but that’s where you come in!
Do you do graphic design? Do you know someone who would be willing to help us? If so, please get in touch with us – leave a comment, tweet us or shoot an email to info@musicbrainz.org. Thanks!