Future MusicBrainz Development Work
These are proposals that are planned for the future of MusicBrainzDevelopment.
- Please only put links to topics here that are not already being worked on.
- If you have just an idea or a suggestion, it should first go to NewFeatureSuggestions for comments and feedback, and only be listed here once the proposal has stabilized.
- Things that are actually being worked on belong in CurrentWork.
Please do not just add a new list item but use TextInsteadOfLists to describe the feature in two sentences. See also TurningYourIdeasIntoReality or HowToWriteFeatureSuggestions for help on how to do that.
Next Generation Schema
There are efforts to work towards the NextGenerationSchema of the database which tries to solve a lot of problems of the current schema and tries to bring the data closer to reality. As this is not an easy process, it has been structured under some collaborative modelling pages: ObjectModel for finding out what kinds of objects we are dealing with and we would need to store and AspectModel to split them into several aspects which all have a different view on the data.
After finishing that process we can start to build a new DatabaseModel which covers ReleaseGrouping, ReleaseAttribute and ReleaseEvent changes, TrackGrouping, multiple artist support and much more. This model should regard that we have to DisentangleInterfacesFromSchema so we also need to build a ViewModel separatly.
Google Summer of Code
MusicBrainz is applying to be part of the Google Summer of Code project. Check out the proposed projects on our SummerOfCodeIdeas page.
Survival of the Fittest / Wiki Style Moderation
SurvivalOfTheFittest/WikiStyleModeration is a completely new moderation system that works a bit like a Wiki. It was introduced by RjMunro. See also AdvancedModeration (deals also with the EditorRating). It is unlikely that we will implement it by making a big change to MusicBrainz but there are small StepsTowardsSurvivalOfTheFittest that may already be part of the CurrentWork.
The page ModerationImprovements itself lists too many different items and should probably be split. E.g. CommunicationBetweenEditors needs to be split out (especially since it has already been implemented, mostly).