Development/Summer of Code/2012

From MusicBrainz Wiki
< Development‎ | Summer of Code
Revision as of 23:44, 27 February 2012 by Ianmcorvidae (talk | contribs) (some updates)


This year Robert Kaye, Oliver Charles and Kuno Woudt will probably be amongst our mentors. That's ruaok (Robert), warp (Kuno) and ocharles (Oliver) on IRC, if you want to come and speak to us first. Some potential mentors are listed by each project; this is far from a normative list, but it might give you somebody to ask about the project.


Repository for Creative Commons-licensed reviews

Proposed mentors: ruaok, ocharles, warp

There's been some discussion of implementing a system somewhat similar to the Cover Art Archive for Creative Commons-licensed album reviews. This is very open-ended at the moment.

Read-only, browser-oriented site

Proposed mentors: reosarevok, gioele, navap

There's been some discussion of implementing a site better geared toward casual browsing users, rather than editors, containing stuff like Wikipedia bios, reviews, embedded streaming for those recordings we have relationships for, etc. This is very open-ended at the moment, but some likely issues are in terms of maintainability (potentially two codebases!?), what exactly needs to be shown, effect on the existing site, etc.

Location support

Proposed mentors: ruaok, ocharles, warp

Currently, MusicBrainz stores only a country (with various entities), based on a current ISO standard list, which obviously doesn't tell that much about locations, especially for releases, artists, etc. that happened well before the establishment of current country boundaries. Better location support could be implemented a lot of different ways and take a lot of different forms. Some basic considerations would include defining areas and subareas, historical locations (how to display them in an understandable way, especially), and how to link these locations into the various places we use locations and could use them (releases, ARs, etc.).

It would probably make sense to also create an entity type for a "lower" tier (studios, venues, etc). Talking to projects with location lists, like OpenStreetMap or GeoNames, might be useful here.


Proposed mentors: nikki

musicbrainz-server doesn't currently run with any translation, although we have some partial stuff set up. It would also be nice to have some pretranslated message catalogs to be able to hand off to applications like Picard or Riker once it exists. Part of this project would undoubtedly include community-wrangling efforts such as attracting and organizing translators, but the bulk of it would be dealing with technical considerations of various sorts: building a robust translation system, setting up user options and language-switching interfaces, making sure our strings are translatable, dealing with complex issues like language-specific CSS (for right-to-left languages, for example), splitting up message catalogs, and making tools and catalogs available for application developers.

Server Internationalisation links to relevant transifex, language-specific translator pages, and such.

Internationalization is a very old discussion of issues re: internationalization; some may still be useful.

Finishing an iPhone app

Proposed mentors: jdamcd

We had an attempt to create an iPhone app during GSoC 2010 that didn't ultimately result in a final product. We'd love to have one, though. jdamcd is the student who made MusicBrainz for Android and he's offered to mentor a student who'd like to work on mobile applications for MusicBrainz.

Extending the usefulness of collections

Proposed mentors: ocharles

Collections might be much more than they are now. Allowing them to work as release subscriptions and allowing free text fields come to mind.

MusicBrainz Server log analysis

Proposed mentors: ruaok

MusicBrainz get over 20M hits per day and we have massive amounts of log files being thrown away daily. We should be mining these log files for interesting things - for instance we could create a "top artist and top release on MusicBrainz" statistic derived from our log files. Our log files could also be very useful for feeding into a collaborative filtering system -- however a collaborative filtering system is not part of this proposal. What other pieces of information can we find in our log files? We'd love to hear you think about this and tell us about it in your proposal.


About proposals

Before you dive in and send a proposal to us through Google, it's a good idea to take some time and learn about the MusicBrainz community. At MusicBrainz we pride ourselves for having a strong community - most of us know each other in same way, and some of us know each other face to face from development summits.

A good way to get a feel of this would be to lurk around in IRC, or to talk about your proposals on the mailing lists.