...
| Item | Time | Presenter | Notes |
|---|---|---|---|
GS1 Update (Josh went to a training). VR's working open questions, here. | 1 minute | Mary Jo Kochendorfer (Deactivated) Josh attended training last week, we're summarizing and understanding the impact for OpenLMIS. We have a list of open questions. Josh and Mary Jo will be meeting with Brian's contacts at GS1 to understand what OpenLMIS can do/how to comply to GS1 standards. Conversation is underway and we're getting our questions addressed. Can follow up with MJ or Josh with any comments or feedback. Jake Watson (Deactivated) Was in Geneva last week for Gavi INFUSE. A UPS rep was there who was seconded to Gavi, offered to make other connections. Best bet is to wait until Chemonics hires their GS1 consultant/expert. | |
Question: data dictionary? and data standards?
| 9 minutes | Danni Yu (Unlicensed) & team | Danni Yu (Unlicensed) Examples from checklist? Standards that other systems are using that you want to see reflected.
As implementers, we did an assessment in our team, but as a product, will it go through its own security assessment? Brian Taliesin Kyle Duarte Jake Watson (Deactivated) |
| OpenLMIS rebranding | 5 minutes | OpenLMIS logo undergoing rebranding. Will introduce 3-5 shortlisted logos likely next week. | |
Risk Discussion: Draft list for review and input. | 15 minutes | Mary Jo Kochendorfer (Deactivated) All team members | Introduced but tabled for next week. Pulled together risk matrix internally - wanted to give the product committee the opportunity to raise additional risks and develop mitigation plans. We understand there are risks involved with a new deployment before the new release is ready. Are tracking these, and can discuss these further next week if there is interest. Can put them up and internally monitor them over time. Kevin Cussen (Deactivated) Lakshmi Balachandran Mary Jo Kochendorfer (Deactivated) |
Discussion on Prioritizing the Roadmap
Product Roadmap (WIP)
| 30 minutes | How can Product committee prioritize features and work for the roadmap? Darius Jazayeri (Unlicensed) Comments on OpenMRS product prioritization 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. Kyle Duarte 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? Kyle Duarte 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? Kyle Duarte 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)
|
...