Design and API review during Amarok DevSprint

Bart Cerneels bart.cerneels at kde.org
Mon Apr 20 15:08:29 CEST 2009


Hey all

It's always a good idea to prepare meetings, certainly when 14 people
are involved. So here is my proposal for a formal agenda for the dev
sprint.

* Architecture and API review
      o Meta/Collection
      o Meta::Playlist/PlaylistManager/Synhronization
      o Services
      o Meta::Playlist/PlaylistManager (this includes synchronization)
      o Biased Playlist (or replacement)
      o Scripting and unit testing

* UI design meeting
      (I propose this work process:)

   1. In a plenary meeting we have the chance to, individually, talk
about what we like and dislike about the current look of Amarok.
   2. The artist and usability group design a new look for Amarok
based on these recommendations and opinions, keeping in mind the KDE
HIG and a sense of "state-of-the-artfullness".
   3. After about one day this group will report to the rest about
their progress to allow corrections if needed.
   4. The artist group will present their design, in the form of
mockups, to the complete group. If alternatives are available there
will a public vote to determine what to implement.
   5. In the development period for Amarok 2.2 will try to implement
as much of possible.
   6. Amarok 2.2 will be eyewateringly beautiful.

* Set long term project goals for the 2.x series

I think we'll need some advice for the preparation of (and perhaps
help during) from KDAB, plasma, Qt-soft Berlin for the API and
architecture review. Those guys know their stuff and I know some of
you have experience with those.

Overall I want to get as much bang for our buck at this meeting. That
also means keyboard hacking time will be virtually 0 and have the
lowest priority. I hope you all agree a devsprint is not for hacking.

The agenda is also in the notebook. You can add there is wanted.
Discussion should be done here.

Bart


More information about the Amarok-devel mailing list