Month: September 2006

The conflict resolution chat has been set for this weekend:

• Date: Sunday, October 1st, 1200 PDT/1500 EDT/2000 GMT/2100 CEST
• Moderator: Lauri Watts
• Location: IRC channel #musicbrainz on irc.freenode.net

The goal of this chat session will be to brainstorm about a system where the community can take part in resolving disputes that arise in the MusicBrainz community. The agenda for this chat will be posted in the next couple of days.

Technorati Tags: communities, musicbrainz

In one of the previous posts, Matthias pointed out that we need to focus more on getting people to vote on open moderations. I’d like to brainstorm a little on this…

I have plans for a more elaborate editor rating system that would replace our black and white automoderator system. This new system will create many levels of privileges and automatically adjust an editor’s rating based on their editing/voting history. As an editor moves up in the rating, fewer of their edits will be put to a vote or perhaps require fewer votes to pass. Many of the details of this new system have not been worked out.

However, until we get to this system which ought to reduce the overall number of edits required to be voted on, we should somehow attempt to encourage people to participate in the peer review voting process. So far we know:

1. Voting i-frame: A “vote on this edit” i-frame shown at the top of each artist/album page didn’t increase the voting much but encouraged people to just start clicking the no button causing lots of pain for many editors. Voting no become too easy. Once we turned this off by default and made it optional the problem of random no voting went away.
2. Forcing people to vote: Forcing people to vote never works. People will vote anything just to get past the obstacle. This is not a viable solution.
3. Showing top voters: The top voters list encouraged more people to vote, but that wasn’t enough. This shows that giving people credit for their work encourages others to participate more.

We’ve probably learned more, but these are the big lessons I remember. Please post a comment if you remember something I’ve forgotten.

The only thing that has worked to a degree was to put active voter’s names in lights and give credit where credit is due. For quite some time I’ve thought about using an eBay like system to put more informative icons before users name to indicate the user’s status. eBay uses stars and other icons to show the status of a user to give people immediate feedback about the trustworthiness of the seller.

What if we create a new icon for users that graphically shows the editor status and the voting status of the user?

Editor status:

1. Newbie registered less than two weeks ago
2. Less than 100 edits
3. Less than 500 edits
4. Less than 1000 edits
5. More than 1000 edits

Voting status:

1. 0 votes cast
2. less than 100 votes cast
3. less than 500 votes cast
4. less than 1000 votes cast
5. less than 5000 votes cast
6. more than 5000 votes cast

These numbers/breakdowns are just randomly made up to illustrate the point — I’d like to have the community suggest actual values and graphical representations of these values if we proceed with this plan. What do you think of this approach?

Finally, I’d like to play devils advocate: What if our magic number of ~6000 open edits is our steady state? What if none of our actions ever change the number of open edits?

Technorati Tags: collaboration, communities, musicbrainz

Part 3 talks short term solutions to problems — things to tackle immediate problems: (also see part 1 and part 2)

Bugs mailing list: In order to solve the problem of opacity of the bug system (its hard to see what people are saying in bug reports unless you spend quite a bit of time following bug reports) I’m going to implement the bug triage suggestion. With this system, every time a bug is submitted or changed an email is posted to the new musicbrainz-bugs mailing list. This will allow more people to monitor the flow of bug reports. (This is almost done, but I am experiencing problems setting up the new mailing list — I’ll need to wait for Dave to return from holidays)

Forums: It appears that even the sternest nay-sayers on forums agree that its time to get these set-up. I’ve asked Lukas to see if he is still interested in spearheading this effort. UPDATE: Lukas is still interested in taking care of this.

Mirror and test server maintainers wanted: Maintaining the nl. mirror and the test/staging server is work I would like to give to someone else. The test server in particular needs work to make many sandboxes for new developers to come in and play with mb_server without having to install a whole setup on their own machine. Anyone interested in this job should be reasonably familiar with mb_server. Send me mail or post a comment if you can help!

support@: As mentioned in part 1, I could use more help with mails sent to support@. Wolfsong has been graciously helping this this task, but as it happens with volunteers he gets busy with real life from time to time. Zout joined the effort to answer emails today and I am wondering if there are other people who would like to help with this. I’d like to have a team of people answer mails sent to support@ and info@ on a first come, first serve basis. Send me mail or post a comment if you’d like to help out.

Conflict resolution: During the August IRC chat we discussed the need for an official body of people to help with conflict resolution here at MusicBrainz. Its clear that conflict resolution is a task to be handled by more than one person in public. I’m currently attempting to find a moderator and a suitable time to have this discussion. My hope is to do this on a Sunday so that as many people as possible can jump into this chat. I’ll post details when I have them.

Stefan: I’ve mailed Stefan to see if he was even interested in being a MusicBrainz developer again. He didn’t give me a clear answer, so I will wait for concise word from Stefan on this issue.

Part 4 will talk about documenting the MusicBrainz development process — more tomorrow.

Technorati Tags: communities, metabrainz, musicbrainz

In part 1 I set the groundwork for how we arrived at our current situation of me being overloaded, and in part 2 I would like to start looking at long term solutions to issues from part 1. Part 3 will look at more short term solutions.

I know there are a number of people who do not like the fact that MusicBrainz is a business. But we have to realize that MusicBrainz and its legal parent the MetaBrainz Foundation is a non-profit business and that it would not really be possible to grow such a project without it being a business. (Before we started the non-profit everything was owned by myself, which IMHO is a much less desirable way of doing this.) We are still an open source project. We’re also an open data project.

Something is working: We have users, editors, peer reviewers and loads of traffic. We even have $$$ money flowing into the non-profit. The community is constantly asking for more features to expand the database and to improve the service.

However, something is not working: We’re dreadfully short on server developers. The number of people who have made serious contributions to the mb_server project can be counted on one hand (or pretty close to that). In order to work on mb_server you need to have a linux box, with free disk space, a fair amount of RAM and you have to have the skills to deal with the long INSTALL process. Some people simply do not own a machine that is capable of doing this!

And even those people who can deal with technical requirements are not necessarily up for the social issues that come with the job. The community can be very demanding and quite harsh at times — no one wants to work long hours for free only to have their work insulted. Compared to ordinary open source projects, mb_server is quite challenging to work on. No doubt about it, its a tough and harsh job that people have been doing for free.

Going forward I will be working very hard to raise funds in order to hire a full time mb_server developer. We’ve passed the point where we can handle all of the mb_server development tasks with volunteer labor. Programming a project towards self-sustainabilty is quite different from programming to scratch an itch. We still have many itches that I hope volunteers will take on, but managing and coding towards sustainability will soon need to be handled by a full time paid developer.

How do we accomplish such a thing? Ever since the last summit where we hammered out the Next Generation Schema I’ve been talking to potential sponsors about donating money towards the development of this next version of MusicBrainz. Finally we have a concrete task to focus on, rather than just trying to make the basics work. Various companies have been receptive to this idea and I will continue to look for sponsors for this task.

My goal is to raise $100k – $200k in hopes of being able to secure a salary for an engineer for one year. The hope is to sell enough data licenses in the course of that year to keep the developer on and pay for this person’s salary. Once this engineer is on staff, I would expect to see 2-4 releases over the this year to prepare for and roll out the Next Generation Schema.

I expect that my time will continue to be taken by running the business development aspects of Musicbrainz and interacting with the community and partners. However, please don’t take this as me no longer participating in the development process. I will still be involved — certainly to manage the process and also to hack out my personal itches. I just don’t think its viable for me to be the official maintainer of any major pieces of code.

Please keep in mind that this is long term planning. I have no schedule for when this will happen. Please don’t mail me in two weeks asking to be hired or to have Next Generation Schema working.

Technorati Tags: communities, metabrainz, musicbrainz

I’m finally back from being on the road. I’ve caught up on much needed sleep and am now working regular hours again. This means its time to address the various issues that we left to ponder before I went on vacation and my trip to Europe. While I was in Europe and in IRC while I was rebooting our database server, inhouseuk said the following:

inhouseuk: you need to start behaving more like a sort of CEO rather than a one man band 🙂

I agree. But then, what exactly is this sort of CEO (or rather sort of Executive Director) supposed to do? And what isn’t he supposed to do? Thats a really tough question that I would like to pose to the community at large. If you have any thoughts on this, please speak up.

The first thing that I want to do is to describe the job I have been performing for the last two years since the non-profit has been running. Then, with help from the community I would like to come up with my job description going forward. That way we can all be on the same page about I should and should not be doing.

Things that I should probably not be doing any longer are in bold.

Executive Director of the MetaBrainz Foundation

Server maintenance

• Hardware purchasing/acquistion of used hardware
• Colocation issues/contracts/maintenance
• Managing hardware costs and future planning
• Manage off-site servers (nl., test.)

Business Development

• Conferences/tradeshows/schmoozing/maintaining contacts for MusicBrainz
• Meetings with potential partners/licensees
• New licenses sales
• Managing and soliciting sponsors
• Raise funds for further server development

Development

• mb_server (and too little of it)
• lucene searching

Legal Department

• Licenses for data/software/web services
• Contracts for data/licenses/web services
• Interacting with lawyers
• Find pro bono lawyers

Community Relations

• Answering questions in IRC/mail/blog/mailing lists
• Conflict resolution
• Managing developers

Foundation Issues

• metabrainz.org web site/donation tracking
• State/federal filing requirements
• Board of directors management/meetings

Accounting

• Keep general books, manage invoices, pay bills
• File tax reports/manage accountants
• Post monthly financial results
• Manage bank accounts/investments

Support

• Answer support@ emails, with help from Wolfsong
• Help partners/licensees (at least have support@ team help

Please note that not all of these tasks are things I do every week. But should something come up, I have to rise to the task. If a server tips over, I go to fix it. If a customer has a question I ask it. I may just go for weeks without dealing with a tipping server.

Do you agree or disagree with the items I’ve identified as things that I should not handle any more?

Technorati Tags: communities, musicbrainz