Month: July 2015

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!

Server update, 2015-07-27

Today’s release improves the way series are automatically ordered (MBS-7557), and fixes a few bugs in the edit system preventing certain edits from closing. We’ve also got some fixes and additions to the URL cleanup code.

Thanks to all who contributed to today’s release. The git tag is v-2015-07-27 and the complete changelog is below.

Bug

  • [MBS-8308] – Non-redirecting Weibo URLs are changed to URLs which redirect
  • [MBS-8475] – Allow links to Amazon Mexico
  • [MBS-8480] – Home page “latest posts” garbles fancy punctuation coming from the blog titles
  • [MBS-8483] – Entities that require a disambiguation comment ISE if submitted with relationships
  • [MBS-8484] – Server does not fully collapse spaces surrounding non-printable characters
  • [MBS-8485] – ModBot can’t close deletion edits if the entity no longer exists
  • [MBS-8488] – ModBot can’t close an AddISWCs edit where any of the works were deleted
  • [MBS-8490] – Works with no relationships not being deleted
  • [MBS-8491] – Work merges aren’t happening

Improvement

  • [MBS-7557] – better series automatic ordering
  • [MBS-7987] – Event series should be (auto-)ordered by date
  • [MBS-8457] – Remove “?oldformat=true” from Wikipedia URLs

New Feature

  • [MBS-8312] – festivals from songkick and setlist.fm not allowed as event-relationships

Task

  • [MBS-8487] – Add autoselect to soundcloud for series

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.

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!