Part of building and maintaining OpenMRS technical products means clearly defining what we are building and how we are building it. Innovative work on microfrontends and OpenMRS Flow continues, new releases of the Ref App and Platform are coming soon, and as @ssmusoke puts so well, we know we have “unsexy but necessary” work to be done to reduce our technical debt. This is the time to define what is next for our technical products - for the short term and beyond. Having a clearer scope enables us to plan for, mobilize, and allocate scarce resources in such a way that complements implementation’s contributions.
As a community, we know that we work faster and go farther when small groups work together on a clear and specific scope. We also know that we are too large to rely on 2 or 3 people to provide our community with the technical guidance many would like.
With that in mind, and with thanks to the insightful questions and suggestions from @paul, @terry, @burke, @jdick, @janflowers, @dkayiwa, @wanyee, @gschmidt, @c.antwi, @akanter @lober, and others, we will set up two, small teams with decision making authority over 1) what we build and 2) how we build our technical products. Specifically:
The Product Change Committee will:
- Gather and provide the Product Change Lead with input on priorities from OpenMRS implementations and partners
- Set short, medium, and long term product goals
- Review, vet, and prioritize community technical projects
The Technical Committee will:
- Define overall technical and system architecture.
- Review and vet technical priorities and projects for technical feasibility and viability
- Maintain the technical roadmap
- Set community technical standards for code quality, contributions, and performance
As always, anyone in the community will be welcome to contribute to the discussions of either committee and we expect each to follow our community conventions around decision making. At the same time, we want to recognize the expertise of respected contributors from implementations and local communities - and intentionally involve them to determine what we build and how. Both committees will have up to 5 core members with decision making authority.
To ensure that these two teams work together effectively, a Product Change Lead and a Technical Lead will oversee and manage their respective committees - and will be accountable to the Project Lead. In addition to the Product Change Lead and the Technical Lead, OpenMRS QA Lead/Technical Product Managers will provide ongoing support to each committee. The full Terms of Reference for these committees and their leads is available here. The diagram below will give you an idea of how these two committees will fit into our software development process.
What’s next?
We’re going to try this out for the next three months and start with the following:
- Over the next two weeks, we’ll identify2-3 interim, core members for each committee and an interim Technical Lead. If you have ideas or recommendations, please feel free to share!
- Each committee will have an initial meeting to review their TOR, come to agreement on their scope for the next three months, and make some decisions about how they want to work.
- At OMRS19, we’ll take a look at how this model has worked, improve on it, and then recruit and confirm committee members for the 2020-2022 period.
As we put this conversation about governance of our technical products on hold during this interim period, we can move forward with the ideas laid out in What would an OpenMRS Fellowship Program look like? and consider different approaches to mobilizing resources.