[mb-users] Google Summer of Code ideas

Robert Kaye rob at eorbit.net
Wed Mar 19 20:57:35 UTC 2008


On Mar 18, 2008, at 7:56 AM, Oliver Charles wrote:
> 1. Redesign
> -----------
> Seems the big one at the moment. This project will be 2 stage - 1  
> part templating HTML for the new MusicBrainz mb-server, and other  
> part implementing CSS and the rest of the design. Will also be  
> bringing JavaScript up to date, and increasing usage to add more  
> asynchronous operations where MusicBrainz is needing it.

I favor this one quite a bit. However, in light of Luks' work with  
pymbserver and his new perl branches we should have some discussions  
to frame this project before working on a proposal.

Everyone: I'm working with Luks and Oliver to do just this. Once we  
have a plan gel'ing up, I'll have Oliver post an update.


> 2. Community Features:
> ----------------------
> MusicBrainz took a leap into community aspects when it introduced  
> Folksonomy with the last release. This project will attempt to  
> further develop this ideas with support for entity comments/reviews  
> (all entity types, not just releases). Alongside this, list tracking  
> will be added - so users can create their own lists of music  
> (possibly to emulate want/have lists, or to create lists of "to-work- 
> on" releases for power editors).

I'm lukewarm on this. I would prefer to see mb_server ported/updated/ 
fixed before squeezing in more new stuff.

> 3. Adaptive Search Results
> -------------------------
> A lot of editors here work on specific sets of music (I myself, work  
> with drum & bass) and often for editors we have to move through  
> extra "noise" in the system to find data that is useful to us.  
> Adaptive search results would attempt to filter, or prioritize  
> search results in some way to make them more useful to specific  
> groups of people. One way to make this work, for example, would be  
> to move any results in an editors subscribed artist list to the top,  
> or emphasis the results. Other changes might be to prioritize  
> artists the editor often works with, or has "visited" more of.

Lukewarm to this as well. I think its more important to tie the search  
server to the database so that changes to the database are available  
instantly in the search, rather than having to wait up to 24 hours.


> 4. Extend XML webservice (submission/edits)
> -------------------------------------------
> The current XML webservice provides a robust way to retrieve data,  
> but no way to push new data. Some people have requested this  
> support, this project would implement it.

I think your talents would best be used elsewhere.

> Motivated by past discussions, and this recent discussion on the  
> auto-editors list, this project would set out to research  
> possibilities of a ranking/reward system for regular contributors.  
> Auto-editor is a hard goal, and sometimes too far away for editors  
> who need that little motivating credit now and then. After a  
> sensible system is decided upon, the rest of the project would be  
> implementing and testing.

I like this project as well, but I think the same as #4 applies here.

--

--ruaok      Somewhere in Texas a village is *still* missing its idiot.

Robert Kaye     --     rob at eorbit.net     --    http://mayhem-chaos.net





More information about the MusicBrainz-users mailing list