Technical Roadmap Planning
We are constantly working on improving our roadmap planning process. When OpenMRS started, we didn't have a formal roadmap and stumbled through version releases. By release 1.5, we had developed the beginning of a Release Process. By 2012, we found that a purely road map-focused process was not meeting the needs of our implementations, so we formed a Roadmap Planning Group to help coordinate and continuously review/improve our road map process. We also created a Roadmap Planning Mailing List for discussions focused on designing/improving/feeding our road map. Our Road Map planning group failed to get enough momentum, so we fell into a those-who-are-able-and-willing-do-their-best-at-creating-a-straw-man-and-let-people-react-to-and-shape-the-roadmap-as-needed approach.
Canvassing for New Ideas & Features
Several sources are considered in determining which features get added to OpenMRS, including:
- OpenMRS implementation site needs
- OpenMRS priorities
- Features requests within the issue tracker
- Needs of ongoing projects
- Module authors
- Needs of ongoing grant-funded projects
- Scrum of Scrums
- Discussions from Design Forum
Other channels:
- Review of current functionality of current ref and platform apps to identify features that could be improved.
- Continuous review of competitor applications both open and proprietary systems
- Implementer's monthly call ( to be established)
How do we determine features for the next release?
- Features for the immediate next release are determined by :
- Reviewing OpenMRS Priorities
- Review tickets assigned to next two releases
- Review OpenMRS someday tickets
- Tickets that are likely to be punted for third time should be considered for "wontfix" or moved to OpenMRS Someday
- Release after next
- New Features
- Any modules that should become core modules or absorbed into core?
- Review how modules are moving along with OpenMRS release
A survey will be circulated on talk presenting features that have been compiled for validation by the community. At the completion of the survey period, a prioritization meeting is held during one of the PM calls to finalize the list of features.
Platform 2.3 features validation can be found here
Platform Roadmap Planning Process:
Objective Lead: Burke Mamlin Co Lead: TBD
| Status | Activity | Resources Needed | Duration | Completion Date | Comments | |
|---|---|---|---|---|---|---|
| 1 | COMPLETED | Agreeing the vision and strategic goal of the RoadMap activities | Community Core Ops Lead | Once a year | March 4th 2019 | |
| 2 | COMPLETED | Call out on all OMRS Communication channels announcing the commencement of the RoadMap planning Process | TPM | 1 week | March 15 2019 | |
| 3 | COMPLETED | Identification of volunteer team members for core activities of the group, such as release management, BA, QA , testing | TPM Community Implementers Individual contributors | Continuous | April 15 2019 | |
| 4 | COMPLETED | Receive new feature requests from community Prioritization and Validation of feature requests Confirmation of feature owners and resourcing to develop feature (or go it alone) | TPM Community Implementers Individual contributors GSOC?? | continuous (2-4 weeks window) | March 30 2019 | |
| 5 | STARTED | Commencement of Release Process | Release Manager, Community Dev's | 8-15 weeks | June 7th 2019 | August 31 |
| 6 | STARTED | Quality Assurance & Testing | QA , Community, Community Dev's | 4-6 weeks | ||
| 7 | COMPLETED | Application pushed for community alpha release (or criteria that meets an alpha release) | Release Manager, Community Dev's | 4-6 weeks | ||
| 8 | COMPLETED | Beta Release | Release Manager, Community | 4-6 weeks | ||
| 9 | NOT STARTED | Completion of Release Process & Application Launch | Release Manager | 4 weeks |
Reference Application Roadmap Planning Process:
Objective Lead: TBD Objective Co Lead: Burke Mamlin
| Status | Activity | Resources Needed | Duration | Completion Date | Comments | |
|---|---|---|---|---|---|---|
| 1 | NOT DONE | Agreeing the vision and strategic goal of the RoadMap activities | Community Core Ops Lead | Once a year | Still looking to identify a Lead from the community | |
| 2 | COMPLETED | Call out on all OMRS Communication channels announcing the commencement of the RoadMap planning Process | TPM | 1 week | March 22 2019 | |
| 3 | STARTED | Identification of volunteer team members for core activities of the group, such as release management, BA, QA , testing | TPM Community Implementers Individual contributors | Continuous | April 15 2019 | |
| 4 | COMPLETED | Receive new feature requests from community Prioritization and Validation of feature requests Confirmation of feature owners and resourcing to develop feature (or go it alone) | TPM Community Implementers Individual contributors GSOC?? | continuous (2-4 weeks window) | March 30 | |
| 5 | ONGOING | Commencement of Release Process | Release Manager, Community Dev's | 8-15 weeks | August 2019 | |
| 6 | NOT STARTED | Quality Assurance & Testing | QA , Community, Community Dev's | 4-6 weeks | ||
| 7 | NOT STARTED | Application pushed for community alpha release (or criteria that meets an alpha release) | Release Manager, Community Dev's | 4-6 weeks | ||
| 8 | NOT STARTED | Beta Release | Release Manager, Community | 4-6 weeks | ||
| 9 | NOT STARTED | Completion of Release Process & Application Launch | Release Manager | 4 weeks | ||
| 10 | ||||||
| 11 |
How do I participate in the Technical OpenMRS Road Map Planning process?
Our hope is that through simply participating in the community (primarily via OpenMRS Talk), your voice will be heard and will help improve our roadmap. We especially welcome Business Analysts, Designers or volunteers who can serve as release managers.
What you need to become a release manager can be found here
What you need to become a Business Analyst can be found here
What if I want to propose a new feature?
New features at a minimum it must meet the following criteria:
- Value to Health Equity
- Is there improvement in health status
- Patient Safety impact
- Quality of Care impact
- Reusable module
- Available resources
- Who benefits
- To community
- More limited context
- Potential to collaborate to develop feature
Features can be recommended via the following methods:
- creating a ticket on JIRA
- Completing this form here
- Posting a topic on Talk.
We aim to respond to each feature request within 3-5 business days and aim to assign a business analyst to aid requirements drafting within 5-7 business days.
Other Criteria we use to asses which features are included in the roadmap are
- Feature can be developed via collaboration (Synergistic opportunities) (ideally with funding)
- Can meet one/more of the following requirements:
- A feature that will enhance the core functionality of the system (performance)
- A Feature that the community has been asking for sometime
- A feature that has not been asked for, but will make the excited
- A catalytic feature
- Reasonable time & cost to completion
- Time to deliver vs. Impact?
- Sustainability
- Feasibility, desirability, viability,