Page tree
Skip to end of metadata
Go to start of metadata

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 to we determine features for the next release?

  • Features for the immediate next release are determined by :
  • 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


StatusActivityResources NeededDurationCompletion DateComments
1

COMPLETED

Agreeing the vision and strategic goal of the RoadMap activities

Community

Core Ops Lead

Once a yearMarch 4th 2019
2

COMPLETED

Call out on all OMRS Communication channels announcing the commencement of the RoadMap planning ProcessTPM1 weekMarch 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

ONGOING

Commencement of Release ProcessRelease Manager,  Community Dev's8-15 weeksJune 7th 2019
6NOT STARTED


Quality Assurance & Testing

QA ,  Community, Community Dev's4-6 weeks

7NOT STARTED


Application pushed for community alpha release (or criteria that meets an alpha release)Release Manager, Community Dev's4-6 weeks

8NOT STARTED


Beta ReleaseRelease Manager, Community4-6 weeks

9NOT STARTED


Completion of Release Process & Application Launch

Release Manager4 weeks



Reference Application Roadmap Planning Process:

Objective Lead: TBD  Objective Co Lead: Burke Mamlin


StatusActivityResources NeededDurationCompletion DateComments
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 ProcessTPM1 weekMarch 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 ProcessRelease Manager,  Community Dev's8-15 weeksAugust 2019
6NOT STARTED


Quality Assurance & Testing

QA ,  Community, Community Dev's4-6 weeks

7NOT STARTED


Application pushed for community alpha release (or criteria that meets an alpha release)Release Manager, Community Dev's4-6 weeks

8NOT STARTED


Beta ReleaseRelease Manager, Community4-6 weeks

9NOT STARTED


Completion of Release Process & Application Launch

Release Manager4 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:

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,




  • No labels