2011-12-01 Leadership Conference Call
Date
1 December 2011
How To Join
Contact @Dawn Seymour for more information on how to join the call.
In Attendance
Paul Biondich
Michael Downey
Hamish Fraser
Darius Jazayeri
Andy Kanter
Burke Mamlin
Mike Seaton
Dawn Smith
Ben Wolfe
Agenda
Topic | Topic Leader(s) | Time | Category | Notes |
---|---|---|---|---|
How to Handle Organisations that want to Assign Copyrighted Material to OpenMRS | @Darius Jazayeri | 15min | License | Â |
Annual Leadership Meeting | @Dawn Seymour | 20min | NGO | Purpose: Set the date for the next annual leadership meeting. Darius: Whether in person or via video conference, good to have these convos 2x/yr |
OpenMRS Core Developer Team: Re-structuring | @Mike Seaton | 25min | Administrative | Purpose: Further discuss Mike's email about restructuring the core dev team and their responsibilities |
Minutes
How to Handle Organisations that want to Assign Copyrighted Material to OpenMRS
Darius: Can people contribute code to OpenMRS to further their needs?
Paul: Yes, but it depends on what people the goals are with that code
Hamish: For this specific example, Brigham Young wants to be able to use the code for research purposes.
Darius: Right now it's on hold as the BYU lawyer makes an iteration to the code rights/assignment
Darius: They want to assign us the copyright and have us put the code into the repository
Paul: Formalise the documents that we used for the LLC, and that team can use it as a template
Annual Leadership Meeting
Paul: January is out for me. Let's start at February
Darius & Burke: No to last 2wks in March
Mike: No President's Day
Andy: Last week of February is bad
Ben: Training in March
Downey: Week of Spring Break
Go with the first 2wks of March
Darius: I'll be flying back to the States on 16 March
Paul: Do we have this meeting in person?
Darius: If we have the meeting more than 1x/yr, just have one in person
Darius: Have the first in person and another mid-year over the phone
Paul: Where do we want to have it?
Paul: I'll offer up Indianapolis as an option
Andy: New York may not be the best idea
Dawn: Keep in mind that Chris Seebregts will be flying in too
Paul: 1 night and 2 days in duration: Thursday & Friday
OpenMRS Core Developer Team: Re-structuring
Mike: This is response to the "PIH and OpenMRS Core Development" email
Ben: Big question is: Are the sprints getting everything out of sprints that we need?
Ben: Mike's proposal isn't that different from what we're doing now other than getting confirmation of commitment from PIH for sprints. This also includes a commitment from us of knowing what PIH wants to sprint.
Mike: My point is that sprints don't need to happen.
Paul: When do we have the space to create the modular architecture?
Paul: What Ben is saying that there aren't immediate things that are implementation directed, but there may not be an immediate reason for implementations to participate in a sprint.
Paul: Does PIH have the cycles to be involved in the OpenMRS sprints?
Mike: Yes. We need to do a better job of coordinating the PIH release schedule with OpenMRS.
Paul: I'm asking for PIH to help in the design and ticket writing for sprints that will be beneficial to PIH in the long-term
Darius: I'm looking at the sprint page right now. The Sync sprint for PIH was in November, before that the last PIH-related sprint was in April and it was bug fixing.
Mike: If you look at the sprint page, there's nothing for the next few weeks, but we've put in requests long ago for PIH sprints in OpenMRS.
Darius: This highlights that we need to do a better job of listening to implementations. In our overzealous attempts to make sure we're not getting sidetracked details, we've gone too far and now we're not doing things relevant to implementations. The impetus is on OpenMRS core to draw PIH ppl, AMPATH, Jembi and others to core sprints by making those core sprints of relevance to the implementation. It doesn't mean we'll build feature x for PIH-Rwanda, but that PIH wants to do an HTML form entry sprint, so that's what we do
Ben: I like Mike's suggestion on not only focusing on a release for 1 cycle of the year. There are modules to work on and bug fixes. I don't know how to correct the problem we have where we ask for features from implementations, but that still doesn't make them happy.
Darius: Downey, when talking about continuous deliver with ThoughtWorks, should we be pushing each new release to be tiny (1 new feature), but they come out more frequently?
Downey: I think that idea can be, but implementing some of the ideas within CD and scrum will help alleviate some of those pain points. One thing that can help is figuring out how to identify and prioritise those features of everyone at the table (implementers, large and small scale) and find a way to prioritise it. This way everyone feels satisfied in one way. Smaller releases is one way to do this, then we can do faster releases. It can be difficult for people to do upgrades in the field.
Paul: I like the idea that Mike S had around having Feb 2012 release that has core this, module this, module this, and making compositions around the timeline and having a process around what the core and modules do independently.