Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Current »

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 roole 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 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 advoacay- somebody needs to do this, manage this (not urgent, but needs to happen, PM and TC shouldn't be their prirority)- 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 pririties of roadmap-PM needs to be empowered to make decisions, unless overruled or there isn't consensus within PM Comittee

CORE vs. COMMUNITY MODULES 

  • Community-Supported vs. "other"
  • Isn't as simple as "it's part of it, or not part of product (Core v/s Universe)
  • 1) Core Product with vs
  • 2) Opt-In  Modules are either Community Supported OR Custom
  • If you're implementing "quick and dirty" I think it's not important to community short term- OR I'm going to spend more, take more tiem so that other people can use this a community supported plug-in because community may want to use it (barcoding)
    • if country can't support it,
    • OR spend more money to make it more useful
  • if barcoding is not on the community roadmap, but there is funding to do it, could meet the code standards but its 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 on 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?)

 

 

  • No labels

OpenLMIS: the global initiative for powerful LMIS software