Technical Committee Sessions Read-Outs/Group Discussion (Plenary)

Owned by Kevin Cussen (Deactivated)
Last updated: Sept 30, 2015 by Sarah Jackson (Deactivated)

Description: Informal summary of key outcomes from each session, with time for Q&A from the larger group

Leads: Leads from Each Technical Session

To Join Remotely: 

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

Optional dial-in number: 716-293-6106

PIN: 63498

Rapporteur/Notetaker: Sarah

Notes from Session:

Where is the code at right now? What should the next implementation do?

  • Next implementation needs a stable code base to start from
  • Current "2.0" code base is really more of a development branch: not release tag
  • Need to: clean up code, remove some code, etc. – a whole set of short-term activities that are targeted for completion by the end of 2015 


Architecture

 

Architecture Proposal

    • TW proposed domain-driven architecture approach, based on micro services
    • There were differing opinion on the best solution. TW agreed to explore additional ideas - different commercial or open-source+commercial models, i.e. OpenERP with an add-on structure 
    • Would it be possible to incrementally move the code base over to this new architecture? likely no
    • It would be quicker to rebuild the product from scratch rather than re-factor. Either way need to consider upgrade path. 

Proof-of-Concept Proposal

    • TW proposed taking one module and do a POC using the domain-driven architecture approach
    • Would help provide an estimate of how much time the rest of the work will take

Comments from larger group

    • What problems are we trying to solve: lack of extensibility; ease of development; accessibility for new developers to come inHow will we measure success?
      • Defining measures of success - product committee
      • Technical committee raising andy trade-offs or options to the product committee 
    • Why are we having to pay for this again? Why didn't the initial implementation take this into account?

 

      • This is common within enterprise applications - typically rewritten (often from scratch) 2 or 3 times before you get there
      • Built as an application, mostly customized via the UI (this was understood to be the use case)
      • Learned as community that the initial architecture didn't work in practice 
      • Example: Cote D'Ivore
    • What about existing implementations?

 

      • If the community says it is community supported, it's hypocritical to not support previous deployments
      • No defined upgrade path (yet). POC could help understand this better.
      • Will the new approach be the right approach? How do we know? What if we screw this up again?
      • Lots of concerns about existing implementations and implementation currently in process: Tanzania, Zambia, Cote D'Ivore, Mozambique, 
    • How big is the delta to the new version?

Re-Architecture Planning Considerations

    • How much would it cost to change existing implementations to this version? Who is funding this?
    • How much time and money will it take to build the new version?
    • Need visibility into key decision points

Technical Working Group Definition (link to page)

Who: Elias (JSI), Jeff (TW), Josh (VR)

Characteristics of Membership: Actively engaged in the work going forward

Duties & Privileges: 

  • Arbitrate technical disputes
  • Have the final say in major arch. decisions
  • Tech review for new projects
  • Owns github.org
  • Defines coding standards and contribution process
  • Regular review of architecture for roadmap and tech debt
  • Tool selection
  • Account for community input
  • Accountable to the community 
  • Meets bi-weekly
  • Review membership and approves new ones in collaboration with community leadership group


Timeline

Q4 2015: Shared upstream branch; Shared Infrastructure for Devs; Tech Committee Calls; Code Clean-Up; Coding Standards v1; Tech Committee Meeting; Research Spike

Q1 2016: Start enforcing v1 standards; Contribution Guide v1; Evolved code standards; Some code clean-up; Shared demo and demo db; Automate required new standards; Decide on re-architecture path; Shared issue tracker; Public community/implementation forum

Q3: New implementations can write to extensions (what does this mean from a business perspective?)


What do we want 1 year from now

link to page

 

Key Open Questions

  • How would upgrades to new version be funded?
  • Need to know how long the re-architecture would take, and how much it would cost.
  • What is the sustainability plan for countries on the current version? For example OpenMRS supports the last 3 versions. 
  • Should additional implementation start? probably yes – needs to be transparent.

Action Items

  • Technical committee to raise trade-offs and present alternatives to product team - product team to verify and analyze how alternatives meet business goals
  • Product and Technical committees to work together to define how we will measure success
  •  Is it possible to set-up linked issues between different Jira's?


 

 

 

 

 

 

OpenLMIS: the global initiative for powerful LMIS software