How to Run a Whole Community Sprint

Most open source project sprints are focused on code contribution. While this makes some sense—open source software is, after all, software—it's also a little narrow-minded.

Open source software projects have many needs beyond coding, including project management, community management, documentation, design, governance, fund-raising, user support, event planning, publicity, and so much more. These are areas that open source maintainers often have little experience in, and thus need the most help with. While code help is also surely welcome, coding can be the one area that maintainers feel they've got things mostly under control.

Whole community sprints expand our image of what an open source contribution is, and who belongs in an open source community. It's an attempt to lighten the load on maintainers who are being asked to do everything, and help open source projects grow in their design, user support, governance, and other long-neglected areas.

Sprints can be run online, in-person, or as a hybrid; as part of a conference or as a stand alone event; for a single project or many projects at one.

This guide will focus on planning a multi-project sprint at an in-person conference. See the adaptations section below for how to adapt the guide for some of those other situations.

Multi-Project Sprints

Clarify Your Goals

Understanding your goals for the Whole Community Sprint will help you set expectations for the event and do outreach for potential participants. Reasons you might want to host this particular kind of sprint include:

  • providing support for maintainers who need help and mentorship with non-coding tasks
  • improving specific aspects of projects in your community, such as their design or sustainability
  • welcoming a broader diversity of people and skillsets into your ecosystem

This is in addition to some of the other goals people often have with sprints:

  • helping projects find long-term contributors and potential new maintainers
  • giving participants a taste of what open source is like
  • encouraging participants to network and/or make new friends
  • getting a bunch of things accomplished

Some of these goals conflict with each other. It's hard to onboard new people and accomplish a lot at the same time, for example. By figuring out your priorities, you can structure the sprint to best achieve those goals.

Determine Which Projects Will Participate

The next step is figuring out which projects will participate.

In some cases, this may be determined for you - for the PyCon sprints, participating projects are "the projects of whatever PyCon attendees sign up". If you're in a situation like this, and the sprints have been run before, you can generate a list of projects that are likely to participate by looking at previous iterations.

If you are running a new sprint, you have more leeway in picking participants. This allows you to, for example, host a topic-specific sprint (ie a sprint focused on design, or project management). See more on this topic below. Regardless, you want to open signups early on so you can begin getting a sense of project needs.

Understand Project Needs

Understanding project needs can be a little tricky, as many open source maintainers have internalized the common conception of the kinds of things they sprint on. They may want help with event planning, for instance, but not see it as the kind of thing they're allowed to ask for help with.

The quickest way to understand project needs is to give them a full list of potential tasks like those listed in this Visibility Spectrum exercise and ask them to indicate which they want help with. But you can also encourage them to do the exercise with their projects. You could even host a pre-sprint zoom call where you all walk through the exercise together. Some maintainers won't be able to attend, but others might be quite excited to do so.

The goal at this step is, for as many project as you can, get a list of the kinds of help they need. For example, you might get a list that says:

  • our issue tracker is a mess, we need help managing it
  • it would be great to have more 'user engagement' whatever that means
  • we have an OpenCollective account but nobody donates, would love advice on fundraising

Combine the lists you've gotten from different projects to figure out what topic/skill areas are most in need.

Recruit Participants

Now that you've got a list of needed skills, you can use it to recruit participants.

You can do this in two ways. First, you can include that list of skills in any of your standard publicity about the sprint. For example, if this is a recurring sprint as part of a conference, ask that the list of skills be included in emails and social media posts advertising the sprints. For example:

At $SPRINT this year, we're going to have a special focus on helping projects with user support and user research. If that's something you know about, or would love to learn more about, please sign up to sprint! (If it's not your bag, don't worry - we'll be sprinting on lots of other kinds of tasks, too.)

You can also to publicity and outreach to specific populations who are likely to have those skills:

  • some skill sets have open source communities built around them, for example open source design
  • most skill sets of professional networking groups associated with them, even if it's not open source specific, and you can advertise the sprint to them
  • you likely know at least one person with a given skillset, and can ask them to pass the invitation around their own professional networks

Understand Participant Needs

The needs of participants are just as important as those of project maintainers. When people sign up, I highly recommend asking what their hopes and expectations are for the event. They might be looking to contribute to open source for the first time, learn about new technologies, network with other people who share their skillset, meet potential clients, or just have fun.

Understanding their needs can help you shape the event itself. For instance, if many participants are eager to learn, you might create some group tutorials or lessons. Or if they're eager to network with others who share their skillset, you might use the affinity group model described below.

Preparing Tasks for the Sprint

Regardless of the kind of sprint, it is often helpful to prepare tasks ahead of time. This makes it easier for contributors to get started, and also helps identify ahead of time potential blockers and types of knowldge needed.

For the projects seeking help, you can use the common bug report format to elicit more information. You could ask:

  • What is the desired experience?
  • What is the actual current experience?
  • What have you tried before? What was the outcome?
  • What constraints do you have?

If you have domain expert participants who are eager to help ahead of time, they could help you make prompts more tailored to a specific challenge (ie common design challenges or community management challenges). They might even be able to share simple exercises that projects can do before or during the sprints.

(I am hoping to, over time, build up a collection of topic-specific prompts and exercises, but that doesn't exist yet!)

If there are commonly needed skills or knowledge across projects, you can also arrange for optional tutorials during the sprint. For example, at PyCon, there's an Intro to Sprinting workshop the night before going over commonly used tools and social norms in open source. If most of your projects have indicated they'd like help with design, you could arrange for a Design 101 workshop.

Challenges & Solutions

There are a few other common challenges when sprinting that you can, optionally, plan ahead of time to address.

Navigating conflicts

Everybody has needs, and those needs often come into conflict with one another. Naming and normalizing conflicts helps people navigate them, which in turn helps them have better experiences.

Common conflicts at a sprint include:

  • a project needing more help than a contributor wants to give
  • a contributor thinking they can help with something, then realizing they can't, and not wanting to disappoint anyone
  • a project maintainer getting frustrated with how much time it's taking to onboard a new contributor
  • people getting distracted from contributing by opportunities to socialize and learn

It's important to note that in all of these conflicts, no one is in the wrong. The situation might feel bad, but no one is being bad.

By naming these conflicts for everyone, we can give people language for articulating their needs and creating an expectation that sharing your needs is normal and encouraged.

This goes in both directions. There has been mounting pressure over the years for maintainers to be welcoming and kind to newcomers. This is overall a good thing—kindness matters!—but maintainers deserve to have their needs met too.

There are a few different ways to normalize these kinds of conflicts:

  • discuss them directly in any kind of intro session, including roleplaying the conflict
  • create flyers/handouts which discuss them, and leave them on project tables
  • designate a person on the sprint admin team who participants can go to if they feel stuck in one of these conflicts (if you go this route, this person should feel comfortable talking about emotions and conflicts; this is a skill in its own right - in fact, conflict resolution is a skill that project maintainers might want help with!)

Tracking Contributions

Open source projects typically use issue trackers for tracking code contributions (or, occasionally, other kinds of contributions like documentation). This kind of works, although because the issue trackers are used for the project in general, it can be difficult to easily visualize what specifically sprinters are working on.

Regardless, most projects will not be in the habit of using issue trackers to track, for example, fundraising or event planning contributions.

If a project only has one or two people sprinting with them, they may not need any tools to track whose working on what. But even then, such a tool might be helpful if the contribution continues past the sprint, which happens quite commonly. And for projects with a half dozen or more sprinters, tracking what folks are working on can be very helpful.

For one of the projects I maintain, we've created a separate community repo for tasks not directly related to the codebase. Github also now has kanban boards, and so we could create a sprint-specific kanban board.

Many projects will not have the time or inclination to make these changes ahead of the sprint, but you can encourage them to optionally do so. As with some of the other prep work discussed above, you could host a remote meeting ahead of the sprint to help projects set this up.

Day Of

Sprints are typically pretty unstructured. However, here are some things you might want to provide on the day of to help things go smoothly:

  • If participants are interested in networking with other domain experts, you can use an 'affinity group' setup. This idea comes from Carol Willing, and basically involves creating tables for each skill group (design, fundraising, governance, etc). Participants can sit at these tables, and project maintainers who need help with a task can go to the group to ask for help. If you choose the affinity group model, you can include prompts and icebreaker questions for people at each table, and/or request them for meta-help creating introductory resources for the community as a whole.

  • If there are tutorials or workshops you've arranged for based on feedback about what people need to know or would like to learn, make sure there's dedicated space and clear messaging around when and where the events are taking place.

  • It's also great to provide dedicated time for socializing. This can include lunch and snack/coffee breaks, or more structured socializing like a puzzle bar or 'speed dating' style quick intros to people.

  • You can use stickers or other additions to conference badges so that people can advertise the specific skills they have.

  • Encourage people to give quick and easy feedback. Are there resources they wish they had? Things they wished they'd prepared? Make it easy to collect feedback so that the next version of the sprint is even better.

Follow Up

While people will typically not be ready to make significant commitments after a single sprint together, we can encourage longer term relationships by keeping the lines of communication open. For example, we can encourage interested participants to join projects communication channels (Matrix/Slack/Discord channels, etc) and for projects to schedule virtual or in person events within a few weeks of the sprint.

You can even schedule a sprint follow up (if you're feeling up for it!). This is an invitation to projects and participants to meet virtually for an hour or so, a few weeks later, to check in on outstanding issues and get help picking what to work on next.

Adaptations

For Single-Project Sprints

When sprinting with a single project, you can do a lot more preparatory work as, presumably, that project's maintainers are very bought into the sprinting process. You can work in-depth with maintainers to identify needs and prepare tasks/issues.

However, you may have less diversity when it comes to new contributors. People who are already interested in a specific project have likely been 'filtered' more intensely than general sprint participants. In these cases, you may need to limit the number of non-coding topics you focus on, and proactively reach out to find domain experts in those specific areas. You may even give a domain expert an honorarium to come talk about the topic and help guide less experienced project members in tackling that task.

For Single-Topic Sprints

When focusing on a specific topic, you may want to partner with an organization that has domain expertise. You can also try a 'learning group' model where you facilitate projects going through a 101 guide or series of exercises together.

For example, many years ago Deb Nicholson and I put together SpinachCon, which was essentially a sprint focused on helping projects do basic user testing and new contributor onboarding testing. While we are domain experts in those topics, the model can be used even if no one involved is a domain expert.

Relational technology is built by and for people in relationship with each other.

Schedule a free consultation