It it time for us to start the process towards the next schema change release. Starting today and for the next two weeks, we’re going to seek people to be the champion (sponsor) of a ticket. If you feel strongly about a schema change ticket getting taken care of, you should consider championing this ticket. Once you’ve decided to do adopt a ticket, you should assign the ticket to yourself.
Then, over the next two weeks it will be up to you to do the following:
- Drive consensus around the core concept of the ticket. If you go through the process of working up a ticket, but no one agrees with what you’re proposing, you’ve wasted your time. Make sure that you get buy in from others in the community. For instance, if Nikki doesn’t like it, chances are its not going to fly. 🙂
- Each schema change feature requires two tickets: 1) An SQL ticket that implements the actual changes to the database and defines the queries used to fetch the data. 2) A UI change ticket that implements the UI portions of the schema change ticket.
- Ensure that the ticket clearly states what needs to be done to implement the ticket. The ticket should essentially become or link to a requirements document. This requirements document should explain what the new feature should do. It should not explain how it should be done — we should leave the how to our developers who are going to implement the feature.
- Provide as much supporting documentation as you can. Mock-ups for UIs are deeply appreciated (even if they delve into the how realm of things) and very useful for meaningfully discussing these tickets.
- Have the ticket reviewed by a developer for clarity and completeness, then address any issues said developer may raise.
On 15 February, we’re going to look at the list of tickets that people have taken on and choose the ones that are clear enough to move forward. If you’ve done all the work outlined above, the chances are good that your ticket will be chosen to move forward. If your ticket is chosen to move forward, there will be more questions that the developers will raise — hopefully those can be tackled in the space of a week. After that we will take all of the well defined tickets and schedule them for implementation. All the other tickets that are not clear to implement will be rejected and will have to make another pass though this process in the autumn.
If you’re still interested, here is the list of schema change tickets that should be considered for this.
We’re going to follow the this schedule:
- 1 Feb: Schema change ticket selection starts
- 15 Feb: Select schema change tickets for implementation, start making tickets fully actionable
- 1 March: Tickets must be fully actionable. Tickets that are not actionable will be dropped from the 15 May release.
- 15 March: SQL tickets must be fully implemented.
- 1 May: UI tickets must be fully implemented, start final ticket testing phase
- 15 May: Release day
All of these dates have been added to our new community calendar.
MetaBrainz Blog 