Development/Summer of Code/2012
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
There's been some discussion of implementing a system somewhat similar to the Cover Art Archive for Creative Commons-licensed album reviews. The BBC has a site for reviews which provides some of the functionality desired, but some folks would like us to have something more open and more our own; it's pretty open-ended at the moment what this could mean though.
Read-only, browser-oriented site
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. It's an open question whether this would constitute changes to the current site (when not logged-in, most likely) or whether this would be an additional site/codebase/view on our data.
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.
Proposed mentors: jdamcd
An iPhone app was started during GSoC 2010 but it didn't result in a final product. We'd love to have one. Jdamcd made MusicBrainz for Android and has offered to mentor a student who'd like to work on mobile apps for MusicBrainz. A finished iPhone app is the obvious project here. However, proposals for extending the Android app in some significant way (such as tagging) could be interesting.
Extending the usefulness of collections
Proposed mentors: ocharles
Collections might be much more than they are now. Among the potential improvements are allowing collections to work as release subscriptions and free text fields of various sorts.
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.
Implement Webservice/Search using Hibernate Search Library
Proposed mentors: ijabz
Currently we don't have a proper seperation between mbserver and the database, we have a webservice that can be used to retrieve most things from the database but it is tied into mbserver. You cannot currently deploy only the webservice. We also have a seperate Search Server application that searches over Lucene indexes built from the database, this provides another part of the webservice but does not have access to the actual database at search time.
[Hibernate Search] is a library that brings together Lucene for searching and Hibernate ORM for retrieving data. I think it would be a perfect fit for us allowing us to provide a single web service with search and lookup in one. Data could be returned in multiple formats or as objects, and the advanced mapping features of Hibernate Core would solve the issues Musicbrainz has serving certain requests (such as all releases by Mozart). HIbernate Core also makes it easy to modify database and this could well as the basis for the editable webservice.
IMO would be very useful to try out using Hibernate Search for serving one entity (i.e Label) and see if it is worth pursuing further.
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.