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.
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
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.
Edit #5258089 has raised the issue how MusicBrainz should handle “XY’s Top 50” playlists or the like.
After some discussion and a Request for Comments on the style mailing list, I have summarised the appearing consensus in this Request for Veto:
Bootleg torrents that are compilations based on playlists of charts authorities (like Billboard’s) should not be stored in MusicBrainz as releases. These playlists are often copyrighted by their issuers.
This has now been accepted. Therefore the “releases” representing such playlists should be removed from MusicBrainz, unless of course there are real compilations out there.
The logic behind this, is that these are not actual releases. The information they hold is just that of a playlist and releases are used as a hack to store this information in MusicBrainz. These “releases” clutter up the discography pages and might even get MB into trouble because of copyright issues.
Concrete cases are the Billboard’s Top n of the year yyyy and the John Peel Festive 50.
I still have not found a good place to write this down in the wiki. Suggestions are welcome.
There was a very good talk about the state of the MusicBrainz community and the plans for future development on irc just now.
It went from 20:03 to 21:52 on 2006-05-04.
It started with a kind of rant by Wolfsong, developed into a discussion about what is going wrong in the MusicBrainz community these days, and led to some pretty simple steps that might help to make things better.
I just wanted to bring this to everybody’s attention, before I go to sleep. I might get to adding a short summary tomorrow, but not now, sorry.
is over. It was fun, and it was a lot of work. Here is what we’ve worked out:
From the whole range of patchy fix to complete rewrite, we have chosen both
- FeaturingArtistStyle will be patched very soon.
- Then work will start on MusicBrainz 2.0: a complete rewrite of the
database schema, the moderation system and the user interfaces. This will
take a long time.
- In the meantime small improvements and fixes to old nuisances will be
made every 1-2 months.
Continue reading “Record of the 7th MusicBrainz Summit”
Alex has been copying the documentation from the website into the Wiki. The idea behind this is that the documentation on the website is partially dated and structured in a way that does not reflect the way new users come to MusicBrainz any more.
I have now joined him in his effort of RestructuringTheDocumentation. This is the second restructuring that this Wiki experiences (the first was the general RestructuringTheWiki).
Continue reading “Slowly updating the Documentation”