Are you overwhelmed with all the directions your project could go? Are you unsure of what to prioritize, or what strategic direction to take? Is there disagreement in your community about what to focus on? Or are you not hearing anything from your community at all, and want to get them involved?
These are common problems for growing open source projects. Some maintainers like making all the decisions themselves, but many would prefer to be community led. But how do you actually take direction from the community?
Community roadmaps offer a framework for making strategic decisions and empowering community members, without the higher stakes and deeper commitments of a governance transition. It can be used to help make new connections to users, funders, and lurkers in your contributor community, as well as to strengthen your existing relationships. It's not just about setting a direction for your project. It's about showing your community that this is their project, too.
The community roadmapping process is smaller in scope than many of the other services I offer and can be seen as the 5 Cs in their purest form:
1. Clarify Your Needs. The first set of needs to think about are those driving you to do a community roadmapping process. Are you feeling overwhelmed and hoping to get more support in general? Do you feel disconnected from a specific group, like certain users, and want to feel better connected? Are you responding to existing contributors who are itching to get more involved? Is there conflict in the community you're hoping to resolve?
The answers to these questions will help shape the process as a whole and, specifically, who we focus our efforts on when doing outreach (that is, inviting folks to participate in the process). If you feel disconnected from a specific group, we'll brainstorm ways to reach out to them. If there's conflict in the community, we'll make sure people from all sides are represented.
2. Connect With People Who Can Meet Your Needs. This is the outreach step. You can advertise the community roadmapping process in any of your existing channels (Matrix, Mastodon, Discord, your mailing list, a Github readme, etc). I recommend including a link to a community survey as part of this outreach, so folks who don't want to participate in a live event can still give feedback.
For people who you really hope will participate, either because they're already connected to the community or because they're part of a group you hope to see more of (funders, users, designers, etc), it's important to do personal outreach. Ask them directly and privately to participate.
3. Communicate Your Needs to Each Other. The roadmapping process typically culminates in a live virtual event, but you'll need to do some pre-communication. The survey mentioned in the previous step is one option. You can also do pre-roadmap interviews, which is especially recommended when there's known conflict. You'll also want to set up whatever tool you'll be using to track your roadmap and invite people to submit suggestions ahead of time.
At the live event itself, the roadmapping process goes in three phases. First, participants share all the things that the community could work on, typically in one domain at a time (ie 'community events', 'new features', 'infrastructure issues', 'publicity'). This is basically a big brainstorming session. Then, participants up-vote things they think are high priority. Finally, participants indicate which things they are interested in working on.
A big enough community may need to break these three phases up into separate events or into separate domains (ie a "technical roadmap" and "community roadmap").
4. Address Conflicts. If there are known conflicts ahead of time, it's worth creating space for free-form debate in the run up to the roadmap sessions(s). That can mean encouraging folks to discuss on your mailing list or getting people together for a private call. Regardless, there may be old conflicts or new ones that arise during the roadmapping process. This is actually a great thing. It's wonderful when people care enough about a project to speak out when they disagree!
Our goal is to create space to work through the conflict without letting it derail the roadmapping process. I recommend setting a short time limit for disagreement and, when that limit has passed, indicating that you will host a separate conversation for interested parties to work through the disagreement. I recommend making that follow up process very clear and easy to execute (for example, you could say, "I am creating a discussion topic for this in Github right now, and we can follow up there" or "If you're interested in debating X, please write your name down, and I will schedule another call within the week"). This allows people to put down the disagreement without worrying their voices are being discarded.
A less obvious conflict that might occur is when many people mark a task as high priority, but no one is interested in actually doing it. As with other forms of conflict, we can spend a few minutes discussing it, but may need to table the discussion for later. It can be tough to frame this conflict without making community members feel bad for not volunteering, but it can be done. Helpful frames include: "What about this task makes it unappealing, and can we mitigate/change that? For example, if it feels too big, can we narrow its scope?" "Are there people not on this call who might be interested in working on this?" "Should we raise/spend funds to hire a contractor to do this?" "Why have people labeled it a priority, and are there other ways to get the underlying need met?"
5. Make Commitments. The third phase of the process, where people indicate what they're interested in working on, is the first part of the commitment process. People may, during the roadmap meeting, proactively volunteer to tackle something specific. If so, you can assign them that task in whatever task management tool you use. Or you may need to follow up later with the subset of people who said they were interested, and see if any of them are willing to commit.
Copyright © by Shauna Gordon-McKeon. All materials on this site are licensed CC-BY-NC unless otherwise stated; please contact me directly if interested in commercial use.
This website's design is based on a theme by Themefisher. It is built using the open source projects Bootstrap, Jinja, Python Markdown, Shuffle JS, SlimSelect JS and LiberaForms.