Page Comparison

...

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?)