Whole Community Sprints

Why You Might Need Whole Community Sprints

Whole community sprints are often hosted not by individual projects but by those who organize across projects, such as conferences, meetup groups, student groups, or foundations. While I'm happy to work with a single project to facilitate a whole community sprint just for them, this page is focused on the more common case of a sprint for many projects.

Whole Community Sprints: The Relational Approach

(For a more detailed breakdown of how Whole Community Sprints work, see the How To Guide.)

As with all of Relational Tech's services, we follow the 5 Cs.

1. Clarify Your Needs. What needs do the projects participating in this sprint have? If you have run the event before, you can reach out to previous participants and ask them. If not, you can ask for likely first-time participants who are willing to share their needs. Ideally these participants will have capacity to do needs identification exercises, but in a pinch filling out a survey will do. Regardless of the format, it's important that participants be pushed to broaden their understanding of their needs beyond code contributions. The Visibility Spectrum exercise is great for this purpose.

2. Connect With People Who Can Meet Your Needs. Once you've identified some key classes of needs, it's time to connect to people who can potentially meet them. What this looks like will depend on the context of the sprint. Is it virtual or in a specific location? Part of a large conference, or a small meetup group? Some options might include:

• An in-person meetup group whose projects are requesting design help might reach out to a design meetup group located in the same city.
• A large conference with projects requesting grant writing help might put out a general call to attendees in the hopes of identifying a small subset with grant writing experience.
• A virtual sprint looking for project management help may put out an open call on social media for people with project management experience to join their sprint.

3. Communicate Your Needs to Each Other. The new participants being brought in are not just there to meet your projects' needs. They have needs too! Ask them what they're hoping to get out of the sprint. Maybe they want to find a project they can join for the long term; maybe they want to help as many projects as possible just for one day. Maybe they want to network with other people who have their skills. Maybe they want to learn more about the tech industry, or about science or machine learning or whatever your conference is about. Whatever their needs, we can adapt the structure of the sprint to meet those needs.

4. Address Conflicts. Sometimes projects and participants will have mismatched needs. Maybe a project needs help with something that will take more time and effort than a participant has to give. By being explicit about potential conflicts, we can make it easier for attendees to navigate them.

5. Make Commitments.While people will typically not be ready to make significant commitments after a single sprint together, we can encourage eventual commitments by helping projects keep the lines of communication open after the sprint is over. 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.

Over time, if enough organizers adopt the whole community sprints approach, we may eventually see a far greater diversity of people and skills in open source projects.

Service Specifics

• Help identifying which project or projects will participate.
• Help identifying project(s)' non-code needs. These might include UX design, marketing, event planning, project management, documentation, and more.
• Recruiting participants with expertise in those areas, and helping organize them into affinity groups (if desired).
• Working with participants to articulate and meet their needs.
• Helping projects articulate and prepare tasks, as well as create onboarding materials or overviews, if needed.
• Running/facilitating the event, including leading interactive trainings if needed.
• Assistance with follow up.

Outcomes

The most important outcomes are often the most uncertain. So I like to frame outcomes in terms of both tangible accomplishments, and the more elusive, harder-to-measure things we're truly aiming for.

Tangible

• An event will be run.
• Your projects will have a much better sense of their non-code needs.
• Progress of some kind will have been made on some of those needs.
• There will be new members of your community, and/or existing community members will be contributing in new ways.

Intangible

A community with a more diverse range of skills going forward.

Long term involvement of people who can help with key challenges facing projects.

More successful, diverse and resilient projects.