History:Turning Your Ideas Into Reality

From MusicBrainz Wiki
Jump to navigationJump to search

RobertKaye wrote a great How To Guide. The examples in the text are all a bit outdated (where it says "current" in the text), but his point is still valid.

There have been a lot of good FeatureWishes discussed on the MailingList as of late, yet we've never published any sort of guidelines for how ideas get translated into actual MusicBrainz features. So here goes...

If you have a cool idea for MusicBrainz, the first thing to do is to post it on the UsersMailingList to discuss the idea with the general MB public. Depending on the nature of your idea, there are a few different courses to take:

  1. For SuggestionsToCurrentFeatures, FeaturesCurrentlyInDevelopment, or SmallNewFeatures: Propose the idea and see if you can get one of the core MB server developers (currently: Dave, Matt, Rob) to embrace the idea. If the core developers embrace the idea and decide to act on it, you're done. If a core developer likes the idea, but doesn't have time/inclination to carry it out, carry the idea out yourself, or find someone who is willing to carry it out on your behalf.
  2. For LargerNewFeatures: (e.g. SurvivalOfTheFittest moderation) Write up your idea on the wiki and then propose it on the MailingList. Work with the community to reach consensus on this idea -- it is especially important to get a sign off from TheCoreDevelopers, because they are the ones what will need to accept and roll out the new feature.

For some features TheCoreDevelopers sign off has already been done (VotingImprovements, EditorRating, AddingMoreDataElements, etc) but there remains a lot of work to be done in nailing down *exactly* what needs to be done. For these features it would be helpful for one person to "champion an idea" and to setup a wiki page and define the feature in painstaking detail:

  1. Describe the overall purpose of the idea
  2. Describe common use cases -- how will a user interact with these features.
  3. Describe the user interface elements in detail -- what new links, buttons, tables, pages are needed to accomplish this. How does the user interact with the improved website? How does it differ from today?
  4. Describe what effect this feature has on the underlying database. How, what, why and when will the underlying database be affected?

Having a person adopt each of these proposals and nailing down the details so that the developers get a clear idea of what this feature is supposed to do, will help the developers get these features implemented. See ModerationImprovements for a start of this for the voting improvements that need to be taken care of -- this page is still incomplete and needs more features added and more fleshing out -- but you get the idea.

I want to applaud Robert Munro's efforts for his idea of SurvivalOfTheFittest -- Robert has developed an idea and is actively seeking community support for his idea. Exactly what an IdeaChampion should be doing. However, Robert hasn't managed to convince the core developers on his idea yet -- in part because his idea is expansive and would take months of work to realize. Convincing another person to spend months on one feature is difficult, since all the developers have tons of stuff on their plates already. (Whether that is a job, life or other MB features -- matters not) My overall impression is that if you want to carry out radical ideas inside of MB, you need to be prepare to spend months yourself becoming part of the core dev team and putting in serious hours to realize your ideas.

As far as I can see right now, the following (not as vast) are IdeasThatHaveCoreDeveloperSignoff and need IdeaChampions:

  • VotingSystemImprovements (finish off the wiki page mentioned above)
  • Moderator <-> moderator CommunicationImprovements
  • EditorRating
  • Add new data elements to the MB database (AdvancedRelationships).

In all of this there are a few key things to remember:

  • Don't implement a feature that TheCoreDevelopers don't like. Ultimately they will need to accept your changes and integrate them into the site, and if they don't think your feature will improve MB, then your feature will not get accepted.
  • Generally, implementation of a new idea takes 50 - 100 times longer than the coming up with the idea in the first lace.
  • In order to keep the site moving forward, we work with smaller changes at a time. Doing really big changes requires a serious amount of dedication to pull off and can leave the users in a lurch as nothing changes on the site wile the devs are off doing the massive next generation changes.
  • Being an IdeaChampion does not guarantee that your favorite feature will get implemented in a reasonable amount of time. The core developers have day jobs, are studying, or in my case have too many responsibilities already.

Once I finish off my tagger grant work, I will return to adding new features to the MB site -- give me a couple more months and then I can help Dave again. However, to give you an idea on how much time I spent working on MB last year: I spent 1 month earning some money and I spent 1 month on vacation (of which some was work). Thus I spent 2200 unpaid hours last year working on MusicBrainz. (10 months = 44 weeks @ 50 hours/week avg = ~ 2200 hours).

I hope this gives you folks a better idea of what it will take to realize your ideas and how you can help more. If you like to help out more, champion one of the above ideas and help us define the new feature in detail. This type of work will makes it possible for new developers to step in and take an active role MB development.