MetaBrainz Blog

In the last weeks I have been talking to Yalaforge, Lukas, Robert and Keschte about integrating Keschte back into MusicBrainz server development. Now, one thing that I have learned from the GreatDispute is not to do mediating behind the scenes, but to MakeIssuesPublic. Therefore I will now tell you what came out of these talks:

Robert said that he owes Keschte a second chance — if only because the way he handled the conflict was shitty — but that he “does not really believe in it”.

Keschte told me that he wants to work on mbserver again, but on the other hand he will wait and see how the MB community evolves after the dispute. He also said that he probably does not want to start seriously getting involved before next year.

So that’s the situation. There is also a lot of hurt pride and lost trust in there. This does not make things easier. However that is Rob and Keschte’s problem, and nobody can help them with it.

What I can do, and kind of did, was to negotiate a kind of compromise — a situation in which both of them could work together again. This is what it could look like:

• Keschte would get a kind of sovereign territory in which he can work his way, while Rob can be sure that whatever comes out of it has been thoroughly checked and is of good quality.
• Keschte does not want to work alone and needs feedback from someone. Robert made very explicit that he cannot and will not fulfill this role. However co-hackers, interested users could do this. That means that Keschte’s development process would have to be opened up to the community. He would need communication tools like forums, a dev-blog, a test server of his own on which “Keschte’s Bleeding Edge” is always available to the public, etc.
• On the other hand, Keschte would have to work more focused, in better delimited projects, one at a time, than he has on the XHTML server project. Initially this could mean to work with branches (it is clear that major refactoring cannot be done this way, but ArtistPageRedesign could).
• I do not believe that bug triaging and buffers between Keschte and the users would do any good. Those were discussed in a chat session mediated by Lauri. As I wrote at the end of the Great Dispute, Keschte had been set up in a double bind. You cannot solve this kind of problems with padding, only by changing the setting.

So, this is what it could look like. I say “could”, because both Keschte and Robert stated that they will not put a lot of work into making this happen now. For me this means that I won’t do it either. While I would love to help both in setting up a “sovereign territory” which is helpful and acceptable to both, I will not try to do all the work that they are not willing to do.

The conclusion? There currently is no MusivBrainz server developer. Sad thing, but the truth.

The suggestion of a bug triage mailing list has been turned into a reality:

• subscribe to mb-bugs
• view mb-bugs archives

The purpose of this mailing list is to give the community more insight into bugs/enhancements/tasks as they enter the bug tracking system and as they move through the various stages. People who subscribe to this list will be able to monitor the chatter between developers and users more effectively than before. If you’ve wondered what bugs are being reported and what bugs are being closed, join this list.

Technorati Tags: communities, musicbrainz

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