2016-08-18 Developers Forum
How to Join
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