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

Leads: Leads from Each Governance Session

To Join Remotely: 

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

Optional dial-in number: 716-293-6106

PIN: 63498

Rapporteur/Notetaker: Sandy Hawley

Notes from Session: (See Dykki's SLides)

GOVERNANCE BODIES

1) Technical Committee- building the product the right way

• Architect:
  • If the person trained to comit the code agrees, there isn't an issue (architect) it goes in- no architect yet
  • if someone wanted to comit something to core not RM, PM would confer with TC to make joint call on whether or not to comit
  • Architect sits above? or is the committee the Board?
• If there are questions, it goes to the larger committee

2) Product Committee- building the right product

 - proposed participants: Ashraf, Kevin, CHAI, Rene

• desire to communicate around meet (call) every 2 weeks 
• one person at least from the field- or is it the committee members to collect and represent input? (no decision right now)
•  (JSI) Wendy in ZAM, Alpha in TZA- on the ground have ability to participate on governance bodies 
• Process- to follow TC process above, lead by Kevin
  • PM makes everyday decisions unless there is an appeal process  

3) Community Committee leads and supports community

• proposed participants: Lindabeth, Sarah, Carl, Mattias 

Other Teams-

1) Advocacy and Communications - branding, messaging, external comms

2) Implementations- support, knowledge sharing, training, requirements, user engagement

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

PRODUCT ARCHITECTURE

Core Product

• a) everyone needs (required)
• b) Some people need (optional)
  • multi-country requirements
  • define core standards
  • supported by community
  • highly tested/stable
  • we need to determine/decide:  what is part of master branch in GH, and what is considered core product ; existence of software in repository is a statement that is considered core
    • Tech Track decided that the Tech Comm.  is in charge of repository. There shouldn't be any code here that isn't core product. Shouldn't be code elsewhere that isn't core.

Contribution Marketplace (is this a nice way of saying "everything else?" NOT in repository)

• anyone can contribute
• focused on single country requirements
• could be elevated to core (curation)
• can be folded in as desired 
• scenario: I write custom code for one country
• is there is also a place where things beyond this live?

Tech Committee would evaluate based on: 

1) is it tech up to snuff

2) is in the vision of OpenLMIS  

DISCUSSION/ QUESTIONS:

• Going forward in a short time frame: Want to get to a place where there isn't any code in the repo  that isn't core product. Shouldn't be code elsewhere that isn't core
• there should be  space for non core that you want to share than your random GH 
• value in the marketplace- it could be helpful as reqs for core
• risk to be aware of is the "3rd" bucket" - should we create another GH repo? things that are not formally accepted, but greater visibility- a collection point for those things.
• if they have something to propose - and want to get input in - this 3rd bucket would hold that
• should be documentation and timeline run by TC to evaluate (NO)
  • if during implementation, core team needs to know during the process - before the point of evaluation
• If you working on implementation, you present those in a way that the TC can evaluate and see, make recommendations along the way 
• PM and TC structure doesn't have to be the same
• Contributions are limited by funding available to participants
  • orgs need to seek funding to participate if orgs can't absorb or sponsor
  • existing models promote leadership and contribution as value/currency; leverage country level funding in order to contribute to core in a way that has value for countries/lcients = more credibility and value to contributors (meritocracy)
  • committee can cometogether to raise funds and prioritize that as a need, and develop processes, action to do more - (consortium fundraising or otherwise)

DECISIONS/AGREED:

• Core committee members have responsibilities to make decisions, but anyone can call-in and participate/communicate in meetings
• Tech Comm.  is in charge of repository and makes decisions
• Tech Committee and Product Commitees are formed; governance and roles (Architect and PM) need further clarification

ACTION REQUIRED/Not resolved: 

• governance and roles of (Architect and PM) need further clarification
• is there a "3rd Bucket" for non core?
• We need to hear from Tech Comm. what is tech team planning, work on timeline - Modula Architecture is key priority

----------------------------------------------------------------------------------------------------------------------------------

SUSTAINABILITY

• PSE
  • Explored models/sectors might be interested in supporting/engaging
  • how can the system provide value ;i.e. TZA- if you provide transaction data to Pharma, maybe they would provide support because that information has value
  • Right now Gates is a sponsor - but we need to diversify
  • Other models - depend on priority
    • different orgs will sponsor (Fedora and Red Hat, Novel and OpenSues) - sell support services, hardened versions, things that are appealing to corporate, then that sponsor continues to support
    • doesn't this go against AGL model? You can't have an enterprise version 
    • don't want "openlmis.com"
    • for others without corporate- collecting donations, fundraising
    • SaaS
  • We don't  have any implementations that are currently sustainable. How can we become more sustainable: want to push as much capacity into countries as possible
    • Country governance role is key
    • System Admin
    • Tier 1 - basic- potential regional/country
    • Tier 2- advanced - potential regional/country
    • Tier 3 needs to be maintained by global (haven't figured this out yet) 
    • Regional Orgs: Eastern Central Southern Africa Health Community and West African Health ORg (iHRIS case study-- single most important factor in dissemination)

-------------------------------------------------------------------------------------------------------------------------------- 

IMPLEMENTATION SCENARIOS (See Sarah's SLide)

Decision (implementer funder/community

• realites on ground - donor, partner, countries have different priorities- trade offs are required
• what can we do- toolkit for implementers

More Models for Successful Core Dev. 

1) implementer brings someone in in as an advisor, how code is reusable

2) sub contract from the community to work once its ready, then pull it in

Artifacts: