How can Product committee prioritize features and work for the roadmap?
What works for us in prioritizing our roadmap for OpenLMIS?
Darius Jazayeri (Unlicensed) Comments on OpenMRS product prioritization
There's always a tension in any open source project between the strategic roadmap as the project, and the fact that the project is made up of contributors and collaborators. Most partners aren't under the control of the partner itself - they need to do their work for their individual projects. You'll always have this tension in the open source community.
The code that gets written ends up being the roadmap that gets written. Those who bring contributions to the table are the ones who help direct the roadmap. Important, however, to have the roadmap written out so that when a contributor comes to the table and wants to contribute X,Y, or Z feature, they can be compared.
Very hard to truly understand what everyone wants to happen. OpenMRS has often tried to lean toward figuring out the product strategic roadmap, what the majority of implementations are wanting. How do they channel the shared voice? They haven't been incredibly successful at that - have tried many ways. Annual meetings - dedicate a session, tried in conference calls, posts to the website, etc. Tried the approach where people are voting on tickets in the issue tracker. Tried having a roadmap committee that actually analyzes those inputs (votes) against what people have said in posts or meetings through a committee that tries to synthesize that into a roadmap. What happens today at OpenMRS' roadmap is much more tactical. The main reason OpenMRS wasn't extremely successful: If you're trying to synthesize that view of the broader community and project, you need a path to actually implement those things, otherwise it's a waste of time. That's what OpenMRS didn't do extremely well. Understood what people wanted, but when it came down to it, it was difficult to act upon and people felt it was a waste of time.
What OpenMRS does today is more tactical and driven by a small number of things get prioritized because it's been identified by the community as important, or a key short-term priority. Nudging people to pick that up. But what also gets picked up is what contributing organizations choose to pick up or implement on their own.
Mary Jo Kochendorfer (Deactivated)OpenMRS faces the challenge that they don't have a path to implementation. OpenLMIS is in a different situation - we have resources to execute on a path to implementation and we need to make sure we understand and define the roadmap, and that what we're including reflects what people need in an implementation to do that.
Darius Jazayeri (Unlicensed)The problem OpenMRS had is that there were many people who had legitimate desires for what they wanted to happen in the product, but it takes developer time to make that happen and they weren't bringing that developer time.
OpenLMIS situation is different: People aren't coming to the table with purely ideas but no investment, they are coming with potential resources.
Jake Watson (Deactivated)Current roadmap was put together during the design workshop, what is the MVP we need to get out followed by the features and descending priority sequence. Informed push was out because it was only one country.
Now that we have Malawi starting soon, it's very possible that the roadmap is going to have some of those priorities shifted - because they are the first real client for 3.x. In this case, the larger question: How do we engage with you to ground-truth those priorities, how do we set up a feedback mechanism, create JIRA tickets? What is the best way to get your feedback on priorities in the roadmap? Especially with the potential tension of having two countries doing an implementation at once, how do we handle tensions that arise between those competing priorities? Open question.
Reflect on what Jake is saying and also touches on what Darius was talking about. The tension in prioritization is backed by funding and if there is divergence in those requests. Either a mandate is set for the core code, we won't be doing A, B, or C because it takes away from the common core. If countries do have the ability to fund that, how is that prioritized, and will that contribute to the common core? Right now, if Malawi is part of one or two countries implementing, it's far easier than 3-4. If there is a request that is backed by funding that is divergent from the common core, we need to find an answer to that. Do we have a response to those kinds of requests?
Jake Watson (Deactivated)
Obviously features that have funding will have priority to get developed. We've already committed to some features in the roadmap, Malawi may want to push some up in priority, that may not be a big issue for some, but if/when another country comes along and wants to prioritize other features, how are we internally as the Product or Governance committee going to vote on this?
Requests are going to a common development team that prioritizes? I was looking at this as more than one set of developer resources are available, and how to harmonize and synchronize those efforts.
Darius Jazayeri (Unlicensed)
The OpenMRS experience is like you are suggesting Kyle. You have a core roadmap, but if someone comes in with their own developers and wants to fund their own features, and they're still generally in scope of what OpenLMIS wants to be, you should allow a team to come in and implement that. At the same time, you do know what you want and the priorities, and whenever possible, leverage those resources toward common, shared priorities. Don't want to turn away people with the ability to do funded development. Neither want to turn it away or completely absorb - find a halfway position.
Kevin Cussen (Deactivated)
My understanding is that the architecture should take a lot of the pressure off of this. The roadmap develops core services. If a particular implementation needs to use an existing service and customize some of its behavior, they can use extension points to do so. If a new service needs to be created, that can be created in-line with the needs of a generic implementation and along the lines of what was needed for the core roadmap.
Two different funding streams: Core VR team that is working on the "common good" overarching services, then implementation teams that are doing customization services for their particular context.
Mary Jo Kochendorfer (Deactivated)
Important conversation to have. As new implementers come up, need to be sure that we monitor what they're doing, and as Kevin outline, the architecture will facilitate this. To focus the conversation though: Specific short-term need. During the re-architecture, we need to prioritize certain features/functionality. This was done in the design workshop, we wanted to bring this back up to the committee, look at the product roadmap. How does this committee want to weigh in or monitor the shifting of priorities. If we decide to shift certain functionality for their needs, how do we bring this up to the committee. Prioritizing current roadmap, then tension around moving forward as more contributors join the community, working in parallel. What will work for us, looking at OpenMRS' experience?
Another example: Other translations, right now work is in English. This was not a simple text translation, but needed a table to store a different translation. Thinking about the database, and what is the decision-making process on things that impact us at a database level.
Jake Watson (Deactivated)
The re-architecture should address these issues, there shouldn't be any cross-service database calls, all should be addressed by APIs. The general approach is what Gates has funded: continuation of the core team, to help review the requirements and requests and offer guidance in how these implementations would be done. Doesn't mean we would do them, but could say, this is the approach behind the architecture. The key aspect of the architecture is that it's modular and extensible.
Kevin Cussen (Deactivated)
The architecture should decide the conversation. My approach is: describe to the product committee at a high level what the feature looks like, based on is that feature simply an extension point, or is it a new service? Part of core? Decide how this needs to be approached. Core service - needs a lot of touch from the product committee. Extension point - Create and implement it however you want. Middle ground - use the architecture to guide this. This is the feature that I'm designing - 1 sentence or 1 paragraph description - review with committee.
Mary Jo Kochendorfer (Deactivated)
- Next steps: Re-circulate the work that Kevin and product committee did. Good diagram that can be circulated and move forward with that approach.