January 26 2016

Attendance Information

1/26/2016

7AM PST - Seattle

10AM EST - New York, DC

5PM CEST - CEST, Geneva, Copenhagen, Joburg

6PM EAT - Dar

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

Meeting Number: 196 307 742

Host Key: 707674

Audio Connection: +1-415-655-0001

AGENDA

MINUTES

In attendance: Kevin Cussen, Lakshmi Balachndran, Brian Taliesin, Gaurav Bhattacharya, Renee Orser

Feedback on the Re-Architecture Plan

No one had read the document, so Kevin outlined the two major proposals: an incremental re-factoring vs. a complete re-write. 

Kevin described the initial VillageReach focus on doing an incremental re-write due to several factors including resourcing and budgeting constraints. Very limited ability to do a wholesale re-write of the code due to a limited number of developers on the project (2) and the long-time it would take these developers to finish a re-write. Based on feedback from the Gates Foundation, there may be additional funding to write an open RFP and augment the global dev team with additional resources which could speed up this process. Pending feedback on this before deciding on approach. Regardless, the 2.0 "stabilization" release will still happen, and this will be the initial starting point for new implementations. I'll keep the committee informed as we receive additional feedback.

Has there been any discussion on ideal timeframe?

Kevin Cussen (Deactivated): We did some very rough back-of-the-napkin estimates for doing a re-write in house that made us think this was not an option. This was one of the factors that pushed us towards an incremental re-architecture. Both are hard to estimate. For the re-factoring, it would depend heavily on the amount of support needed for "fast tracking" extension points for the community. Since we don't have an envelope or any proposals for the new architecture, we can't speculate on timeline except to say it would be faster than incremental. 

Brian Taliesin: What about the 3.0 migration path? How would that look for each of these options?

Kevin Cussen (Deactivated): Either way it will need to be a discussion with individual implementations on whether it makes sense for there situation to upgrade. A new version doesn't make your current version less functional simply by existing. If what you have is not meeting your needs, then the community would support the migration process as outlined here (under Additional Reading). There could be significant effort both ways and the implementer would need to secure some funding to perform the migration even with community support.

Do existing implementations need to remain static and then re-write to 3.0? What if there are new feature requests between now and future release?

Ashraf Islam (Unlicensed): The incremental approach appears to make more sense. For new countries coming in that want to implement now, they shouldn't have to wait. 

Kevin Cussen (Deactivated): Regardless, of which approach we take, there will be a starting place for new countries 2, 3, 4 months from now. The 2.0 "stabilization" release is happening no matter what, and that can be where these countries begin.

Code Contributions Standards Feedback

The majority of committee members did not read the document. Those that did had no strong feedback and felt that this was the domain of the technical committee.

In-person Meeting Proposal

Kevin Cussen (Deactivated): There have been times where I've felt like a bi-monthly 1-hour meeting was not enough time to hash out issues. I could see situations in the future where this would be the case as well. What are folks thoughts on a potential 1-2 day in-person if this happens in the future?

Ashraf Islam (Unlicensed): I can't commit, even if there were funding due to other projects that pose a conflict.

Renee Orser (Unlicensed): Curious to see if this may happen by accident somewhere in the world at some point in the next 6 mo. May require a sneaky approach to scheduling. Perhaps we can find a conference most of us will be attending anyhow that we may be able to do a day leading up to or following. It's easier to attend when there is more included as part of the travel. It would also be useful to review a list of conferences that we know are coming up as a product committee agenda item next time, so we can plan ahead.

Brian Taliesin: A day on either side of an established conference would be helpful. Conceptually not opposed, but budget could be a problem. Ideas for an agenda could include a general framework, a rubrick for scoring things similar to our initial prioritization of end-states. Prioritizing the backlog would be a good activity as well. 

Continuation of Re-Architecture Discussion

Brian Taliesin: What is the existing test harness? As we're making changes how do we know if something is broken?

Kevin Cussen (Deactivated): This is a very real concern. Much of the current OpenLMIS has poor to non-existant test coverage and as such it is very difficult to tell if your changes have broken behavior elsewhere. With the re-factoring there would be standards enforced starting now, but grandfathered code does not have to abide by these standard. One benefit to a re-write is that those standards could be enforced from the ground up. 

Brian Taliesin: Has there been any estimations done for the cost of migrating existing implementations VR has done? 

Kevin Cussen (Deactivated): No - as yet there's nothing to migrate to and no demand yet. We would work with these implementations down the line to see if a move is the right direction for them. 

Ashraf Islam (Unlicensed): We're beginning phase 2 in VIMS. What are the realities of phase 2. How would they migrate over?

Kevin Cussen (Deactivated): If you met the code coverage expectations in place for the new 2.0 master branch, you could continue to merge in changes which would make any future migrations easier. 

Ashraf Islam (Unlicensed): Test coverage is extra effort. Working with another timeline is extra effort too. Merging in changes are outside the scope of our work for Tanzania as well. There could be some back and forth. A bumpy road. Adjustments for impossible timeline. We have to deliver to IVD in June and what you're describing (test coverage, merges, etc.) is not part of our estimates for that date. 

Kevin Cussen (Deactivated): I think software is always a trade-off between time, quality, and budget. Articulating the importance of quality to your stakeholder is all you can do. 

RECORDING

ADDITIONAL READING