Author: ruaok

New business relations guru: Christina Smith

I am pleased to announce that I’ve just hired our first person responsible for looking after the day-to-day business operations of MetaBrainz! Christina Smith, a Canadian who also lives in Barcelona, has signed on as our part-time Business Development Guru (/Manager/Troublemaker/What have you).

This marks a significant step forward for us in a number of ways. First, it acknowledges that we have grown enough to warrant such a position. Second, Christina will improve how we communicate with customers and how much revenue we bring into the foundation. In the last two years we’ve added several new projects, but haven’t been able to hire new engineers to work on these projects, so hopefully having Christina will allow us to grow to support our new projects as well.

Christina’s responsibilities can be summarized as:

  • manage relationships with our supporters
  • provide timely, friendly and helpful answers and solutions for our supporters
  • increase revenues by connecting and building relationships with current and potential supporters
  • general accounting tasks including invoicing and payment tracking
  • periodic research, recommendations and help to address evolving business needs. (e.g. research the implementation of a company presence in Europe, including help in setting up a new headquarter in Barcelona)
  • research and suggestions on law and policy issues related to the business

I am super excited that Christina will be working with us — this removes a pile of tasks off my plate, which should allow me to focus more on running the foundation and managing our teams.

For the remainder of December, Christina will work on research tasks on how we can establish a better base in the EU. Then in January she will properly join the team and be present in our IRC meetings.

Welcome on board, Christina!

New search server build deployed

Today we’ve deployed a new build of the search server code. As you may know, we’ve been having loads of issues with our search servers recently.

In an effort to figure out what causes the bizarre behaviour we’ve observed, we compiled a new version of the codebase with a more recent version of Lucene. In theory this makes no feature changes to the codebase, but you never know if that is actually the case.

We hope that this build will be more stable, but we’ll need to observe over the next few days to see if that will be the case. If you spot any problems, please report them in our SEARCH bug tracker.

Thanks!

Laurent Monin joins the team as a part-time sysadmin

For the first time in a number of years we have a person responsible for system administration! Over the past few years we’ve been trying to spread the duties to maintain our servers among our developers. This only worked so well and the duties are piling up and not being attended to.

With the introduction of our new MetaBrainz site in May, we finally have an increasing revenue stream, which allows us to finally hire a paid sysadmin. Hopefully we can work on our back log of tasks now.

Laurent Monin (aka Zas) is no stranger to our project — he has been hacking on Picard for a number of years and he attended last year’s summit in Copenhagen. I’m quite happy to have found a community member and long-standing contributor to take on this task.

Some of the first tasks that Laurent will take on are from direct feedback from our blog series about community improvements. We’re hoping to consolidate our mailing lists and forums into a Discourse instance and then provide single sign on for Discourse, our Wiki and Jira. Stuff we’ve talked about for years, but never have made any progress on.

I’m quite excited to have Zas on board! Welcome!

Roman Tsukanov joins the MetaBrainz team

I’m pleased to announce that last week we officially hired Roman Tsukanov, AKA Gentlecat to be a part time developer for MusicBrainz!

Gentlecat has already established himself firmly in our community: Last year he rocked the CritiqueBrainz project for Summer of Code and this summer he rocked AcousticBrainz. And he’s written our shiny new MetaBrainz web site! He is now in the process of learning perl and has started to help Bitmap review existing code reviews. And he has even fixed a couple of issues already. In other words he lives up to his name: To Gentlecat something means to rock it!

I’m quite happy to have such a capable developer participating in MusicBrainz. Welcome to the team Gentlecat!

There will be no autumn 2015 schema change

Schema changes are always a lot of work for us and we end up spending much time preparing for it and then even more time cleaning up/catching up after it. As a result, some critical non-schema change features keep getting pushed back… to the point that we never get to them.

To try and break this cycle, we’re going to skip the Autumn 2015 schema change. Instead we will focus on other tasks such as hosting and community features.

We will resume our schedule with the next planned schema change around 15 May, 2016. After that release we will determine if we want to go ahead with 1 or 2 schema change releases a year.

New MusicBrainz server virtual machine available

Time to check the weather forecast for hell, because it appears to have frozen over! We have finally released a new Virtual Machine that contains all of the MusicBrainz server software and fixed all of the currently outstanding bugs (for the VM).

The new VM now uses a 64-bit architecture and has 80GB of disk-space so it should be much easier to get along with. I tried to ship one VM that has the search indexes build in, but after 3 hours (and increasing time) of trying to export that VM I killed it. If someone has better luck exporting a VM after building search indexes, please let me know. Also, VirtualBox seems to have improved in stability on Mac OS, so we are not going to build a VMWare version of the VM at this time.

All the details for the new VM are on our Server Setup page.

Remember to get your Live Data Feed access token here if you plan to use the replication.

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!