Transparent communications

In the past few months I’ve tried to re-iterate that MusicBrainz is an open source project and that open source projects should carry out their work in public whenever possible. I received quite a bit of push-back every time I suggested this, so I feel it necessary to reinforce this concept.

I’ll reference the “Producing Open Source Software” book and in particular the Chapter 2:

Even after you’ve taken the project public, you and the other founders will often find yourselves wanting to settle difficult questions by private communications among an inner circle. … All the obvious disadvantages of public list discussions will loom palpably in front of you: the delay inherent in email conversations, the need to leave sufficient time for consensus to form… The temptation to make decisions behind closed doors and present them as faits accomplis, or at least as the firm recommendations of a united and influential voting block, will be great indeed.

Don’t do it.

If this sounds familiar to you, it should. Sadly this has been happening inside our community for some time. I am now going to put my foot down and insist that communication about the project happen in public. Since I will be setting the dev tasks and will be working to establish a rough road-map for the project, I’ll know what level of communication is appropriate for the current tasks at hand. And I’ll be watching for signs of this improving!

I am going to set an example and keep my communication visible to the public if at all possible. Some things are private matters (pay, personal issues) that should not be discussed in public and I will not discuss those in public — there is no change for private topics. But for all other topics, I am going to insist that we discuss matters in a public channel where the community can follow along. So, if you send me a private message in IRC or a direct email, expect me to ask you to move the discussion to a public forum if the communication really doesn’t need to be private. As a guideline, I would expect about 98% of the project communication to be public.

In the coming weeks I am going to define the various roles that people hold in MusicBrainz and then document them on the spiffy new MetaBrainz web site. If you plan to take on any role in MusicBrainz (or any of the MetaBrainz Foundation projects) I will require that your communications be transparent. Please keep this in mind as I work to bring some clarity in the project.

I would really recommend to everyone that they read all of Chapter 2 linked above — it makes a lot of solid points that are very important to our project right now.

A positive outlook going forward

My next installment of MusicBrainz management changes focuses on how we should frame our discussions going forward. Currently there is a lot of animosity in our community and a lot of finger pointing — neither of these are constructive for moving forward, so I will aim to cut these short and focus on fixing rather than blaming.

I’d like to offer an analogy to start this discussion: When two people are in a personal relationship and when that relationship starts falling apart, a lot of negative feelings come up. The two people will often blame each other and be convinced that the other person is the reason for all of their troubles. If you’ve ever had an opportunity to talk to two people in a failing relationship, you’ll probably have seen that failing relationships are usually the fault of both people. I’ve yet to find a relationship that failed, solely on the actions of one person alone. Both people are involved, both people had a hand in it.

That said, I’ll step forward and say it: I am guilty. I am partially to blame for what is going on. Go ahead, feel free to blame me for the troubles we’re facing.

But, that is it. Basta! We’re not going to engage in finding every little thing that was done wrong, by whom and work hard to lay blame. That is pointless and it brings up unnecessary emotions. Instead of finding blame we’re going to find problems to our solutions and we’re going to move forward.

As part of me restructuring MusicBrainz, I’m going to be asking everyone what problems they perceive with the project right now. I will listen to the problems, catalog them and attempt to build a plan for tackling these problems in the future. However, I will insist that problems are stated without aggressive communication (e.g. passive aggressive communication) and without value judgements. If you cannot state your issue without being aggressive or disrespectful, you can count on me calling you on your behaviour. I will not address problems that are stated in an aggressive or disrespectful manner.

For instance, it is not acceptable to say: “I don’t think that anyone is going to listen to me anyway, but I think that because of Joe’s idiotic decision to not allow white space in code, all of our code is a freaking mess — this was the worst idea ever!” This statement has passive aggressive communication, it lays blame and contains a value judgement. One way to express the same concern in a constructive manner could be: “The decision to exclude whitespace from our code has created a number of difficulties for people to follow our code. We should re-consider this decision.”

This means of expressing problems, ideas and solutions allows us to focus our energy on moving forward and improving the project. It avoids painful discussions that won’t gives us much insight on moving forward. As we work to mend our community, I will be relying on these communication tools heavily. If you run afoul of these new communication guidelines, expect me to remind of you of this blog post. 🙂

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:

  1. 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.
  2. 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.

More posts are coming in the next few days!

Team change

Ian (ianmcorvidae), our senior developer on the MusicBrainz project, has decided to leave the project due to personal reasons. I’m sad to see a very skilled engineer leave our team — Ian has done a tremendous amount of great work for MusicBrainz and the MetaBrainz hosting infrastructure. Thank you for all of your hard for in the past few years, Ian!

Ian will remain on our team while he seeks a new professional position, so the change won’t be immediate. That said, now is the time to ask Ian to document whatever pieces of his work that still need documentation.

If anyone knows an experienced perl developer with experience using web technologies, Postgres and the myriad of technologies that MusicBrainz uses, please let us know! I’ll be posting an official job posting next week.

Server update, 2015-07-13

This update contains bug fixes and improvements the new tag voting interface, thanks to feedback from people during the last couple weeks. The plus/minus buttons simply add or subtract 1 from the current score (and are disabled where you’ve already done that). There’s still room for improvement, but hopefully it should be more intuitive now.

We’ve also made duplicate entity detection more immediate—the interface will show you possible duplicate artists, labels, etc. before you submit anything.

Thanks to Nikki and the MetaBrainz team for their work on today’s release. The git tag is v-2015-07-13 and the changelog is below.

Bug

  • [MBS-8322] – Editing entity (now) removes its URL relationship dates
  • [MBS-8434] – Work editor can’t seed both relationship type and target
  • [MBS-8463] – Adding a tag with upper-case letters on the tag page has funny behaviour
  • [MBS-8470] – Bulk tag submission doesn’t work if the same tag appears in different recordings

Improvement

  • [MBS-2873] – In add relationship edits, always display the URL second
  • [MBS-8331] – Move some of the duplicate entity check code to the client
  • [MBS-8464] – tag voting interface doesn’t make sense if you don’t use reddit