Governance Committee: 2016 Plan (GOV)

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

Leads: Dykki

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:

COMMUNITY COUNCIL RESPONSIBILITIES- DELEGATED GOV (We agree)

• We have to be specific about responsibilities, structure, membership, communication - need to articulate the responsibilities of the governing bodies

  • Community Council, Governance "team" - (teams are not governing bodies, they collaborate, but don't have authority on direction)

  • Technical Committee (decided) 3 members 1 CHAI, TW, VR- decision making power over tech contributions; propose committee select direction moving forward

    • people felt like they could commit the time, CHAI on hold, PATH should make a case to join if they have interest or time (time wasn't an issue for those partners) 
      
      
      

• Community Council and Tech Committee have equal authority - collaborate on key decisions; sample responsibilities:

  • membership prop

  • conflict resolution

    • OpenLMIS needs an EMR (clients demand it) - this group would make that decision 

  • Values and product principals, stewarding that and revising

  • Processes (onboarding)

  • Ordaining gov bodies

  • Direction

    • Community

    • Product (this seems the most challenging)

  • Format:

    • Annual Meeting + one off sessions

    • Product Dev- how do we drive the community that is flexible  but not schizophrenic

    • We don't want to move forward with good process

    • HOW does stuff get on the roadmap

• We heard

  • move quickly

  • not have a lot of process
    
    
    

• Role of Product Manager - right product (we don't have this roll filled right now- so Governance board is driving that)

• Product Architect- build right way

• Collaborate on Roadmap- but eventually define Product Manager role and evolve

• Do people want to be on the PM Committee OR this is something that the Community Council decides?

• Do we empower one person (PM) to be the leader or committee has ability to hire the position? Committee has oversight on the person 
  
  
  

• TECH COMM (proposed : Josh, Elias, Jeff)- build the product the right way

  • every other week 2x month 
    
    
    

• PRODUCT COMM (Proposed: Kevin, Rene, Chai (TBD) - build the right product- seek advice and direction from gov. group and others via Annual Mtg)

  • manages risk of partner development outside scope; we need technical resources 
    
    
    

• GOV COMM: (Enabling Comm)

  • we need people to drive/lead community beyond Comm. Manager, resolve higher level issues, funding

  • advantages of formalization - avoid risk of alienating people when there is no structure

  • unusual for a group not to have a formal group

  • "grab bag"

  • funding and advocacy- somebody needs to do this, manage this (not urgent, but needs to happen, PM and TC shouldn't be their priority)- if you don't assign someone, it won't happen

    • if effort of community to allocate resources should be highly focused on PM and TC, GOV enables/supports those roles 

  • community processes (values, principal maintenance,

  • communication- emails

  • MONTHLY conversation (record)

  • Monthly emails

  • power to help with conflict management- review, provide comments (if things required a vote committee members vote when you can't reach consensus)

  • Annual Meeting give opportunity for input from community- PM and TC execute

• We need consensus on priorities of roadmap-PM needs to be empowered to make decisions, unless overruled or there isn't consensus within PM Committee

CORE vs. COMMUNITY MODULES 

• Community-Supported vs. "other"

• It is not as simple as "it's part of it, or not part of product (Core v/s Universe)

• 1) Core Product +

• 2) Opt-In  Modules are either Community Supported OR Custom

• If you're implementing "quick and dirty"  it's not important to community short term- OR I'm going to spend more, take more time so that other people can use this as a community supported plug-in because community may want to use it (bar-coding)

  • if country can't support it,

  • OR spend more money to make it more useful

• if bar-coding is not on the community roadmap, but there is funding to do it, could meet the code standards but it's not on the roadmap - there is a place for such things

• How do we incentivize partners to contribute back- defining the distinction is key- it will guide implementers  ability to contribute (or not because of time and $ constraints)

  • We have to have an architecture and supports to distinguish core vs universe; with  "optional" capability (PRODUCT vs TECH!)

    • "community supported" and modules have specific meaning and mean different thing to different people

WHAT WE DIDN'T GET TO  (try for later today or post-meeting

• 2016 plan commitments

• issue tracker

• teams and team members

• what will get done in the next 12 months- Roadmap

• communication processes - way to have more visibility and collaboration on implementations- past, present, issues etc

  • best way to share OpenLMIS opps w/ community 

• country engagement strategies

• building capacity of OpenLMIS

• next meeting around a common agenda (GHSC?)