OperaTrackStyle in beta period

Those who participated to it’s elaboration feel OperaTrackStyle is stable. We have now reached the next phase: the users who feel like testing the new StyleGuide are invited to do so. Remember that we are still in beta phase: you shouldn’t do mass edits yet, but rather choose atypical edits which might reveal problems with the new StyleGuide. Links to successful or problematic edits should be posted on this forum thread or in the mb-style mailing list.

Next server release: 1 week from today

The next server update is scheduled to happen one week from today. Today Lukáš and I finished checking in changes and will now only do further bug fixes — that is if you help us find more bugs!

A few things to note:

  • Lukáš added support for track annotations and release formats!
  • Data quality changes are no longer automods for everyone. Their behavior is defined in the edit info page now.
  • Since we’ve implemented the DataQuality feature, expired edits will no longer stay open for a grace period. Thus the next time ModBot runs after the next release, a bunch of expired edits will be accepted, since all the data will be at the default level and the action for expired edits at the default level is to accept the edit! Is this really what we want? Please take a moment to review the edit info page now and make sure it all makes sense to you!

The staging server is now updated with the latest code — please come and help us test over the next week to make sure no new bugs slipped into the upcoming release.

Thank you Rightround/BandBot and MusicIP!

I just returned from SXSW in Austin where I had the chance to speak to many people about MusicBrainz, see a few dozen bands and attend many music parties where I talked more about MusicBrainz. This trip was a great opportunity to catch up with a number of people and to forge new relationships for MusicBrainz.

This would not have happened if it wasn’t for Cliff and his cool team at Rightround/BandBot donating a free Music conference badge to me! And MusicIP rose to the challenge and found and paid for a hotel room so I could avoid sleeping on people’s hotel rooms floors!

Thanks Rightround and MusicIP — thanks for making my trip to SXSW possible and awesome!

Google Summer of Code

MusicBrainz has applied to be a mentoring organization for Google’s Summer of Code project. Google will actually pay students to spend their summer hacking on open source projects and I’m hoping that some students who are excited by MusicBrainz will apply to this project and spend their summer improving MusicBrainz.

If you’re a student and are interested in this, check out the link above and read up on the project. Then take a look at SummerOfCodeIdeas for some of the projects that I think could be done in the scope of Summer of Code.

They will begin taking student applications starting today and the window to apply isn’t terribly large, I think. So, if you’re interested, don’t dawdle and get your application in ASAP.

Post questions in the comments if you have them!

Next server release: April Fools Day

April 1st may not be the best date to release a new server, but scheduling would have it that way: The next server update is officially scheduled for April 1st, 2007.

To prevent the next release from becoming a bad April Fools joke, we will need your help to test the new features on the server. Recently we’ve asked people to come check out the new Labels support and the Data Quality support. Now that we’re coming to a close on this new release (there are still bugs to be fixed, but major functionality changes are done) we’d like people to come check it out again and help us test on the staging server.

The following features will be included in the next release:

  1. Improved cover art support: A new release-url Advanced Relationship link type has been created. By linking a release to a cover art JPG file at CD Baby or at the Internet Archive, editors will now able to deep link to cover art on sites other than Amazon.com. For more information on this feature, see CoverArtSites. See an example here and here.
  2. Data quality: Based on the first round of feedback, we’ve narrowed the data quality levels down to 3 from 4. The staging server has also been loaded with recent data and the ModBot is now running for a more complete test. See below for more comments on this.
  3. Label support: Label support has been around and a number of bugs have been fixed. For more info see Labels.
  4. Lookup nagging: Nagging tagger users who look up their files at MusicBrainz but who have not donated. If you go to to the taglookup page, you will be constantly nagged if you’re not logged in. If you log in, you will only be nagged every 5th lookup (I suspect that most people will be logged in). If you’ve donated to MusicBrainz, you wont be nagged at all. Designed to be not terrible right off the bat, I am curious to see what people think of this solution. Please point your tagger to http://test.musicbrainz.org and do some lookups to see if you think the current nagging approach will work ok.
  5. Bug fixes: Lots of them — see our milestone info for more details.

I have some more comments regarding the DataQuality feature — based on blog feedback I’ve changed the data quality levels to:

  1. Low
  2. Unknown
  3. High

I’m not certain if these are the best levels, but I wanted to throw out some thoughts that go with choosing these names/levels. First, the existing data and all new data that editors have not vouched for needs to have a name attached to it that makes sense. Just applying low data quality to all data by default will be unfair to large swatches of our data. I think one level needs to indicate that no human has vouched for the data and the other levels needs to indicate that someone has looked at the data and given it a thumbs up or thumbs down. Second, I like Low and High, but I am not a big fan of Unknown. What other word can we use that suggests that no human has vouched for this data?

Other suggestions I’ve tried for level names:

  • bad, unknown, good
  • unverified, unknown, verified

I tend to dislike these levels since labeling our data as bad seems like a poor idea. And verified is questionable as well — what do you verify the data against? So, please take the staging server for another spin and let us know what you think now. We still have nearly three weeks to try and figure our the best way of handling this.

Finally, the change artist/release quality edits are currently still auto edits for everyone — this will be changed before the release.


Data quality: We want your feedback!

The release locking concept has been around for quite some time and has been debated at great lengths. After a couple of long calls Don and I reworked the concept into the data quality concept. The idea is relatively simple:

  • Each artist and each release in MusicBrainz now has a quality indicator that shows the quality of the data: Unknown, low, normal or high.
  • Data that is marked with low quality should be easy to change.
  • Data with normal quality should take about the same amount of effort to change as it takes now.
  • Data with high quality should be harder to change, to avoid incorrect changes to good data.
  • Each edit type will define the number of votes required to pass, the duration votes stay open, what to do if an edit receives no votes, and if a vote is an auto edit.

This new feature will allow us to edit sloppy data faster, tune the editing system to fit better with how people use it and it will allow us to prevent accidental edits to good data. Now we need to your help in testing this system and giving us feedback about the various edit levels.

If you would like to help, please read the data quality wiki page, view the new edit information page and then test the new features on the staging server. Each artist and release page now has a Change Quality link that will allow you to change the quality of the artist/release. Once those are changed, the edit system will behave according to the values set forth in the edit information page. Please note that the change artist/release quality edits are currently autoedits, which will be changed once we’re done testing the bulk of this new system. For right now we’re making it easy to change the data quality for testing purposes.

To start testing, head over to the staging server. Add any bugs you find to the bug tracker. Or post your feedback in the comments.

Beta Period for Style Guidelines (aka Don's suggested new style evolution procedure)

In the last month the Style Council has worked on a couple of guidelines for classical music, and the first one of these is nearly ready: The OperaTrackStyle will describe how track titles for Operas should be written.

There were also discussions about how to make the style-changing process simpler and less tiresome. Now Aaron suggested to use “Don’s suggested new style evolution procedure” to make this new guideline official.

So, I suppose, I should explain a bit what that procedure would be. The explanation is attached as a podcast, since I still cannot type too much.