Attendance Information

5/3/2016

8AM PST - Seattle

11AM EST - New York, DC

5PM CEST - CEST, Geneva, Copenhagen, Joburg

6PM EAT - Dar

Link: https://meetings.webex.com/collabs/#/meetings/detail?uuid=M299H1X42RL8F1ABXL3LOKN9TN-3O29&rnd=750730.25263

Meeting Number: 192 173 465

Host Key: 352864

Audio Connection: +1-415-655-0001

AGENDA

Item	Time	Presenter
Next steps on maturing our process for vetting project proposals (see memo & graphic) Soliciting project proposals from non-product committee members Responsibilities / Expectations of product committee members Cross-country functionality (based on current knowledge or researched - what does "due diligence" look like in this context?) How are decisions made? On-going involvement with projects What do check-ins look like? Implementation team augmentation? Verification of global accessibility The product committee recognizes that a clear process for vetting project proposals needs to be defined. To this end, we have recently introduced a process to review new project proposals for global requirements, to investigate cross-country demand for features, and to inform what features belong in the core OpenLMIS product. Consider a 1-2 day in-person to make bylaws concrete if possible	40 minutes	Kevin Cussen (Deactivated)
OpenLMIS Re-architecture acceleration proposal	5 minutes	Kevin Cussen (Deactivated)
2.x vs. 3.x Country Recommendations (see memo)	10 minutes	Kevin Cussen (Deactivated)
Round-table on prospective projects	5 minutes	Kevin Cussen (Deactivated)

ACTION ITEMS

Item	Owner	Deadline
Discuss approaches to disseminating product committee process to wider community with Tenly Snow (Deactivated), specifically including country outreach committee.	Kevin Cussen (Deactivated)	06 May 2016
Draft memo on "bylaws" discussed today to get feedback from Product Committee	Kevin Cussen (Deactivated)	17 May 2016

MINUTES

In attendance: Kevin Cussen (Deactivated), Lakshmi Balachandran (first 30 minutes), Mattias Wiklund (Unlicensed), Jake Watson (Deactivated) (first 40 minutes), Danni Yu (Unlicensed), Chris George (Unlicensed)

(Began a few minutes late do to call-in issues)

OpenLMIS Re-Architectural Acceleration Proposal

Kevin Cussen (Deactivated): Gave overview of agenda, asked Jake Watson (Deactivated) to discuss the re-architecture proposal.

Jake Watson (Deactivated): We believe we'll be able to release one release this fall with a stable release by February. Sent a draft proposal to BMGF yesterday including options for a 3.1 and 3.2 release with some of the big features that would be present in an ERP (ie stock management). Can send out copies of that for those interested. CHAI and TW contributed to this with their mobile front end. Attached JSIs name to a vaccine functionality menu item. To recap: 3.0 by end of January 2017. Per the design workshop this is the minimum viable product for a release.

Lakshmi Balachandran: When will work start?

Jake Watson (Deactivated): Already started. Development work will begin in earnest May 30th. We'll be working with SolDevelo initially and may bring other teams on later. Will be in Poland the week of May 16th to do project kick-off with them.

2.x vs. 3.x Country Recommendation

Kevin Cussen (Deactivated): Described the 2.x vs. 3.x release memo, specifically pointing out this table (below) on page 3:

Target Deployment Date	Level of Customization Needed	Recommendation
2016	Low	Deploy on OpenLMIS 2.0 in 2016 Supported upgrade to 3.0 in 2017
2016	High	Work with OpenLMIS global team to conduct requirements analysis in 2016 to inform 3.0 development Deploy on 3.0 in 2017
2017	Low	Deploy on OpenLMIS 3.0 in 2017
2017	High	Work with OpenLMIS global team to conduct requirements analysis in 2016 to inform 3.0 development Begin software development on new modules, in coordination with re-architecture project Deploy on 3.0 in 2017

Encouraged all members to read the memo if they haven't yet.

Chris George (Unlicensed): What is the situation where you stay on 2.0?

Kevin Cussen (Deactivated): Where they want to release very soon and don't have many code changes. This way, they can take advantage of the migration path to 3.0.

Chris George (Unlicensed): Our work in Mozambique right now uses a very small slice of OpenLMIS but there is interest in using OpenLMIS for many other parts of the supply chain in Mozambique.

Discussions on Product Committee Process

Kevin Cussen (Deactivated): Gave introduction to this discussion. Desire for more rigor is to give donors more confidence that the presence of the product committee will result in more globally applicable software being created. In order to promote this confidence, we need a rigorous and well known process that vendors, implementers, partners, and donors are aware of and trust. To that end - how do we make implementers aware of this process? How do we solicit project proposals from non-product committee members? Collateral we hand out? Post on the wiki? Other means?

Chris George (Unlicensed): Wasn't there a country engagement committee? This could be an avenue towards this.

Kevin Cussen (Deactivated): Yes, will discuss with Tenly Snow (Deactivated) on the best way to involve this group. Other comments?

Kevin Cussen (Deactivated): Second item, what are the expectations for product committee members to vet new proposed features as "global"? What does due diligence look like for a product committee member? Should items be approved on the spot or should there be some time between proposals and votes to give members an opportunity to research the items?

Chris George (Unlicensed): This is a tough question. I haven't been on, but what comes to my mind is why would someone want to reject a feature as non-global?

Lakshmi Balachandran: What is at stake with this decision? If we put it in the global reqs but it's not global what is the outcome? Additional effort for the developers, no?

Kevin Cussen (Deactivated): Additional work, yes. But also what if we're wrong? What if something we thought was global is not and we haven't had time to research to confirm this fact? We then have a feature in core that shouldn't be there and a country that depends on its' presence.

Lakshmi Balachandran: Perhaps we need some sort of requirements process across multiple countries? If we decide a feature is part of the global feature set. Maybe there is a second process to make that global feature generic.

Kevin Cussen (Deactivated): So, you're saying the first step is higher level and the second would be more of the nitty gritty of getting into the business process and researching the need across multiple geographies?

Jake Watson (Deactivated): The new architecture will promote the ability to re-use ad extend features. Hopefully these conversations in the future will be easier to have. Having a unified backlog in JIRA for all partners will be extremely useful as well.

Kevin Cussen (Deactivated): Is it appropriate to decide this sort of thing on the spot? Perhaps committee members hear the proposal and then have 2 weeks to vote via email?

Chris George (Unlicensed): Would that vote be publicly visible?

Kevin Cussen (Deactivated): If we voted via the google group, yes. Only committee members can vote but all others can view.

Chris George (Unlicensed): Is there a danger of no follow-up? Why not vote on the call and then cycle back during the following week if need be?

Kevin Cussen (Deactivated): Or similarly, why not have proposals one week and then vote on the next meeting? That makes it so that those that would like time to research can.

Kevin Cussen (Deactivated): I'll draft up some language and send out in the next few weeks, we can ratify next time... which segues to our next topic nicely - how should voting occur? Consensus? Majority?

Mattias Wiklund (Unlicensed): I believe consensus is important from a community stance.

Kevin Cussen (Deactivated): Understood - will discuss next week further when we have more of the regular members. Next item - how involved does the product committee stay with development shops as they build global code? Specifically, once the committee has signed off that we want a feature in the core product - how and how often do we touch base with that developer going forward? Do we as a committee or is an individual tasked with this? Given that we all have other jobs, what is realistic and productive for us and them?

Chris George (Unlicensed): It will be difficult to compete with the end user in this regard. They will have a louder voice than any number of check-ins. Need to re-iterate with the dev shop that there is a trade-off on working with a open source community.

Kevin Cussen (Deactivated): Agreed, and I think this has been our narrative but it has to be more than just there are trade-offs. We need to provide incentives for these partners to honor the contract as well. What resources can the community offer to a dev shop to make them invested in the process? Could have devs physically co-locate with the implementing team for some amount of time? Have them join remotely for some %? Something else? I will draft up some ideas and send them out.

Chris George (Unlicensed): Has this happened in the past?

Kevin Cussen (Deactivated): VillageReach has placed developers with in country teams before during project ramp up with mixed success. Lastly, what does the final check-off look like? It should obviously include the tech committee but product committee needs to be involved since we are the party approving the initial global requirements. Any approaches?

RECORDING

ADDITIONAL READING