MetaBrainz Foundation Community Blog
Google has announced that Summer of Code will be happening again. We’re in the process of applying to participate again and I could use your help in coming up with some ideas for Summer of Code. Please take a look at our as of yet blank ideas page and add new ideas of your own.
Thanks!
Sander van Zoest and Dan Brickley have been prodding me to officially post about Flickr Machine tags — using Flickr machine tags you can now tag your photos on Flickr to refer to specific MusicBrainz entities. This is how to create MusicBrainz machine tags on Flickr:
For more details see the official wiki page: FlickrMachineTag
In working on figuring out how to integrate UserVoice into our workflow its become painfully clear that we need to have some people take “ownership” over a few portions of MusicBrainz. Back in the day when Cristoph König (Don Redman) was our Wiki warden, our wiki was well groomed and worked smoothly. Alas Cristoph has been swallowed whole by a University in Germany and we may never see him again. 🙁
Its time to find volunteers who are interested in taking on personal ownership of these aspects of MusicBrainz. I’m looking for 2-4 volunteers, one for each of the following areas described below. However, please note that these people are not expected to carry out the bulk of the work that needs to be done to get these projects into an improved state. I envision each of these people being motivators and leaders who can focus and encourage the efforts of other volunteers to help them achieve their goals — there is a big difference between a leader and a workhorse.
I’d like to stress once again that I am not looking for people to do a lot of work — I’m looking for leaders who can do a little work, but motivate others a lot of help out and create a thriving sub-communities that allow MusicBrainz to become more concise and cohesive. If you’re interested in one or more of these positions, please post to the comments.
A few people have been commenting on how MusicBrainz has a few bugs that bother them on a daily basis, yet these bugs are never fixed. From a developers perspective its really hard to see which bugs in our large bug list really matter to end users — its hard to figure out which bugs should be fixed first. Rather than fixing the bugs that affect most people first, developers tend to fix the bugs that have the most insistent users shouting for those fixes. Unfortunately fixing bugs for overly vocal users may not be the same as fixing bugs that will improve life for the most people.
Warp suggested that we check out Get Satisfaction, while others suggested using UserVoice. Both of these services provide an intermediate layer between the developers and the end users to provide feedback about the bugs that are important to them. End users can enter the bugs that bother them and everyone can vote on those bugs/issues. While we already have a bug tracking system, this system is geared to the less technical users out there — not everyone loves entering bugs into trac. Plus UserVoice’s voting mechanism allows the most important bugs to rise to the top of the list.
I’ve explored UserVoice a little since they offer a free plan for Open Source projects. (Not to mention that their site is in Orange, which is a big draw for me. 🙂 ) It seems that it would be easy to integrate this with MusicBrainz. But, it seems that this is one more chore for someone to manage and the last thing I need is to take on another chore. I’m willing to do the technical integration, but I would need some help from volunteers to manage the day-to-day operations of UserVoice. I envision volunteers to pay attention to the data that collects at UserVoice and maintain a mapping between UserVoice issues and actual bug/enhancement tickets inside the MusicBrainz bug tracker. If you already play with trac and help us maintain it, this might be another aspect in which you could help MusicBrainz.
I’d like to know:
Please let me know in the comments!
I come bringing good news! With the latest version of the server now out in the wild, we’re ready to move on to the next stage of MusicBrainz development. But first a quick refresher…
You may recall, many moons ago I (Oliver Charles aka aCiD2) began work on moving the mb_server codebase from our own in-house framework, to the tried and tested Catalyst framework – along with separating out the HTML into separate Template Toolkit templates. Well, after what seems like an age, it’s finally got to the time where I can start getting some critical feedback from the most important people – you!
As from now, test.musicbrainz.org is now running the development branch of this work. It’s important to realise that this new codebase currently has no javascript support. This decision was made because it’s very important we get the website fully functional, and then add bells and whistles on later. We’re starting from a mostly clean slate, so there’s a lot of chance of things breaking, and JavaScript was likely to be just one more headache.
Oh, and I’ve never deployed a server like this before, so please bare with me while I work out any problems running the server. I’m going to London tomorrow and coming back Saturday evening (slightly bad timing, I’m aware) – but I’ll do my best to check any messages that come my way!
However, before you jump straight in and overload us with work – I’d like to lay down some guidelines for providing us with feedback. This will (hopefully) ensure that we can see to these bugs as fast as possible.
Where to report:
Standard practice- report at our bugtracker – bugs.musicbrainz.org
What should you report?
The most important things to report are actions that cause errors to occur, invalid behaviour or features that are simply not available, but are from the main server. You should also report typos and other visual problems – but I will be encouraging people to help fix these themselves (more on this later!).
What information should you provide?
The most critical information is that you can provide us with as much context as possible. Please let us know:
The last point relates somewhat to Catalyst. Catalyst features improved error handling and can provide us with a stack trace. You should try and include this stack trace, and the errors at the top. Chances are, we’ll be able to reproduce this from the information you provide – but if not, the stack trace gives us one more pointer to where the problem is 🙂
How should you organise the report?
Generally speaking, just try to fill in as many of the fields as possible. I’ll be reading every single report that comes in, and re-filing it myself where necessary. Ideally, set the component to ‘MusicBrainz’, the milestone to ‘Server: TemplateToolkit’ and assign the bug to me 🙂
So…
Thanks to the tireless efforts of Matthew Wood, the BBC has officially hired Jason Emmett to work full time on the MusicBrainz server!
Jason, who will be working in the BBC offices in London will be working with Oliver to finish the port to Template Toolkit branch. After that both of them will tackle the Release Groups that we’ve deemed to be a worthy intermediary step. A few weeks ago the MusicBrainz server had only table scraps of love, moving it along quite slowly. Today we have nearly 1.5 full time people working on the server source code. This gives me tons of hope that we can shoot for doing 3-4 releases in 2009.
Thank you so much for all of your efforts, Matthew Wood. Thank you for all of your support BBC! Welcome on board Jason!
Eight years ago today, I checked the very first version of MusicBrainz into CVS and thus marked the birth of this project.
A big fat thank you goes out to all of the people who have made a vast difference since that day 8 years ago. Without your help MusicBrainz would not have come so far!
THANK YOU!
I’m pleased to announce that Jim DeLaHunt is our new style leader!
After chatting with tons of people, it appears that no-one has any objections to Jim being our new style leader. Jim will be working to improve the style process and to get stuck proposal moving again. Expect to hear much from Jim in the coming weeks as the revamps our style process. If you’re interested in taking part or observing the improving style process, please subscribe to the MusicBrainz style mailing list.
Wendell and Sergey from MusicIP have done another crawl of Wikipedia — this time the goal was to match up releases in MusicBrainz with Wikipedia pages that exist for those releases.
Just like last time the results have been broken into convenient chunks of 100 with the proper links to let people verify the matches and quickly enter them into MusicBrainz.
If you’re interested in helping, please follow the instructions on the wiki and jump in!
Thanks!
We’ve recently seen a rise in Sock Puppets here at MusicBrainz. We’ve observed editors creating separate sock puppet accounts who vote through the edits of the editor in order to get changes through MusicBrainz faster. This practice obviously side-steps our peer-review system, and up until now we’ve had to have other editors go through and follow the trails of naughty editors to clean up after them.
To avoid this from happening continually, we’ve update the main server with a minor patch that requires people to have more than 10 approved edits in order to vote on other people’s edits. This makes creating a sock-puppet account much harder — each sock puppet account created will need to have a lot of work invested in it before it can be useful. We’re hoping that this simple tweak will discourage sock puppeteers.