Gx Sprint Agenda (Oct 22-24)

Objectives

By the end of the sprint we will have:
  1. A better product and code name
  2. Project Management issues resolved (aka Chris's note to core)
  3. The framework of the Gx Hacking document (i.e. http://subversion.tigris.org/hacking.html)
  4. A working implementation  of the basic Gx functionality. I'm thinking in terms of functionality:
    1. User management and permissions is operational
    2. The framework for administration functions is implemented
    3. images can be upload and organized into albums
    4. an extension framework is enabled
    5. An a standard theme is in place.
  5. Project Schedule in place with tasks assigned
  6. Implicit in above is a release schedule.

    Overview

    Approach

    In an attempt to maximize our productivity and address the diverse skill sets and interests of the people attending the sprint, I chose to organize the agenda in such a way that we start with the broadest issues and move to the more focused. 

    The agenda is based on the following "4-tier" architectural design with a clear delineation between the layers:



    Framework
    The framework consists of the chosen 3rd party framework to uses as a basis of Gx.  One of the deliverables of the Sprint is to chose a framework.

    Gx Framework Extensions
    What I consider in this category are all the things we need to add to framework for Gallery.  Things like (non inclusive list):

    Gx Features and Extended Features

    Presentation Layer
    This is how the information gets to and from the user to the various gallery functions.  I might be swimming up stream on this one, but I believe we need a clear separation of between the controllers and models that make up a feature and the various views that can display that information.

    Agenda

     Waterfall approach to the agenda.  Hopefully, given this schedule, which might be optimistic, we can be "cutting" some code by the end of the first day.
    gmc

    Task Detail

    The names in brackets are a first cut at someone to lead the discussion of that section.  If anyone  feels strongly about being or not being a leader things can be changed.

    1.    Introduction (Tim)
            Welcoming remarks, agree on agenda, etc.

    2.    Project Issues (Chris)
            There are some high level project issues that need to be decided upon:
    1. Coding standards (php and javascript); Unit testing (php and javascript)
    2. We need to come up with a "Hacking GX" document along the lines of: http://subversion.tigris.org/hacking.html Chris has offered to drive this as long as others actually contribute to it. This one single doc can serve as an entire entry point to developers that might want to work on GX, as well as a way for us to easily document our practices. It doesn't have to be a lot of work, but it's going to take a conscious effort from everyone.
    3. We need a public system for people to claim ownership of things to provide some accountability. "Action Items" were cute, but when people miss meetings with a lot of regularity, things don't get added to the list that people are working on, etc. Ccollab is nice, as are aspects of sf.net, but things just don't mesh together very well.   Chris has been using Chandler (http://chandlerproject.org/) both personally and with work, and it might be a more effective way to communicate as a team on who is doing what.  He has a Chandler server running and can spend time explaining this work-flow to people.
    4. Our support options are pretty rough. FAQs are great, but we have entirely too many entry points for people, and most of them don't get any response from us (RFEs, IRC, forums, paidsupport, etc). We need more user-to-user support and I'm not sure how to make this happen for end-users. I think with #2, we'll get more "casual" developers that are capable of supporting each other in the forums.
    5. Our releases take a long time, and are so huge that the blockers list includes things that are holding us back but that need to get out sooner than the next full point release. Release early and release often may be worth going back to. We'll need a build/release system and upgrade mechanism that allow us to put out new releases every couple of weeks.
    6. What do we want to do with RFE's.  We have a huge pile of cruft that is the RFE tracker. It contains every idea possible for an online media organizer and it's pretty worthless to us in it's current state. We should turn this into something we can use or stop presenting it to our users as such.
    7. Is there other technology we can use to make us more efficient (in conjunction with 3).   i.e. Google Documents, Skype, a Google group for core? etc.

    3.    Framework (Tim)
                Decide on the framework. 

    4.    Gx Framework Extensions (Bharat)
                 Discuss and decide on various extension we need

    5.    Gx Feature Set (Andy)
    1.  How to divide up the feature set into core supported, community supported
    2. What gets released as the standard (i.e. like the current minimal download type).

    6.    Presentation Layer (Chad)
    1. Discuss and approve Chad's CSS guidelines
    2. Extend wire frames for other key features
    3. Develop standard views

    7.    Wrap up Checkpoint (Chris)

    1. Project Issues (chris's stuff, coding standards, etc.)
    2. Framework decision
    3. Gx Framework extensions (install, support infrastructure, LM, DP)
    4. Feature set (core vs non core, SOA/ResTFUL etc)
    5. Presentation Layer (standard theme (Ux), embedding, rss, etc)
    6. Wrap up checkpoint