Community – Page 5 – MetaBrainz Blog

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. 🙂

Code of Conduct overhaul

Hello!

Our Code of Conduct is probably over 10 years old and hasn’t had much of a review over time. I’ve heard various complaints about it in the past few months, so I’d like to start a general discussion about it:

What do you like about the current version?
What do you hate?
What is outdated and needs to be removed?
What is missing and should be added?
Do you even think that it needs an overhaul?

If you have any comments, please post them below. Your comments will determine my next actions on this project.

Thanks!

Editing: Making MusicBrainz better

Over the past few weeks I’ve received a number of emails from people who are concerned about some editors who are losing sight of some basic principles behind editing data in MusicBrainz. I wanted to chime in and remind people of some of the principles that should guide how we all get along when we edit data in MusicBrainz.

First and foremost is:

Be polite and give people the benefit of the doubt that they are doing the right thing.

I don’t have to explain being polite. Yes, we all have our bad days — that is a given. But if you’re having a bad day, stop editing MusicBrainz and step away from your computer. Go outside! When you do edit, please be kind to your fellow editors.

Giving people the benefit of the doubt that they are doing the right thing is also important. The vast majority of people who edit MusicBrainz have good intentions and you should assume that to be the case.

Second, edit to make the database better. Vote yes if an edit makes the data better.

This one is a lot more vague, since “better” is a subjective term. We should accept edits that are “good enough” and avoid asking people to make “perfect” edits.

Edits fit into four categories:

Edits that makes things better (perfect or not)
Edits makes things different (but neither are better)
Edits that contain some correct things and some incorrect things
Edits that are outright wrong (existing data is better)

The first type should clearly get a yes vote. For the second, if it doesn’t make things worse, abstain and leave a comment. The third is a judgement call and I would suggest applying this heuristic:

Unless it takes more time to fix the edit than to make a new one, vote yes.

Clearly, the fourth type deserves a no vote.

That brings me to the final topic for now: No votes. A no vote is a very strong expression that has potentially chilling effects that may prevent people from editing again. A no vote should be considered the last resort. Use a no vote if you can’t find another way to resolve an edit.

Finally, some tips for auto editors: If you see an edit that is not perfect, approve it and fix it.

Auto editors are supposed to set the tone for the project and auto editors should practically never vote no on something. You have more powers than fellow editors, so please use your powers for good!

Thanks and happy (and polite) editing!

Looking for someone to represent MusicBrainz Music Hack Day Boston

Music Hack Day Boston is happening on Nov 8-9 and I am looking for someone to attend and represent MusicBrainz/CritiqueBrainz there. Ideally this person would be knowledgeable about how our Web Service works, what data MusicBrainz has and how our schema is laid out. You must be comfortable giving a short (~5 minute) presentation about MusicBrainz/CritiqueBrainz at the beginning of the event. And you should also be comfortable answering questions during the event.

If you live in or near Boston and are interested in helping out and attending MHD Boston, please leave a comment here and I will get in touch.

Thanks!

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.

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!