Date

11 September 2008

In Attendance

Burke Mamlin
Brian McKown
Ben Wolfe
Sam Ndichu
Darius Jazayeri
Justin Miranda
Mike Seaton
Andreas Kollegger
Saptarshi Purkayastha

Starting a road map
- Within Trac and/or the wiki
- Prioritization process (at least to get started)
Running production implementations – from tags, trunk, branch?
- Best practices / options – e.g., currently AMRS is using latest stable release + patches for subsequent features/fixes we want. Could this be an amrs branch? Or an amrs tag? Or in an /openmrs-implementation folder off of root?

Talked about rolling cohort report designer branch into trunk
Discussed options for creating a implementation-specific tags that contain a set of patches desired by a particular implementation
- It was felt that rather than encouraging a lot of implementation-specific branches, we should look for ways to follow a more predictable timeline and ways to more efficiently get patches and features that are ready for review into trunk
Talked about creating a timeline
- It was felt that we don't currently have enough full-time developers to handle all of the upcoming features in a predictable timeline
- We thought of some ways to improve things
  - Schedule code review 2-3 times each week for an hour or two, based on need. But make this scheduled and required for some of the full-time developers, so we're always making progress in code review each week.
  - Create a timeline with dates only for patches and features that are completed – i.e., ready for code review. Those features that are still in design or not finished being coded (not quite ready for review) will not be placed on the timeline; rather, those patches and features still in progress will be listed without specific delivery dates (until we have the developer cycles to be more predictable with these dates).

...RG was cut from the call when their bandwidth in Kenya suddenly dropped to near zero.