-
Notifications
You must be signed in to change notification settings - Fork 110
Community Based Surveillance Community Sprint
January 18 - 19, 2019 Oslo Norway
The CBS Community is one year old. The following is a co-created community analysis to support the next steps. The methodology follows open principles and community management best practices. Edits welcome.
- Open Community resources
- open organization principles
- community maturity model
- network-centric resources).
There are three main groups in this community:
- Software community (remote/codeathons)
- Norwegian Red Cross, business partners, technology companies, IFRC, and other National Societies
- Local Community Volunteers
There are two main parts of the cycle - the software and the community volunteers in local branches/ National Societies. The software teams are organized into 5 teams: alerts, notification gateway, reporting, analytics and administration. They have 34 different channels on slack for the sub-parts.
Some of these roles exist. Some are needed. This list needs definitions and roles. As well, descriptions on how to get involved.
- Core Team
- software developers
- advocates
- front-end/backend
- ux/ui
- humanitarian
- technology lead
- logistics/event organizer
- issue maintainer
- open source process engineer
- volunteers
- tech leads
- code reviewers
- hardware
- data viz
- health professional
- facilitators
- communications/storytellers
- humanitarians
- program lead
We discussed the open principles: transparency, inclusivity, adaptability, collaboration, and community. Participants provided the following feedback about their community norms and values:
- facilitators /experts in the teams
- "life savers"
- learners
- Friendly, social
- 138 slack, 109 github
- participatory spirit
- CBS system believers
- adapative, unorthodox solution providers
- mixup groups, onboarding
- positive, useful, feel engaged
- care giving/checkins
- engaged
- eager
- community management/support
- wants to know why people leave/go and not return
- people know they can ask questions
- respectful
- inclusive
- curious
- people can see the progress
- inside jokes (ducks) make us connected
- consistent communication
- organized (?)
- transparent
- team bonding/self-selected
- self-organized
- documented roles
- saving lives
- network
- new technology
- local communities need solid solutions
- need IFRC and National Societies to be responsive
- need to be clear on what to do
- ownership of project needs to be "open"
- independent from IFRC/National Societies
- everyone does everything
- decision-making flow
- information flows from NorCross - what is going on?
- Traditional organization moves slow
- structure may need to adapt
- branded as Red Cross - needs to be more "Open"
- active checkins needed (on an individual level)
- software onramp is not easy - 6 different pieces of software
- structure may need to adapt
- who's community?
- pilots are moving faster than the software
- improve on these values and norms
- duplicate processes in various sections of software
- leave without documentation or code committed
- tech partnerships have to be managed via Red Cross hierarchy
- "open" is not enough, add growth and others
- too much hierarchy to invite partners
- needs to assess time needed on tickets
- wants more notice for events, schedule 3 months ahead
- convert - tasks to open source methodology
- sustainable $
- pilots don't scale
- project management
- missing skillsets
- people not returning
- cost of mobile services
- undervalued/underused
- "leader" driven
- time between codeathons - losing momentum
- need own github, not IFRC
- no pathway to being truly "open"
- codes needs to be refactor
- onboarding is hard, takes too long to learn how to help
- switching code bases
These items need to be prioritized and divided into projects/tasks (small, medium and large). As well, the community needs to decide who does what.
- weekly notes/updates
- ask for more help
- tasks/issues to build out the community
- ambassadors to support in between times (codeathons)
- need process for delegation of work
- open up dialogue with humanitarians and partners (business) to open up this work (build faster, more useful)
- engage people in small tasks more
- someone to go to OSCON Europe and/or Mozfest to learn about open community management
- we wrote a draft governance document
- roles are documented/roles and responsibilities need to be better written/there are developer role gaps
- there is a 3 year project plan
- outreach to larger open source and technology communities plan and networking
- community management training for core team
- need code review process
- always be charging - your community needs updates and engagement strategies that they can support and own
- decide how to grow
- communications plan - slack, github, newsletter, social media etc
- write out history - tell the full story while you go
- ask for in between event help - clear asks, small tasks to medium
- provide more onboarding documentation, mentors
- create a brief intro to the project(for developers to get started)
- mandate/purpose, more docs, 'open' on ramp to grow
- strategic vision and plan
- status updates on github - next steps for technical and supporting members. give project updates/timelines
- consider models to design your community plan e.g. Public Lab, Ubuntu (Contributor policy)
- governance - self-sustained community
- CBS's open source license
- need to learn more about licenses and tie this to strategy
- partnership strategy/ budget for cbs
- roles within IFRC and Red Cross
We also created a list of how to talk about data for the community volunteers with other national societies. They need to have feedback loops. This may go into the Data Playbook Beta Project