Description: Summarize what we seek to accomplish in 2016, activities/owners, and any working agreements needed to facilitate those goals v

Leads: Darius

To Join Remotely: 

Join the call: https://www.uberconference.com/openlmis_technical

Optional dial-in number: 857-216-2500

PIN: 36416

Rapporteur/Notetaker:  Rich

Notes from Session:

Recording:  2016 plans.mp3

Next Steps, 2016 activities

Exercise:  "Fast forward a year, what do you hope has happened?"

Ashraf:  a site that shows OpenLMIS as a production release (similar to DHIS), details the features that OpenLMIS offers, brochure and other doc is available.  Materials like install/config guides are available, and a demo site for folks to investigate the application.

Developers have easy access to documented ("published") APIs, dev environment setup, coding standards and Dev Guide and infrastructure (how to contribute, good practices, etc.).   Dev onboarding process is defined and easy to find.

Doc specific to implementers is available.

Tech Committee exists and functions.

Jeff:  Collaboration environment for implementers, a place for discussion and advice

Published road map.

Architecture:  OpenLMIS has an extensible architecture.

Shared infrastructure for issue tracking, etc.  

Ashraf described a sort of internship program to build capacity and skill for in-country staff.  Donors could fund this.

Support forums for devs, implementers.  (DL/listervs, etc.)

Some of the above is an ask for governance to own/help

Targets/Milestones

Q4 2015:

• Master/upstream branch established
• Shared infastructure for devs (CI, sonar, etc.).  Ideally the Sonar results are published
• Code standards v1 (first steps to get it going)
• Start Architecture spike

Q1 2016:

• Code standards evolved (ongoing discussions anticipated)
• New standards enforced (via automated checks)
• Contribution Guide v1
• Architecture spike completed, reviewed, and decisions made.
• Shared demo environment (implies demo DB)
• Public community support forum (simply a public DL.  No service level committed to)

Q2 2016:

• Published technical documentation begins

Q3 2016:

• Extensible architecture ready - new implementations can write extensions, and have a path to contribute back to core

Coding standards:  once established, what do we do with the existing code?

• First, don't  make code worse (new code must adhere to standards)
• Legacy code is refactored opportunistically, typically if a developer is updating exist code/files.