The purpose of this document is to document the goals & tasks we believe OpenMRS needs to meet the objective in time for sharing & discussion at OMRS15.

We should strive to come up with metrics for each Goal. Each task should have one or more objective success criteria (i.e., how do we know that the task was achieved?).

We will draw out our achievable-if-resourced goals for 2016 (i.e., when defining goals & tasks for 2016, assume that we can get the resources to achieve them), use those to define the additional resources needed, and then review those and define which are at risk or will not get done without additional resources.

Team (responsible for getting goals documented)

Objective

Outputs before Singapore

Outputs after Singapore

Goals & Tasks

Philosophy and Process

Road Map 2016

Parking Lot Items:

Team (responsible for getting goals documented)

Burke Mamlin (lead), Andy Kanter, Kaweesi Joseph, Darius Jazayeri, Sri Maurya Kummamuru, Jan Flowers

Objective

Develop and evolve the OpenMRS Platform, the foundational product of our community

Outputs before Singapore

• We want to have a straw man for objectives & tasks for the Platform in 2016 that can be presented to the community and guide discussion at the Summit.
• Some idea of metrics for each goal
• Some idea of success criteria for each of the tasks
• Description to Leadership of process for estimating resource requirements (so that we all can wrangle them)
• Estimate of minimal resourcing needs

Outputs after Singapore

• A “final” set of objectives & tasks for Platform in 2016, vetted by the community.

• Objectives, Philosophy, and Process
• Technical Road Map

• Estimate of ideal resourcing needs

Goals & Tasks

Philosophy and Process

• The OpenMRS Platform Road Map is driven by consumers and managed by a coordinating group, in a well-known way

1. Identify, engage, and describe users of the platform

• Document the types of users of the platform and how each can contribute and shape it over time (e.g., Implementers, Organizations, Developers, Architecture Strategic Goals)

1. Metrics:

1. Documented types of Platform Users on wiki(1)

2. Note:

1. look at implementers data available (that Judy presented)

• Look for ways to monitor usage & infer use of the platform, identify new user groups, detect problems, etc.

1. Metrics:

1. At least one mechanism introduced to look at platform usage patterns

2. Notes:

1. Consider collecting information at the time of Platform download 

• Define (and fill) a role to oversee Platform user engagement - (maybe a shared role)

2. Published Platform Road Map

• Publish Platform Road Map on openmrs.org

1. Metrics:

1. There is a Platform Road Map page on the wiki, and it is up to date for next (1-2?) releases
2. There is a link from somewhere on openmrs.org to the Road Map wiki page

• Promote reference to the road map

1. Metrics:

1. Short links
2. Links used in forums

3. Describe how people or organizations can influence and contribute to the Platform Road Map

• Define & document process for how ideas, resources, and/or ideas+resources can influence the road map

1. Metrics:

1. The majority of New Feature tickets in the 2016 Platform release (e.g. 2.1) went through the platform road map process

4. Describe how the Platform Road Map is prioritized, and how people or organizations can influence the prioritization. (Parking lot items)

• Define & document how milestones are prioritized
• Concretely describe how a platform consumer can raise the priority of an item of interest.
• Have a process identified of how an implementer can contribute back to the platform

• The OpenMRS Platform will be released on a predictable schedule

1. Document and announce 2016 OpenMRS Platform release schedule

1. Metrics:

1. Documented page describing the release process and schedule
2. At least one new release of the Platform in 2016, that happens in the scheduled month

2. Define role & expectations of Release Management Lead (for Platform & Ref App)

1. Identify and describe the release process and schedule
2. Manage the release process by facilitating the release managers
3. Keeping the release process current

3. Communicate effectively with the community before releases to anticipate issues (e.g., info for module authors, distributions, etc.)

• The OpenMRS Platform will be scalable & reliable

1. Define the current limitations (concurrency, number of obs, number of patients, number of concepts, …)
2. Upgrade and Installation Testing as part of release process

• Installation testing automated, maybe through CI
• Upgrade path identified and displayed in the release schedule/ platform release timeline
• Identify and do some platform upgrades for known implementations to come up with some summary of the amount of effort needed to upgrade to the platform being released (needs discussion)

3. Roadmap includes a spike on scaling OpenMRS bigger than anyone has done so far, and identifying bottlenecks to be addressed

• The OpenMRS Platform will stay current, relevant, and accessible

1. Create a clear process for regular reviews of that architecture

• Create an OpenMRS Platform Architecture Review Board

1. Identify and publish Quarterly/Half-year dates to have this architecture review

2. Define what the Platform is and what is should/could be

• Define which modules can be incorporated into the platform and how those can be supported and sustained
• Define the governance for what is in the platform
• Add Define and begin building the Web framework component for the Platform (Module Management, Open Web Apps Reusable Components, openmrsjs, etc.)

3. Postgres Compatibility

• The OpenMRS community will ensure consistent, productive development resources exists to build and refine the OpenMRS Platform

1. Sufficient “always on” resources to empower/leverage the volunteer community to build the OpenMRS Platform as effectively as possible

• Be able to identify and effectively use product owners and subject matter expertise

1. Metrics:

• Different product owners and subject matter experts identified and listed (within 6 months)

• Build a reliable technical project management team

1. Metrics:

• At least one full time technical project manager (within 3 months)

• Improve our ability to convert design ideas to actionable tickets

1. Metrics:

• At least one BA (within 6 months)
• Some level of UX support (need to determine based on 2016 experience if this is always-on or can be ad-hoc)

• Reliably and quickly review & respond to issues (bugs, enhancements, etc.) for the Platform

1. Metrics:

• Handled by the developer team.
• Number of unvetted Platform tickets is shrinking (not growing)
• Platform tickets get a response within 3? working days

• Reliably and quickly review and merge volunteer contributions

1. Metrics:

• Continues to be handled by the developer team?
• All OpenMRS Platform pull requests reviewed and/or merged within 3? working days
• All OpenMRS Platform merged contributions go through QA within 5? working days

• Constantly iterate on improving workflow and experience for Platform development, so developing for OpenMRS is a great (and always improving) experience

1. Metrics:

• Development environment can be set up in less than 15 minutes
• Hello World can be achieved in less than 1 hour
• Updated Developer’s Guide in 2016

• Produce and maintain technical documentation, and make it easy to find

1. Metrics:

• Published living REST/FHIR documentation
• Published living Java API documentation
• Published and updated Architecture Overview
• Lead an external review of platform documentation
• A process for maintaining and improving documentation
• Documentation is commonly referenced in community discussions

• Cultivate experts to advise on a regular basis (e.g. FHIR & REST expertise, API expertise, and other technical expertise relevant to the platform)

1. Metrics:

• At least one expert identified (within 12 months)

2. "Sufficient dedicated development resources" to consistently implement Platform road map items and respond to critical bugs with a minimum velocity, as volunteer effort fluctuates

• Technical Project Manager
• BA
• Dedicated developers

1. ≥4 devs focused (in the zone) on a development activity/sprint
2. ≥1 dev supporting the community
3. ≥1 dev working directly with an implementation

• QA
• Technical documentation
• Assumption: no need for dedicated UX. (Verify this over 2016.)
• Assumption: infrastructure (dev ops) supplied by community
• Perhaps educators/implementation specialists, others, might be a part of the team (volunteers)

3. Understand and Grow the development team

• Metrics to assess contributions to github
• Create tools and processes that help developers be Devs productive in 1 hour

1. Road Map for SDK

• ≥10 people doing code review + pull requests

1. ≥4 within 3 months, ≥7 within 6 months, ≥10 within 12 months

• ≥10 active /dev/5s (within 12 months)
• Begin defining “lieutenants” to delegate authority (e.g. volunteer tech lead for a specific portion of OpenMRS, who thinks about this ≥ weekly and has some authority & accountability in the area)

1. REST and FHIR web services
2. API
3. Security
4. Databases
5. Documentation
6. …

2016 Resourcing Goal (Dedicated resources)

• 1 FTE of Technical Project Manager (within 3 months)
• 1 FTE of Lead BA with ability to build strategy & lead volunteers -OR- 2 FTE Entry-Level BAs (within 6 months)
• Three additional dedicated developers (within 6 months)

• ≥4 devs focused (in the zone) on a development activity/sprint
• ≥1 dev supporting the community
• ≥1 dev working directly with an implementation

• 50% FTE of QA (within 12 months)
• 100% of an FTE of technical documentation (within 12 months)

Notes

• Additional resources to support modules added to the platform

• Discuss & define the list of modules that belong in the platform (e.g., reporting, idgen, …)

• Map out the lifecycle of a module and criteria needed to become part of the platform

• Stable
• Well-tested
• Used by ≥2 implementations
• Headless (does not depend on UI framework)

• Consider an OpenMRS IDE package
• 50% QA is awfully low. Rule of thumb is often 1-2 QA/dev

Objective 1.1: The OpenMRS Platform Road Map is driven by consumers and managed by a coordinating group, in a well-known way

Objective 1.2: The OpenMRS Platform will be released on a predictable schedule

Objective 1.3: The OpenMRS Platform will be scalable & reliable

Objective 1.4: The OpenMRS Platform will stay current, relevant, and accessible

Objective 1.5: The OpenMRS community will ensure consistent, productive development resources exists to build and refine the OpenMRS Platform

Road Map 2016

• The OpenMRS Platform will have a fully realized and well documented API for health record keeping functions

1. Document the OpenMRS Platform functional architecture
2. Living REST API documentation (i.e., Interactive REST documentation provided by a module with static documentation drawn from source code)

• The OpenMRS Platform will be scalable (1-2 dedicated devs)

1. Perform formal load testing of the OpenMRS Platform
2. Design and resource plan for clustering support

• Introduce Higher Level Functions within the Platform

1. Initial implementation of decision support API

• Content

1. Include core terminology services in platform (support under Objective 6)

• 3 mo:  publish/subscribe
• 6 mo:  proposals, collection
• 12 mo:  all concept management within platform, not just packaging?

2. Assess/create terminology needs road map for upcoming use cases
3. Include indicators in the CIEL dictionary
4. Move toward vision of vertical packaging

• Metadata mapping

5. Make localization of concepts easier

Parking Lot Items:

Strategic Goal 1:

Point 4:

How can the tickets be prioritized:

1. Following the normal process - will be completed in the order they are picked up - (The ones high in the priority of the list will be encouraged)
2. Consumers coming with contributors can complete the tasks after they have been added to the release roadmap
3. Volunteers can be hired by consumers with funding to complete the tasks they want to get released.