Attendance Information
07/26/2016
8:15AM PST - Seattle
11:15AM EST - New York, DC
5:15PM CEST - CEST, Geneva, Copenhagen, Joburg
6:15PM EAT - Dar
Meeting Number: 194 152 066
Host Key: 348190
Audio Connection: +1-415-655-0001
AGENDA
| 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 | |
| OpenLMIS rebranding | 5 minutes | ||
Risk Discussion: Draft list for review and input. | 15 minutes | Mary Jo Kochendorfer (Deactivated) All team members | |
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 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. 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. 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 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? 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. 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. My understand 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 presentation and 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. 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? Had a conversation on May 31 on high, medium, low. Work is already slotted for 3.1 and 3.2 release, these could be moved, subject to change based on this committee's ranking and decisions. Don't take the work on the roadmap as fixed, it is still a work in progress.
|
ACTION ITEMS
MINUTES
In attendance:
Tasks from last week -
- Outcome: Jake and Brian will continue to coordinate and discuss options of how to obtain support on GS1. Jake will update the group on the BMGF conversation around the conference and other parties (from conversations at GAVI) and Brian will follow up with his contacts at GS1 and others. Mary Jo Kochendorfer (Deactivated) to consolidate and update the open questions.
- Outcome: Mary Jo Kochendorfer (Deactivated) to update the PC next meeting on the roadmap development status.
- Outcome: PC members agreed the rebranding was good and to move forward. VR will move forward and update the group on the process and options.
NOTES:
RECORDING
ADDITIONAL READING: