Development/Summer of Code/2012: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
No edit summary
 
(8 intermediate revisions by 5 users not shown)
Line 8: Line 8:
'''Proposed mentors''': ''[[User:RobertKaye|ruaok]],'' ''[[User:OliverCharles|ocharles]],'' ''[[User:Kuno|warp]]''
'''Proposed mentors''': ''[[User:RobertKaye|ruaok]],'' ''[[User:OliverCharles|ocharles]],'' ''[[User:Kuno|warp]]''


There's been some [[MusicBrainz_Summit/2012_Mini-Summit/Notes#Editorial_data_.28artist_reviews.2C_album_reviews.2C_artist_pictures.29|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.
There's been some [[MusicBrainz_Summit/2012_Mini-Summit/Notes#Editorial_data_.28artist_reviews.2C_album_reviews.2C_artist_pictures.29|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 ===
=== Read-only, browser-oriented site ===
Line 14: Line 14:
'''Proposed mentors''': ''[[User:Reosarevok|reosarevok]],'' ''[[User:Gioele|gioele]],'' ''[[User:PavanChander|navap]]''
'''Proposed mentors''': ''[[User:Reosarevok|reosarevok]],'' ''[[User:Gioele|gioele]],'' ''[[User:PavanChander|navap]]''


There's been some [[MusicBrainz_Summit/2012_Mini-Summit/Notes|discussion]] of implementing a site better geared toward casual browsing users, rather than editors. 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.
There's been some [[MusicBrainz_Summit/2012_Mini-Summit/Notes|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.


=== Location support ===
=== Location support ===
Line 20: Line 20:
'''Proposed mentors''': ''[[User:RobertKaye|ruaok]],'' ''[[User:OliverCharles|ocharles]],'' ''[[User:Kuno|warp]]''
'''Proposed mentors''': ''[[User:RobertKaye|ruaok]],'' ''[[User:OliverCharles|ocharles]],'' ''[[User:Kuno|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. It would probably make sense to also create an entity type for its lower tier (studios, venues, etc). Talking to projects with location lists, like OpenStreetMap, might be useful for this.
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.


=== Internationalisation ===
=== Internationalisation ===
Line 26: Line 28:
'''Proposed mentors:''' ''[[User:Nikki|nikki]]''
'''Proposed mentors:''' ''[[User:Nikki|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 [https://github.com/kepstin/riker 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.
musicbrainz-server doesn't currently run with any translation, although we have some partial stuff set up.


[[Server Internationalisation]] links to relevant transifex, language-specific translator pages, and such.
[[Server Internationalisation]] links to relevant transifex, language-specific translator pages, and such.
Line 32: Line 34:
[[Internationalization]] is a very old discussion of issues re: internationalization; some may still be useful.
[[Internationalization]] is a very old discussion of issues re: internationalization; some may still be useful.


=== Finishing an iPhone app ===
=== Mobile apps ===


'''Proposed mentors:''' ''[[User:Jdamcd|jdamcd]]''
'''Proposed mentors:''' ''[[User:Jdamcd|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.
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 ===
=== Extending the usefulness of collections ===
Line 42: Line 44:
'''Proposed mentors:''' ''[[User:OliverCharles|ocharles]]''
'''Proposed mentors:''' ''[[User:OliverCharles|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.
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:''' ''[[User:RobertKaye|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:''' ''[[User:ijabz|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 separate 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.

[http://www.hibernate.org/subprojects/search.html|[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.


== Proposals ==
== Proposals ==

Latest revision as of 09:53, 24 August 2013

Mentors

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.

Suggestions

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. 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

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. 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.

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.

Internationalisation

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.

Mobile apps

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 separate 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.

Proposals

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.