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.
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:
This is in addition to some of the other goals people often have with sprints:
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.
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.
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.
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:
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.
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.
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:
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:
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.
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.
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.
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.
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.
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.