13 attendees on Saturday, 18 July 2015
- How to incorporate community feature wishes with the company software roadmap
- How to get feedback from users and incorporate that in the roadmap
- Agile development but having the mandate to increase community contributions -> How to incorporate community contributions in 2-week sprints?
One huge open source project used to limit access to only approved project teams, but went away from that and now allows anyone to publish. The merit of the developers and their contributions will weed out non-functional / sustainable projects. The infrastructure team does help newbies getting started so they are not left to their own devices, but have good support available to learn using all the tools that the core team and the wider community is used to.
Developer meetings that are open to everyone help involve community contributors as they can talk with the core team.
Boundary setting is important: Support volunteers, but also let them go and allow them to fail so they do not feel overwhelmed if they can't finish something. Examples included:
- If community member can't finish something for a deadline, give it to somebody else and communicate that change so it's transparent.
- Working on a task instils ownership and a sense of responsibility. -> Let volunteer know it is OK if they have to go and can't finish.
- Volunteers are sometimes treated like employees and are rostered like others and fulfil important tasks whereas in other communities, they are given supplementary tasks so if they do not show up, the logistics / infrastructure is not jeopardized. -> Every community needs to decide how they want to work with volunteer contributions.
Ideas for community involvement where community members do incredibly valuable work, but where it may not matter so much if the work doesn't get done by the end of a sprint:
- Have community sprints around documentation and setting up processes.
- Community builds reports and analytics.
Processes shape contributions -> contributors need assistance with the processes and tools involved to become familiar and comfortable with them. Don't expect they know them from the start.
Make decisions clear: In one community meetings didn't happen officially if there is no record / summary of it afterwards that is shared.
Work with deadlines and communicate them, e.g. deadlines for providing feedback, deadlines for when a feature needs to be done to be considered for a particular release.
Having smaller pieces of work helps involve community members who may not be able to commit large chunks of time. That goes along with making incremental changes.
In one community, the core developers usually start new features and the community then contributes small changes
It's not just about developers. There are many roles in which community members can contribute, e.g. docs, QA, design, UX...
To sum up:
- Involve community members in small changes if they can't handle bigger projects with a hard deadline.
- Let everyone participate -> merit will weed out
- Support volunteers
- Let volunteers go without them losing face
- Set expectations and communicate them clearly so there is consistency.