Category: Community

Recap of the MusicBrainz Summit 15

The MusicBrainz Summit 15 participants.
From left→right (top) chirlu, reosarevok, ruaok, Freso, (bottom) Leftmost, alastairp, Gentlecat, bitmap, zas, and LordSputnik. Special guest on the laptop monitor: caller#6.

A couple of weeks ago (Oct. 30th through Nov. 1st), the MusicBrainz Summit 15 took place in Barcelona, at Rob “ruaok”‘s place. We had all of the MetaBrainz employees there, Rob/ruaok (local), Michael/bitmap (US), Nicolás/reosarevok (Spain/Estonia), Roman/Gentlecat (recently local), Laurent/zas (France), and myself, Freso (Denmark) – in addition to a bunch of other people from the community: Sean/Leftmost (US) and Ben/LordSputnik (UK), the two lead developers of BookBrainz; chirlu (Germany), long-time volunteer developer on MusicBrainz; and Alastair/alastairp (local), lead of AcousticBrainz. Between us, we represented 7 countries, 8 nationalities, and 9 languages.

Talking around the table. We managed to cover a lot of ground on the serious topics, discussing how to avoid data/MBID loss and how to version data, how to deal with labels (the entities, not the corporations…) and other unresolved style issues, how to integrate all the various *Brainz projects more and better, and a bunch of other things. The official notes for the summit is stored in a public Google Docs document. Feel free to read through and it jot down your own comments!

One of the big things was the we decided again-again-again (for the third or fourth year in a row?) to release the translations of MusicBrainz.org. But this time we actually did it! So MusicBrainz.org is now available in German, Dutch, and French (in addition to English) – go check that out if you have not done so already. 😉 At some point in the not-too-distant future™ we will also enable translating all of our documentation. Sean/Leftmost volunteered to look into options for this. Expect to hear more on that later!

MusicBrainz Style BDFL: Nicolás/reosarevok
Our Style BDFL: Nicolás a.k.a. reosarevok

We had some talk about how and why MBIDs get lost and what we can do to prevent this. As part of this discussion, we decided to make more edits autoedits for everybody. This was partly due to a wish of having a shorter queue of open edits (and there’s been a significant drop in open edits since Nov. 16!), but also very much to avoid losing MBIDs once they have been generated. More in depth discussion of the reasoning (and some of the community’s response) can be seen in the server release blog post and its comments.

We talked about a few other things like genres, reviewing the work of the style BDFL and the community manager, the future direction of the MetaBrainz Foundation, and a couple of other topics. The summit notes should contain more information on what we talked about and decided on these points.


Obviously it was not all talk and talk and talk. There was also plenty(!!) of chocolate. yeeeargh helped us by getting a lot of Ritter Sport as he apparently lives right next to their factory, and sending it along with chirlu to Barcelona. Thank you, yeeeargh! Gelato! We also managed to take in a vast amount of gelato (Italian ice cream), as there was an amazing gelato place close by Rob’s apartment. And got to walk a bit around the city of Barcelona. And have various social hanging out that only most of the time was Meta-/MusicBrainz related… but not all of it. 😉 Our system administrator, Laurent/zas, also took a bunch of pictures capturing the summit. A few of them are shown here, but you can peruse them all in the slideshow at the bottom.

Finally, a big thank you to Google and Spotify for helping to fund this meeting. It would have been a lot harder to bring all these people together from around the world without their (continued, no less!) support. Here’s to 2016 and summit 16!

This slideshow requires JavaScript.

IRC channel switcheroo

If you’re like me, you may have noticed a sudden drop in activity in #musicbrainz-devel (if you’re not like me, you may still have noticed it). This is not because we all suddenly dropped off the face of the earth (not all of us anyway), nay, we simply decided to move to #metabrainz!

#musicbrainz-devel was registered on Freenode on February 16th, 2009. That’s almost 6 years and 7 months ago! However, over the last months, it has been as much (if not more!) about AcousticBrainz, CritiqueBrainz, and two brand new members of the Brainz family (stay tuned for more news on these!) as it has been about MusicBrainz. The channel has also been home to a lot of non-MusicBrainz specific MetaBrainz talk, e.g., talk about my hire, Roman’s hire, upcoming hires (stay tuned for news on this as well!), server administration, finances, … – you get the picture. In light of this we decided to rename #musicbrainz-devel to #metabrainz, and also merge the more quiet channels of #bookbrainz and #bookbrainz-devel into this new channel.

So thank you to #musicbrainz-devel for your proud service over the years, and welcome to #metabrainz, I hope you do us just as much credit as your predecessor did! I hope to see a lot of you in #metabrainz over the next few days, to join in the celebrations with a nice virtual cup of tea or other beverage of your choice.

Sincerely,
Freso, your friendly neighbourhood community manager ❤

August Community Revisit

Ohoi m’hearties, it’s time for the first monthly Community Revisit, where we’ll revisit what happened in MetaBrainzLand during the last month. Ready for the ride? Leggo!

The primary thing happening this month has likely been the changes in the MetaBrainz employee line-up following Ian’s departure in July. In the beginning of the month, Freso (wait, hey, that’s me!) was pulled on board as Community Manager (a brand new position for MetaBrainz too!), and just at the end of the month, GSoC wonder child Roman “Gentlecat” Tsukanov was hired as the new software engineer. So hi to us two! 🙂

Speaking of GSoC, the Google Summer of Code, this year’s edition is also fast coming to an end, and our four students and their projects are closing up and giving their work the final touches to have them ready to go live. Don’t be surprised if you hear more about these projects soon.

One thing that did go live during August, in no small part thanks to Ben “LordSputnik” Ockmore and Leo_Verto: the new IRC chat logger! Chat logs from IRC are now available at http://chatlogs.metabrainz.org/ – the site still needs some MetaBrainzifying, but Ben has done a great job of importing (pretty much) all the old chat logs to the new system and the bot is running in all the official MetaBrainz channels. If you’re on IRC (or you just like poking at the IRC logs), be sure to say “Thank you!! <3” to LordSputnik and Leo_Verto next time you see them around!

Another person who has made a mark in the last month was Alex a.k.a. caller#6, starting up the discussion about the current situation of MusicBrainz’ Area entities. Be sure to check out that blog post and let your voice be heard, if you don’t feel like it’s being represented already. The next instalment should be out before long.

We also had two server updates (pretty much all bug fixes) and an updated Virtual Machine image was finally released for the more tech oriented people.

This about rounds off the August Community Revisit. What do you think about the format? Did I miss any important community happenings? Any other comments? This is a brand new venture, so nothing’s set in stone yet!

From Denmark with love,
Freso

Area editing, part I: How did we wind up here?

First, where is “here”?

The current MB-area landscape looks pretty bleak. The data is incomplete, and adding new data is a hassle.

To add an area, you need to:

  1. Create an account on tickets.musicbrainz.org.
  2. Make a ticket to request that the new area is added.
  3. Wait for an area editor to do the rest, and judging by the backlog that might happen sometime between “in a long time” and “never”.

Where did area_bot go? Why are there so few area editors? Why isn’t somebody trying to improve the situation? In short, how did we wind up here? To understand that, we need to look at where we’ve been.

Where did we start out?

By design, areas were meant to be added by area_bot, pulling data from Wikidata. The workflow would look something like this:

  • If area_bot made a mistake, there would be a handful of editors who could correct it by editing areas manually.
  • If the bot missed an area in Wikidata, you could either:
    • (if it didn’t already have a valid “type) improve the Wikidata entry, or
    • (if it did have a valid “type”) ask nikki to tweak area_bot, so that it would recognize more types.

And that worked. Sort of. For a while.

How did we get so far off course?

At some point, things started to go wrong. While I didn’t see it firsthand, what I’ve been told is this: rather than ask nikki to add more area types to area_bot’s white-list, some editors started adding incorrect area types on Wikidata, types which area_bot already recognized. So, the area would be added to MusicBrainz, but at the expense of Wikidata.

At this point, communication broke down. Area_bot was taken offline (to discourage low-quality Wikidata edits), but very little was done to explain the situation to users. This lack of communication became a larger problem than areas themselves, because it kept us from fixing the problem.

So what’s the plan?

Broadly, the first steps are:

  1. Improve overall communication within the project, as is being discussed in Rob’s recent blog posts.
  2. Make a long-term plan for areas and how they should be edited
  3. Possibly open up area editing to more people, based on what’s decided in step #2.

My next post, Area editing, part II, will go into more detail about step #2.

New Community Manager: Freso

Hello Brainzers!

Following up on the last post, I am now hired as the “MetaBrainz Community Manager”. This means that you should see me far more often in the forums, here on the blog, and on IRC. Just kidding. Like I could be more active on IRC than I already am! 😀

My overall tasks are outlined in the job description (link is one of the last drafts, final version is slightly different and will be put up on metabrainz.org Soon™), and my concrete here-and-now tasks are outlined on this Trello board. For right now I’m mostly “settling in”, getting my various tools set up and familiarising myself with them, catching up on blog comments and forum posts, etc., etc. – once all that is done, expect to hear more from me about my plans with this new title and its responsibility. Until then, feel free to catch me on IRC or comment below if you have any questions or comments. Looking forwards to (continue) working with you all!

Love,
Freso, your new friendly neighbourhood Community Manager ❤

Creating a paid community manager position

I’m slowly sifting through the community feedback comments and I’m increasingly falling behind in my tasks for managing MusicBrainz and all of the projects of the MetaBrainz Foundation. It has become clear that I need help in managing the community and not just help for software engineering or system administration. Thankfully one person came to mind when I started looking for help! Our own Freso has been active in MusicBrainz for over 9 years, so he knows his way around and is used to my abuse:

BDFL on Freso

More importantly, Freso manages to keep his cool when things get heated. He’s attended and supported our summits and he understands MusicBrainz and communities. I’m working with Freso to define his position and determine the appropriate pay level — we’ve moved past the stage where private issues were settled and are now ready to take this job description public.

So far, we’ve created this document to describe this new position. Please take a look — anyone can comment on the document. We’ll take comments and attempt to answer/integrate/respond to your feedback.

Once this job description is done and we’re happy with it, I will need to get board approval to create this new position. Fortunately for us, the new revenue from our new MetaBrainz site will cover the costs of having Freso as a paid member of our team.

Going forward, I plan to publish a list of people who are paid by the MetaBrainz Foundation, including their job descriptions. The above document will then be moved to the MetaBrainz site.

Happy weekend everyone!

Consolidating communications

There are already two themes emerging from the feedback on the various blog posts (especially yesterdays’s post):

  1. We have too many forms of communication: Blog, forum, mailing lists, Jira, edit notes and IRC. Some of these serve very specific purposes, such as the blog and jira, our ticket system. Others like the forum, mailing lists and IRC overlap quite a bit. In this area it seems that we should be able to consolidate a little, but people seem to be quite invested in their favorite form of communication. Forum users tend to dislike mailing lists and vice versa. People either hate or love IRC, there isn’t much middle ground.
  2. Lack of single sign on: To participate in most of these forms of communication the user needs to create a new, distinct account from their main MusicBrainz account. This hinders users from participating in more communication forms, which fractures our community.

How do we improve this then? I think we should focus our discussion on mailing lists, forums, IRC and in-site communication (MBS-1801, again), since they are more generic and overlap each other somewhat.

I see some possible ways of doing this, so let me think out loud for a minute:

  • Drop mailing lists and forums and use a “cloud hosted” instance of Discourse. Discourse is open source, supports single sign on, and looks like it could easily replace forums and mailing lists. I doubt this would be sufficient to replace IRC, but overall very promising.
  • Drop mailing lists, forums, IRC and implement a really kick ass communication/chat/edit note system in MusicBrainz itself. Layer’s offerings look like they might make this not too hard and are not too expensive. Our own system would allow the greatest level of control and integration and needs no new sign-on. However, it may also be the most amount of work.

(Regardless of what we decided to do, worry not, we would keep historical archives of whatever communications form we decides to drop.)

I’d also briefly considered using Slack, but since it isn’t open source and not geared towards open source, this doesn’t quite feel right. What other interesting tools are out there? What other ways do you see that we can consolidate our forms of communication?

Community problems?

No one has made any suggestions as to what tools we can effectively use to collect feedback about what aspects of the MusicBrainz community people think are broken. I’ve looked at a few tools to try and find something suited, but all I found was a lot of ill-fitting stuff.

So, let’s keep it simple and use this blog entry’s comments to talk about what bits about the community are working less than ideal right now. What bothers you? What feels wrong? What should we focus on right away to improve? What should we improve, but isn’t so important right this second?

Now, please remember to keep it polite, respectful and concise — if you are rude or hit me with a wall-of-text, I’ll ignore your comment. Also, please don’t name any names; don’t point fingers. Remember that everyone got a blank slate and is now innocent. If a particular person’s behaviour bothered you, describe the troublesome behaviour, not the person.

If you know of a ticket in Jira that already describes your issue, please reference the ticket! That will make sifting through the comments much easier. I’ll take your comments and try and weave them in a coherent set of topics and then post them somewhere. Exactly where is still to be determined — that depends on the amount/coherency of the feedback I get.

One issue that I prefer to not hear about is MBS-1801, the issue about people ignoring their emails about edits they have made. I’ve already set the process in motion to look at possible solutions for this issue and I hope to have a separate blog entry about this next week.

Go!

UPDATE: Some people did comment about solutions on. Sorry for skipping that part. (None of those suggestions really resonated with me either, sadly)

Robustness principle applied to communities

The great internet pioneer Jon Postel once wrote the following in an early draft of the TCP specification:

Be conservative in what you do, be liberal in what you accept from others

He wrote this in the context of computer networking and this philosophy arguably helped the Internet become robust to faults. Personally, I think this is great wisdom even in a larger scope — it can be applied to many other contexts in life. Today, I would like to apply this wisdom to our community:

If members of the MusicBrainz community could work hard to craft their edits so that they adhere to the guidelines as much as possible and to add supporting links to their edits, that would fit the bill of “being conservative in what you do”. Then, when you consider other edits, be liberal in accepting other people’s edits. If an edit makes the database better, vote yes, even if you don’t fully agree with it. If you see a small mistake and you’re an auto-editor, accept the edit and fix the small mistake. See if you can find a way to accept the edit, rather than shooting it down.

Our attitudes shouldn’t be “How can I shut this person down?”, but “How can I help this person make better edits?”. If an editor gets shut down for small mistakes, the editor is going to be discouraged from doing more edits. This harms the project overall! But, if an experienced editor politely helps a less experienced editor to improve their edits, the less experienced editor will feel more welcomed and is much more likely to continue learning and to continue making more edits.

After all, happy teams are vastly more productive than unhappy teams.

Happy editing!

Poisonous people

As I work to re-shape our community, I’ve been brushing up on open source philosophy. I’ve already mentioned “Producing Open Source Software” book, which is great, but can be somewhat dry at times. A more recent book that covers more of the team related issues is the excellent “Team Geek“. In particular the chapter on “Poisonous people” is really well worth reading.

One passage summarizes some underlying themes of my current series of blog posts:

“But there’s a danger here. In general, it’s not healthy to spend one’s time stewing in an ocean of negativity—it tends to eat you up and can create more conflicts in the long run. The term poisonous person is a nasty label and automatically creates a dividing line between “us” (the good guys) and “them” (those nasty jerks). There’s a better way to think about the problem. Instead of running your team as an elite fraternity with a mission to repel mean people, it’s healthier to create a culture that simply refuses to tolerate certain negative behaviors.”

Our community currently has a number of disrespectful people who could be classified as “poisonous”. However, I have good news for these people: I’m wiping the slate clean! Everyone gets a fresh start. As of today no one is poisonous! Hooray! \ø/

However, if you decide to go against the updated principles I’m stating in this blog post series, you should expect that people will confront your behaviour. One point of these blog posts is to provide bite-sized chunks of information that can be used to succinctly state updated project policies. If you encounter a person who is communicating aggressively, is being disrespectful or is hindering the community from moving the project forward, please remind them of these blog posts. When you encounter a problematic person, post the link to this blog entry and respectfully remind them to improve their behaviour.

I would also like to propose that we organize a group of volunteers to form what could be called: “Team Respect“. If someone in the community finds a person who is going on a “no-vote spree” or is entering useless and aggression filled tickets into jira, then they can call on Team Respect to jump in. Team Respect should engage this person, link to the relevant blog posts/project policies and remind them to be respectful. The team should also review the actions of the person — if the team feels that the actions by this person were uncalled for, the team should work to counter-act their actions. For instance, if someone goes an on unjustified no-vote spree, the team members should evaluate the edits in question and if they “improve the database” then they should vote yes on the edits, improve the edits to remove the objections or even approve the edits outright if they are auto-editors. Use your best judgement, of course!

The basic idea behind Team Respect is to make being a disrespectful person no fun and frustrating. At the same time Team Respect can raise positive feelings in the community by working together and protecting the work for polite, respectful people. And the polite, respectful people whose work was protected will be more inclined to contribute in the future.