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

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.