Development/Summer of Code/2011: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
No edit summary
m (Reverted edits by 208.75.10.42 (Talk); changed back to last version by RobertKaye)
Line 39: Line 39:
=== Proposal Tracker ===
=== Proposal Tracker ===


The StyleCouncil sometimes has a hard time keeping track of proposals. This project would develop an proposal tracker for the [[Proposals|Style Council]], either modified from an existing issue tracker or written from scratch. The goal is for anyone interested to be able to see:
The StyleCouncil sometimes has a hard time keeping track of proposals. This project would develop an proposal tracker for the [[Proposals|Style Council]], either modified from an existing issue tracker or written from scratch. The goal is for anyone interested to be able to see:


* the current status of a proposal (e.g. RFC/RFV/withdrawn/approved/implemented)
* the current status of a proposal (e.g. RFC/RFV/withdrawn/approved/implemented)
Line 85: Line 85:


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

== External Links ==
[http://www.overnightpools.com/ Pool Supply]


[[Category:Development]]
[[Category:Development]]

Revision as of 05:06, 20 April 2010

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 the 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, Oliver Charles and Kuno Woudt will be mentoring students. That's ruaok (Robert), warp (Kuno) and aCiD2 (Oliver) on IRC, if you want to come and speak to us first.

Proposals


IMPORTANT NOTE: All of these ideas should assume that they are going to be built on top of our Next Generation Schema. We will not accept proposals based on our old code base.

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 Amazon Web Services (EC2) - we'd be happy to mentor some small projects about running parts of MusicBrainz on AWS.

Artist credit utilization

Artists and artist pages are a very central convergence point for the data in MusicBrainz, but unfortunately the current UI doesn't fully capitalize on all the data available such as artist credits. This proposal is to redesign the artist and related pages with the intention of providing more thorough access to artist credit data.

Artist credits offer two features: one is the ability to credit artists with various alternative names and still link everything back to the one artist, and the second is to be able to assign multiple artists to a given recording, release, release group, etc.

Possible outcomes of this proposal would be the ability to:

  • "Filter" the data on the artist page based on what artist credit was used (similar to Discogs' artist name variation).
  • Find what all data a specific collaboration artist credit is credited to (similar to the current server's collaboration artist pages).
  • Select a "frequently used" artist credit when doing a lookup for an artist in the add release wizard.

Embeddable widgets

All the data in MusicBrainz is easily accessible to programmers, but it's not as easy to use the data if you're not a programmer. To allow third party websites (specifically bloggers) to use data from MusicBrainz we would like to create a set of widgets. Widgets will make it easier for someone writing an article about an artist, or a blog post reviewing a particular release to include correct metadata about the artist or release. It will also let their visitors (human or searchbot) know exactly which release or artist is being talked about.

Proposal Tracker

The StyleCouncil sometimes has a hard time keeping track of proposals. This project would develop an proposal tracker for the Style Council, either modified from an existing issue tracker or written from scratch. The goal is for anyone interested to be able to see:

  • the current status of a proposal (e.g. RFC/RFV/withdrawn/approved/implemented)
  • when it was last discussed on the mailing list
  • who is responsible for it
  • the proposal itself

Mobile MusicBrainz Application

It would be nice to have an Android application that allow editors to submit information to MusicBrainz from their mobile phone. This application could do some or all of the following:

  • Scan a CD barcode and lookup information about that CD.
  • Submitting barcodes using an existing barcode scanner application. A user could scan barcodes off Audio CDs in a music shop with this feature.
  • Mobile optimized pages for editing MusicBrainz data.
  • Mobile optimized pages for rating music and/or submitting tags.

This application must use a third-party library for processing all aspects of the barcode reading. This application is not a barcode/reading/decode application, but an application that makes use of other resources to process barcodes. Also, Android is preferred, but proposals for iPhone apps will also be considered.

UX Design for MusicBrainz Server

The MusicBrainz server is nearly fully re-written an much cleaner than the previous version. However, its still written by computer geeks who have little UX design experience. We would love a UX designer to apply for summer of code and help us work on the following issues:

  • The usability of our release editor.
  • The usability of our edit/voting pages.
  • The usability of core entity pages.
  • The creation of a MusicBrainz specific user interface design guideline that defines what the MB user interface should look like in the future. This document should aim to achieve a consistent user experience on the MusicBrainz server.

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.

Adding data into Musicbrainz is largely a manual process - which I think is unsustainable, (new releases are coming along much quicker than they can be handled). It would be interesting to look at some way of automatically entering data from outside the Web Interface (it would still require manual voting) or improvements to modbots for fixing existing data. This could range from entering a new release, creating a link to a Discogs release or converting (Disc 1) in titles to release groups. Ijabz

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