...
Rapporteur/Notetaker: Sandy Hawley
Notes from Session:
COMMUNITY COUNCIL RESPONSIBILITIES- DELEGATED GOV (We agree)
- 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 drive the community that is flex 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 distinguish core vs universe; with "optional" capability (PRODUCT vs TECH!)
- "community supported" and modules have specific meaning and mean different thing to different people
- We have to have an architecture and supports distinguish core vs universe; with "optional" capability (PRODUCT vs TECH!)
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?)