We got this from Ben, who has been in charge of taking this discussion forward:
Since the beginning of the year there has been a lot of discussion about recordings and what exactly they should be used for. After several meetings on IRC and a couple of huge topics on the style mailing list, we’re finally ready to bring in a new definition for recordings, and new style guidelines to go with it!
The new recording definition can be viewed at http://musicbrainz.org/doc/Recording
And the accompanying style guidelines are at http://musicbrainz.org/doc/Style/Recording
The new guideline brings significant changes to the way recordings should be used, so all editors dealing with recordings should take the time to read it.
As a short summary, recordings are now never produced solely through copying or mastering. This means that recordings shouldn’t distinguish between different masters of some audio – in general, a recording will correspond a particular mix or edit. In addition:
- AcoustIDs and ISRCs have been removed from the guideline – they are mostly irrelevant for managing recordings under the new definition.
– Guidelines for audio channels have been introduced.
– Existing guidelines have been expanded.
– Several in-depth examples have been added to explain how recording should be used.
Also, as a result of these changes, the recording-recording remaster relationship type and the artist-recording master relationship type have been deprecated.
Thanks to everyone who was involved on mb-style and in the IRC meetings for your excellent ideas and contributions!
Nicolás Tamargo (reosarevok) is replacing Kuno Woudt (warp) as style leader. This will allow Kuno to fully concentrate on development, and also allow our other style leader Nikki to dedicate more of her time to testing changes and make it less likely for us to have botched releases.
We are also updating the proposal process, and tying it to the Jira tracker, to avoid the manual updating of the proposal table and problems with two people using the same proposal number by mistake. The updated system is at Proposals – the huge table there has been moved to Proposals/History
The MusicBrainz Style Leader has a really hard job — this position requires people to to have a thick skin, a deep understanding of MusicBrainz and the patience of a saint. Its a really challenging job! And because of this, people burn out fast and generally abandon their jobs after a while. This has been the pattern for many years for us and its been very frustrating. And now its has happened again: Brian, the Style Leader up til today, has not been responding to me. I’ve not heard anything from him in weeks.
In an effort to try and break out of this cycle, I am going start a new experiment: Make the Style Leader a paid position.
While we have some money in the bank, its not massive amounts of money and the pay for this position reflects just that. Its not a whole lot of money, but I am hoping its enough money to offset the pain of being the Style Leader and will keep the Style Leader engaged over a longer period. With that in mind, I am proud to announce that Nikki will be our next Style Leader and our first paid Style Leader.
Nikki has been tasked to ensure that the style process moves along and is properly documented. Her goal is to drive consensus among the brainerz who participate in the important Style process and to keep proposals on track. Once a proposal’s RFC/RFV periods are up, its Nikki’s job to ensure that the proposal is acted upon by the appropriate people. She should also help to keep the style process evolving as the MusicBrainz style needs evolve.
Thank you for all your hard work Brian! I look forward to working with you more closely Nikki!
BTW: Warp will still be involved in helping Nikki lead the style process, but his focus is on NGS for the time being. We’re very much dedicated to staying focused on delivering NGS as soon as we can.
We’ve hammered out many of the rough edges from the upcoming release and now we need your help to test the release to spot any problems that may have slipped past our new code review process.
New in this release:
– Release groups: This allows us to group same titled releases from one artist that have slightly different track lists into release groups. For instance, here is a Weezer release group that has many separate releases in it. We have converted as many batches of releases to release groups as we automatically could, but there are tons left to do. We’ll need your help!
– ISRC support: We can now track ISRC codes. While this is less useful to end users, our commercial customers have been asking for this for eons.
– WikiDocs: Our WikiDocs system now uses our new Mediawiki to pull documentation from.
– Bug fixes from our last release.
Aside from a good chunk of the bug fixes, all of these things are now live on our test server. Please report bugs to our bug tracker and make sure to select the “Server: ReleaseGroups, ISRCs, Bug Fixes” milestone so we can spot your bugs fast. Also take a look at the bugs we’ve already closed for this release and which ones are still outstanding.
We have one major known issue, where some release groups may be found in the search engine, but will give a “release group not found error” (example). This is a known bug.
Finally, do the release groups as we have them now make sense to you? There are a few things that may not be entirely clear, so we’re looking for feedback how to make things more clear before we release this on May 24th.
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.
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.
After many months of discussion, a new advanced relationship type for translated or transliterated titles has been created. This proposal hasn’t been fully implemented; a new Release Status for transl*ations that aren’t actual releases still needs to be implemented in the server (there is a vote on the Wiki for the best name for this), and there is still discussion on the -style mailing list about the need for explicit attributes marking translation vs. transliteration, but the basic AR, representing the parts of this proposal that have reached consensus, has finally reached the main server.
Thanks to everybody who participated (and is participating) in this very long and drawn out process.