This year, the ideas behind Development Sprints are being expanded into Contribution Sprints.
This change has two main goals:
- To provide a wider range of support for our community’s Open Source packages and maintainers
- To explicitly describe & discuss a wider range of contribution types and opportunities for our community’s members
If you plan to lead or participate in a Development Sprint at DjangoCon US this year, consider the idea of a Contribution Sprint.
What Does This Mean?
Contribution Sprints are a superset of Development Sprints. They serve the same purpose while increasing the range of contribution types and opportunities.
Let’s start with what some people already know: Development Sprints. Development Sprints are an opportunity for people who maintain open source projects (or want to get involved in doing so) to sit and work together on that goal. They’ve mostly focused on contributing code, tests, and documentation. However, open source projects often need more than those things. This is especially true as the project grows in size and popularity. Development Sprints are one type of Contribution Sprint. However…
Many of the new things a project needs as it grows fall under the idea of project governance. Here’s a short list of general governance issues a project may face as it grows:
- General project governance (Who leads the project? How? How are decisions made? How are new leaders developed? How are conflicts resolved?)
- Onboarding new contributors
- Funding/Finance: does your project want it? Is it needed? Who will manage it? How will they manage it?
- Project Marketing
- Graphic/logo design
- Project legal/licensing issues
- Explicitly specifying a project’s code, documentation and testing conventions. This is metadata for your Development Sprint. It provides details about how Development Sprint activities should be implemented.
There is an excellent video on this topic by Shauna Gordon-McKeon. The video was part of the PyCon US 2023 Maintainers Summit. If you maintain a project, or are interested in helping maintain one, I recommend checking out some of the other videos from the summit.
How & Why To Lead a Contribution Sprint
The “why” is clear: if you’ve started to realize your project needs more help, especially with things beyond code, THIS is an opportunity to look for that extra help.
The “how” can be less clear, so here are some specific suggestions:
- Think about the non-code needs your project has. What areas have you as a maintainer struggled with that go beyond merging PRs, adding test coverage and improving documentation?
- Ask for help in those areas.
- Document the need for that help in your project’s
Contribution
documentation. - Make it clear in all of your project’s communications that you’re looking for this non-code help. Many people still think contributing to an open source project ONLY means code.
How & Why to Join a Contribution Sprint
The “why” can be different for everyone. Maybe you don’t feel like you are “a good enough developer” to make a code contribution. That’s almost definitely not true, but it is a feeling many people have. Perhaps you have skills in some of the non-code areas mentioned above and you’d like to contribute using those skills.
The “how” requires some introspection, as well as identifiying a project you’d like to contribute to. I would refer you to the video by Shauna Gordon-McKeon, and use that as a starting point for what skills you have that could help a project with it’s governance. Then, contact projects you’re interested in helping, to see if they’ve recognized a need for your type of contribution. It’s quite possible that a project either hasn’t recognized the need, or has recognized it, but didn’t know how to have it met. That’s where YOU can come in.
“This all seems confusing, I just want regular Development Sprints!”
Fear not! If you were already comfortable with Development Sprints, you can show up and do that! Development Sprints haven’t gone away; they’ve been added to. They used to be alone, now they have a new friend.