July 26th 2016

GS1 Update (Josh went to a training). VR's working open questions, here.

1 minute

@Mary Jo Kochendorfer (Deactivated)

Question: data dictionary? and data standards?

9 minutes

@Danni Yu (Unlicensed) & team

OpenLMIS rebranding

5 minutes

@Tenly Snow (Deactivated)

Risk Discussion: Draft list for review and input.

15 minutes

@Mary Jo Kochendorfer (Deactivated)

All team members

Discussion on Prioritizing the Roadmap

• OpenMRS post for context on different approaches

• High/Med/Low (per earlier PC conversation on May 31st)

Product Roadmap (WIP)

• ProductPlan software and way forward

30 minutes

@Mary Jo Kochendorfer (Deactivated)

GS1 Update (Josh went to a training). VR's working open questions, here.

1 minute

@Mary Jo Kochendorfer (Deactivated)

@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)
We had proposed that either Gates or USAID convene a public/private working group to bring in DHL or UPS to share knowledge on GS1 and system design. Gates has signaled that, even if they have a working group later in October, it won't touch on system design.

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)
Background: Got a technical checklist from MOH in Mozambique. They're reviewing the app. To evaluate it, they need us to answer questions related to data models. Some are related to questions like, do we use a data dictionary, etc. Quick answers are no. Other question: Moving forward to migration to 3.0, will those things be available, and how are we ensuring the robustness of the app to stakeholders?

Examples from checklist? Standards that other systems are using that you want to see reflected.

• Standard that OpenMRS uses - do we have the same? We don't

• Security: Password verification, encryption

As implementers, we did an assessment in our team, but as a product, will it go through its own security assessment?

@Brian Taliesin
Get the actual standards names - too many to choose from. Difficult to know exactly what OpenMRS does, or what government is looking at.

Kyle Duarte
Documentation: Most countries get USAID funding, and documentation required for approvals takes time. Need to keep the documentation track up to date too.

@Jake Watson (Deactivated)
Could have a spike. Danni come up with specific standards. Looking at introducing GS1 standards. Apart from that there are security standards. If you have specific requests, create a ticket or send us an email and we'll create the ticket.
OpenMRS standards - some don't apply to the type of data we're gathering. Will add standards to the openlmis.org website. We'll want to publish something along with the GS1 stuff anyways.

OpenLMIS rebranding

5 minutes

@Tenly Snow (Deactivated)

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)
Might be useful to define who the audience is experiencing that risk since these are directed at different audiences.

@Lakshmi Balachandran
Review offline and bring them up to discuss next week. Haven't had a chance to review it, we don't need to go through each one, but could discuss prioritized risks.

@Mary Jo Kochendorfer (Deactivated)
Review this and identify which ones they would like to discuss next week. Will prioritize and discuss those that seem important for the group, and will bring it up on an as-needed basis.

Discussion on Prioritizing the Roadmap

• OpenMRS post for context on different approaches

• High/Med/Low (per earlier PC conversation on May 31st)

Product Roadmap (WIP)

• ProductPlan software and way forward

30 minutes

@Mary Jo Kochendorfer (Deactivated)

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.

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.

@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)