2016-08-18 Developers Forum
Owned by Tanya Khokhar
How to Join
Click here to expand...
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