Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

Q&A: Ask OpenMRS »
Discussion: OpenMRS Talk »
Real-Time: IRC Chat

Resources

Skip to end of metadata
Go to start of metadata

How to Join

 Click here to expand...

 

In person

Courtesy, please

If you are joining remotely via telephone, Adobe Connect, or Skype, please use a headset-microphone, or at least earphones. Please use the mute feature when you are not speaking.

Interactive meeting - Adobe Connect

  • We routinely share a screen during the call. You can view the screen via our Adobe Connect meeting room at http://connect.iu.edu/omrsdf. For large meetings, the room has the ability to broadcast audio and connect to a telephone-based system as well, as controlled by the meeting hosts.

By telephone

  • US telephone number: +1-888-510-4073
  • Access code: 24222#

By Browser

Chat/IRC

  • Chat is available in the Adobe Connect meeting room (see above).
  • A backchannel meta-discussion during the meeting also occurs on IRC.

 

Agenda

 

  • Quickly review previous meeting minutes (5 min)
    • Release Process
    • OpenMRS 1.11
  • After-action review & next week's agenda (5 min)

In Attendance

  • You

Minutes

View at notes.openmrs.org

OpenMRS Developers Forum: 2013-04-03
Attendees
  • Michael Downey
  • Roger Friedman
  • Karl Wurst
  • Nyoman Ribeka
  • Wyclif Luyima
  • Burke Mamlin
  • Elliott Williams
  • Daniel Kayiwa
  • Ada Yeung
  • Darius Jazayeri
  • Rafal Korytkowski
  • Mhawila Mhawila
  • Joseph Kaweesi
Agenda & Minutes
  • TODO: Burke will get PIH presentation from Mike Seaton added to the wiki page
  • TODO: Burke & Darius to clean Road Map up
  • TODO: Send out an e-mail announcement to dev@ & implementers@ informing people about the new project. (Elliott)
  • Release Process
  • Reviewing the current release process
  • Timing of releases (i.e., setting some goals)
  • We never want to go more than a year between releases
  • Releasing an update (minor or major) to our reference application at least twice a year
  • Marchs & Septembers (e.g., merge code in Jan & July)
  • Releasing an update (minor or major) to our platform application at least once a year
  • Septembers (e.g., merge code in July)
  • When do we set "the date" for a release? Feature-driven or time-driven... or compromise?
  • We'll try time-based in the 2014-2015
  • Recipe for releasing (being a release manager)
  • Why isn't anybody taking notes here?
  • Need to consider separate release process page for reference application vs. platform?
  • Need more automated tests for OpenMRS 2.0
  • TODO: Testing discussion in dev forum
  • Need to get basic release testing automated & sustainable
  • Still just taking notes by myself. /me wishes we were better at taking notes during meetings.
  • s/etherpad/wiki/g (note that Burke has been better about copying & pasting notes into wiki after meetings)
  • TODO: We need to find way(s) to encourage implementations to help test new releases
  • What things could make it worthwhile?  Are there any incentives?
  • Release Testing Module was a good idea, but was stopped b/c of issues with getting module-specific data transferred.
  • Could modules support a testing interface (getTestData & saveTestData)?
  • Are there out-of-the-box approaches we could take to encourage testing?
  • Can we create demo sites with different combinations of modules?
  • We currently have 1 system for UAT on order and more can be obtained.
  • Plan on ordering 72 of them.
  • Dream on!
  • Ok. We can settle for 30.
  • Mike has built some pretty cool tools for exporting random/helpful subsets of data, deidentifying them, etc. There was also a SoC project about this sort of thing. => If OpenMRS can set up a hosted server with all the relevant modules, and we just need to get one implementation to send us realistic testing data.
  • TODO: really could use a realistic demo data set – i.e., great to have the tools, but where are the de-identified data?
  • Implementations probably feel more comfortable giving deidentified test data with limited access, just to the implementation itself plus 1-2 trusted OpenMRS devs/testers.
  • Contrived test data is safe for crowdsourced testing
  • Try to apply the "distribution" approach to testing releases. I.e. if an implementation tells us their modules + versions, and gives us their global properties and MDS packages of all metadata, we should be able to build a "testing distro", that can be quickly deployed by vagrant and/or other tooling.
  • OpenMRS 1.11
  • Strategy for 1.11
  • Get 'er done.
  • What does this mean as OpenMRS Platform diverges from OpenMRS 2.x?
  • OpenMRS 2.0 – our reference application
  • OpenMRS Platform 1.10 – API with web layer including REST (for now still has remnants of old ref app)
  • Going forward
  • Platform will be WAR + REST Web Services module
  • After Action Review
  • What did you expect to happen?
  • What actually happened?
  • What can we do better?

TODOs

Loading

Outstanding TODOs (0 issues)

Summary Assignee Created Due

Create a TODO: http://go.openmrs.org/todo

Transcripts

  • Backchannel IRC transcript
  • Audio recording of the call: Listen online or download - available after the meeting
  • No labels