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?