Development/Summer of Code/2011: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
No edit summary
No edit summary
Line 18: Line 18:
=== Improve collections ===
=== Improve collections ===
Collections are a really useful feature of MusicBrainz, but their usefulness is limited by implementation. This proposal would be about making the collections more useful - for example the ability to have wishlists, multiple collections, sharing lists, etc. Be creative - there's lots of stuff we could do with a more generic solution to managing lists :)
Collections are a really useful feature of MusicBrainz, but their usefulness is limited by implementation. This proposal would be about making the collections more useful - for example the ability to have wishlists, multiple collections, sharing lists, etc. Be creative - there's lots of stuff we could do with a more generic solution to managing lists :)

== Investigate MusicBrainz on Amazon Web Services ==
There are probably some parts of MusicBrainz that we could run on AWS - we'd be happy to mentor some small projects about running parts of MusicBrainz on AWS.


===Your idea here!===
===Your idea here!===
Line 29: Line 32:
* Artist-artist collaborative filtering: We have a third party that has volunteered to work on this for us pro bono.
* Artist-artist collaborative filtering: We have a third party that has volunteered to work on this for us pro bono.
* Collaborative similarity, along the lines of tags, as well as similarity cloud-link charts, between artists, labels, or releases. (This artist sounds like that artist, this label tends to release the same types of music as that label, this release is quite like this other release, etc). Maybe even tracks? Personally, I like the implementation in the Gazelle code, where anyone can add a similar artist, but then others can both up and down vote that similarity, something like the Slashdot karma system, with the similarity ranking between two objects influencing how high in the list they are, and how large they appear in the cloud. -- [[Brian Schweitzer|BrianSchweitzer]] 04:14, 13 March 2009 (UTC)
* Collaborative similarity, along the lines of tags, as well as similarity cloud-link charts, between artists, labels, or releases. (This artist sounds like that artist, this label tends to release the same types of music as that label, this release is quite like this other release, etc). Maybe even tracks? Personally, I like the implementation in the Gazelle code, where anyone can add a similar artist, but then others can both up and down vote that similarity, something like the Slashdot karma system, with the similarity ranking between two objects influencing how high in the list they are, and how large they appear in the cloud. -- [[Brian Schweitzer|BrianSchweitzer]] 04:14, 13 March 2009 (UTC)
* Ports of MusicBrainz: Yes, we're aware of Django and Ruby on Rails, but porting all of MusicBrainz to run on these platforms is not at all practical.


== About Proposals ==
== About Proposals ==

Revision as of 20:43, 8 March 2010

Ideas for Google's Summer of Code

The MetaBrainz Foundation has applied as a Google Summer of Code organization in 2010. This will allow MusicBrainz hackers to apply for the Summer of Code program and if accepted, get paid for hacking on MusicBrainz.

This page lays out various ideas for projects that people can take on during their Summer of Code. If you have your own ideas for Summer of Code, please add them at the bottom of this page.

All applications for Summer of Code must pass a community review process where the proposer must clearly define their idea and present it to the community at large. Proposers must be/become active members of the community and must adapt their proposals according to community feedback. If the community does not approve of the project, the project will not be accepted by MetaBrainz Foundation. If your project makes it into the final round of consideration for acceptance, be ready for an interview and possibly even an entrace test to verify the skills claimed on your Summer of Code application.

Furthermore, all projects must develop new features for MusicBrainz. Proposals for replacing existing and working projects for the sake of making them more open will not be accepted. Proposals for extending existing projects with new features have a much greater chance at being accepted.

We strongly encourage students to delve into MusicBrainz and provide their own ideas for Summer of Code. We're listing a few projects here that we care about greatly, but we're more excited to hear what students want to do!

Mentors

This year Robert Kaye and Oliver Charles will be mentoring students. That's ruaok and aCiD2 on IRC, if you want to come and speak to us first.

Wanted Proposals

Improve collections

Collections are a really useful feature of MusicBrainz, but their usefulness is limited by implementation. This proposal would be about making the collections more useful - for example the ability to have wishlists, multiple collections, sharing lists, etc. Be creative - there's lots of stuff we could do with a more generic solution to managing lists :)

Investigate MusicBrainz on Amazon Web Services

There are probably some parts of MusicBrainz that we could run on AWS - we'd be happy to mentor some small projects about running parts of MusicBrainz on AWS.

Your idea here!

We really like getting completely different suggestions, so please do not feel at all limited to the above proposals. If there's something cool you think could be done with MusicBrainz and want to make it happy - please suggest away.

Proposals NOT wanted

We are not interested in Mentoring the following projects:

  • Creation of new tagging applications: We would much rather see proposals that extend the Picard tagger and help along with its development.
  • Acoustic fingerprinting projects: We have an excellent partner in MusicIP who provides our current fingerprinting technology. Submitting a proposal to replace MusicIP is not going to be accepted since we are very happy with our current arrangement for acoustic fingerprinting.
  • Artist-artist collaborative filtering: We have a third party that has volunteered to work on this for us pro bono.
  • Collaborative similarity, along the lines of tags, as well as similarity cloud-link charts, between artists, labels, or releases. (This artist sounds like that artist, this label tends to release the same types of music as that label, this release is quite like this other release, etc). Maybe even tracks? Personally, I like the implementation in the Gazelle code, where anyone can add a similar artist, but then others can both up and down vote that similarity, something like the Slashdot karma system, with the similarity ranking between two objects influencing how high in the list they are, and how large they appear in the cloud. -- BrianSchweitzer 04:14, 13 March 2009 (UTC)
  • Ports of MusicBrainz: Yes, we're aware of Django and Ruby on Rails, but porting all of MusicBrainz to run on these platforms is not at all practical.

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

More ideas