2016-08-18 Developers Forum

Owned by Tanya Khokhar
Last updated: Aug 18, 2016 by Burke Mamlin
2 min read

How to Join

 Click here to expand...

By Browser

By telephone

  • US telephone number: +1 201.479.2627

 

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

 

Â