Author Archives: ruaok

Code of Conduct overhaul


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.


Welcoming Rassami Hok Ljungberg to the MetaBrainz Board of Directors

I’m pleased to announce that Rassami Hok Ljungberg of 2Pears, the organization that puts on the Music 4.5 seminar series, has joined the MetaBrainz Board of directors! Rassami is well connected in the music scene in Europe and has an extensive network of contacts in the music industry. Rassami has already been informally helping spread the word about MusicBrainz and its related projects for the past couple of years. I’m quite pleased that I get to work with her more formally now — welcome Rassami!

Rassami replaces outgoing board member Brian Zisk. Brian has been a board member for over 9 years and has done amazing things to help raise the visibility of MusicBrainz and to generally support our projects. Thank you for all of your support over the last 9 years, Brian!

I find it interesting and lovely that we’re swapping one amazingly connected maven who puts on music conferences for another amazingly connected maven who puts on music conferences. This is a conservation of mavens, while at the same time increasing the diversity of our board of directors.

Win-win! Thank you Brian and Rassami!

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:

  1. Edits that makes things better (perfect or not)
  2. Edits makes things different (but neither are better)
  3. Edits that contain some correct things and some incorrect things
  4. 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!

Service downtime to fix some database issues

This Friday we’re going to need to take a 15-20 minute downtime to fix a few leftover issues from our recent schema change. We tried to do this without downtime, but the service got progressively slower, so we’re electing to take some downtime.

We’ll be down shortly after Noon PST, 3PM EST, 20:00 UK, 21:00 CET for about 15-20 minutes.

Sorry for the hassles this causes.

Downtime for fall schema change

Our next schema change version will be released on Monday, 17 November, 2014 around Noon PST/3pm EST/20:00 GMT/21:00 CET. We expect that MusicBrainz will be unavailable for 30 – 60 minutes during this time. We will put up the downtime notification on the site and tweet from @musicbrainz right before the release.

Sadly, our backup database server suffered a hardware failure and we ran out of time to get a replicated database setup after the hardware was fixed. This means that we won’t be able to put the site into read-only mode and will require us to take a full-downtime.

It sucks and we’re not happy about it either, but there is only so much we can accomplish with our limited resources. :(

Sorry for any troubles this may cause you.

Changes to our style process

At the MusicBrainz Summit last month in Copenhagen, one of the topics to
be discussed was the state of the style guidelines and style process.
One thing those present agreed on was that the process was in need of
reform, for several reasons: the complexity of the process,
inconsistency with other processes in the project, the high level of
individual commitment required to make changes, long-running discussions
without conclusion or followthrough, and ultimately the state of the
final product, the style guidelines themselves. The inaccessibility of
our existing process meant that many users, both new and old, avoided
the style process, and this hurts the project: style is part of what
makes MusicBrainz what it is, and low participation means our guidelines
have grown both internally inconsistent and out of sync with community
practice. Nor is the style process a new problem for MusicBrainz:
historically, it’s changed several times and some past style leaders
have vanished into thin air.  After all, it is a hard job, for a
volunteer, to convince many voices to come to a consensus.

To improve upon these issues, we’ve decided to make two major changes.

First: to designate our JIRA issue tracker at as
the central coordination point for style issues. This way, any issue, be
it style-related or code-related, is reported and discussed in the same
place (and should an issue be misfiled, it’s easily corrected). The
issue tracker can also collect links to other discussions, in edit
notes, the forums, IRC, etc., and store links to related issues such as
features in need of implementation.

Second: to promote our current Style Leader to Style Benevolent Dictator
For Life (Style BDFL). Nicolás Tamargo (reosarevok) will then be in
charge of considering tickets and implementing changes in the style
guidelines. This change shifts the burden of evaluating style issues
from the community to our newly appointed BDFL. For simple changes and
for simple improvements to consistency and writing style, the BDFL can
change things directly, without need for lengthy discussion. Of course,
his work won’t happen in a vacuum: for changes that are complex or
contentious, the role of the BDFL will be to gather feedback and
determine the next steps before making changes. To this end, he may
occasionally call for a non-binding vote on a particular topic, to
collect a snapshot of community opinion to augment existing discussion,
all in order to make a better informed decision.

We hope that this new process will make contribution to the creation of
style guidelines easier and less onerous a commitment for everyone, and
that the resulting style guidelines will be more up-to-date, more
consistent, and more clearly written and organized. To test it out,
we’re going to try this process for 6 months, and then review how things
have progressed and if the process needs further tweaking or even
complete replacement.