Restructuring MusicBrainz’ management

In the recent past, the MusicBrainz community has become more fractured with evident tension rising between members of the community, the dev team and myself. I’ve been struggling with trying to find a good way to fix these problems and I’ve attempted making a number of changes over the past few months. Mostly with mixed or bad results, which further increased the frustrations for everyone involved.

While I was on vacation the past two weeks, I had some distance from work and at random points during this vacation a few key issues/solutions became clear to me. Over the next few weeks I will be announcing changes to how I manage this project and possibly some changes to some of our core policies to support these changes. Stay tuned on this blog for more announcements regarding this restructuring.

In the first round of changes, which I will detail in a subsequent blog posts, I would like to:

Re-emphasize that we are an open source project and that we must do all of our work in public. Point 3 of our social contract states: “We won’t hide problems and policies: We will keep all MusicBrainz related discussions open for public view at all times, regardless of their content. All problems and policies related to MusicBrainz will be visible to all.” As problems in our community grew, factions hid from the public view. A lot of development work and development discussion went underground in private communication channels that had no transparency at all. Fixing this will be my most important goal moving forward.

Take control of tasking the development team. Starting this monday, during our weekly development chat, I will take the lead on discussing what tasks the development team should be focusing on. I will need to catch up on a lot of happenings that I haven’t paid attention to recently. I also suspect that we will need to talk quite a bit about which tools we would like to use to manage our short, medium and long term plans. Don’t expect us to magically revamp this process on Monday — Monday will simply be the first step in what could be a long journey to improve how the MusicBrainz dev team is currently managed.

Given one of the most-requested (and complicated) features, credits for relationships, was recently added, I’m not sure how “real world issues” aren’t seeing development time. Quite a few other issues there are hugely complex (alternative tracklists, webservice editing, 3-point relationships), or basically depend on similarly complex changes like making edits reversible (image replacing). I’d personally like to see reverting edits as a priority, but in any case, a fair amount of those features there need months of dev time so there’s just no way they can all be done quickly with our resources – it’s not just a question of saying “ok, we’ll do all this now” 🙂

Yes, there have been huge features recently (as always been, should I have said). And yes, AC on AR was part of this top 10.
On this topic I was made aware that I had been a cause of some frustrations in the team. I say again that I am sorry for this and I don’t think I am doing bad things with mean intentions. I apologise to people I may still Irritate without any intention of doing so.

Comments here about tickets highlight that something isn’t working (as well as it could) in MB.

It’s not clear where discussion should take place.
It’s not clear if opinions are taken into consideration.
It’s not clear if/how votes on tickets influence development.
It’s not clear where I should ask the above questions.

CallerNo6: You’re spot on in your comments, but as mentioned in my post: “Don’t expect us to magically revamp this process on Monday”. My following blog posts will answer some of your questions, while others will take time to unfold as I listen to the community and work out the right path forward. Right this second, please collect your questions and hang on for a bit as we work through this process.

I am open for suggestions on where to collect this info in a public manner. An OTHER- ticket? A google doc?

(I am also working hard to avoid a “wall-o-text” communication, which would be useful to telling everyone everything, but is hard for most people to consume. Thus one step at a time)