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)
  • Platform Technical Road Map – Objective 1.1
  • Review next meeting agenda

Minutes

Attendees
  • Jamie Thomas
  • Darius Jazayeri
  • Burke Mamlin
  • Ada Yeung
  • Wyclif Luymia
  • Srimaurya Kummamuru
  • Daniel Kayiwa
  • Willa Mhawila
  • Jeff Neiman
Agenda
  • Platform Technical Road Map – Objective 1.1
Notes
Who do you think are the users/consumers of the OpenMRS Platform?
  • Implementations of OpenMRS
  • Service providers who implement OpenMRS for others
  • orgs who have OpenMRS implemented for them by some service provider
  • Distributions of OpenMRS
  • Module authors
  • Organizations with vested interest in or dependency on the Platform 
  • Academic Institutions using OpenMRS
  • Developers who contribute to openmrs-core (and the rest of the platform)
Are there people/groups who are not currently users of the Platform We should be targeting?
  • Other projects who could leverage OpenMRS as part of their solutions
  • Strategic partners
  • Vendors of systems that can integrate with OpenMRS
Are there people/groups who may be using the platform, but should not be our (community) focus/priority?
  • Hackers
  • Individuals needs/opinions/suggestions that do not include investment
  • People using OpenMRS solely for learning
  • e.g. Global North colleges using OpenMRS to teach about Open Source
  • Developer-defined features/priorities
  • Making developers efficient/productive definitely IS a goal, but the road map should not be developer-driven
Is the Technical Road Map page sufficient?
  • More effectively giving people fair warning of upcoming features
  • For example, we created a mailing list long ago to target module authors to notify them of upcoming changes. This could be a Talk forum and/or creating a distribution list via modulus (published modules)
  • Improve accuracy of Road Map page to reflect where efforts/resources will be directed
  • Indicate what is *really* scheduled work (currently, things listed under the next Platform and Refapp releases), versus what's really just a backlog (currently, things on the Refapp 2.6+ and Someday sections)
  • Better reflect reality (e.g., currently largely driven by what organizations are prioritizing, with a nudge towards community-priority tickets)
  • Improve documentation and design of wish list (someday) features
How should the platform road map be prioritized?
  • Have guidelines that let developers & implementations know how things get prioritized
  • We should be more honest, and make sure people actually know that mostly things are *not* prioritized in any intentional way
  • Clarify how legacy versions are supported
  • Help describe how anyone in the community can backport a feature to an earlier version (including what is or what is not appropriate for backporting)
  • Explicit product architecture team (mix of developers/BAs/PMs/SMEs/Product owners) driving the vision
  • Responsible for balancing all inputs and defining the priorities
  • Generates the priority-ranked backlog of tasks/projects to reach the vision
  • Not responsible for driving day-to-day development
  • Invest in defining/describing projects/features
  • Share these (e.g., via wiki or Talk), allowing volunteers (individuals or orgs) to take them on
  • Consider having feature-driven releases (i.e., release manager's job is to get feature X into a release)
  • Separate Platform and Reference Application technical road maps
Related:
  • Bahmni's Process
Who should constitute the OpenMRS Platform architecture Review Board?
  • Representative(s) of Implementer Community (e.g., Jan Flowers)
  • Representatives of users of the Platform
  • Implementer Community (Jan Flowers)
  • Orgs (TW, PIH, Regenstrief, I-TECH, Soldevelo, etc.)
  • Module authors
  • Experts

 

Transcripts

 

 

  • No labels