Preparing for conference sprints
Sprints are a valuable event at conferences, for you, the project, and the broader community. This post helps you prepare to get the most out of them.
These ideas are a result of a discussion at Conference Chats (go check them out!). Thank you to Hugo van Kemenade, Jon Banafato, Kojo Idrissa, and Reshama Shaikh for your insights.
- What are sprints?
- How do I prepare for sprints as a Project Leader?
- How do I gain new contributors during sprints?
- Who can be a Project Leader?
- How do I prepare for sprints as a prospective Contributor?
What are sprints?
Simply put, sprints are the part of the conference where people gather to work on open-source projects. There’s a more thorough description in a DjangoCon 2023 blog post by Kojo Idrissa.
This has a few benefits. The first is that we’re creating value for the project by fixing a bug, implementing a new feature, improving a process, etc. The second is that you’re working with new people and being exposed to new ideas. The third is that the community bonds that enable us to move forward together are being built and strengthened.
Sprints have three types of participants:
- Sprint Organizers
- Project Leaders
- Contributors (prospective and existing)
The Sprint Organizers are provided by the conference. They make sure people know where they are going, ensure there’s space for people to work, and will handle any questions or requests for the sprint. There’s more to it, but that’s a conference organizing discussion.
The Project Leaders are people who help others contribute to a specific project during the sprint. They will be the ones answering questions and providing assistance to others about the project. If there’s a discussion for the project, they are the ones who are facilitating it.
The Contributors are the people who are primarily focused on delivering value. They may be entirely new to the project or an existing person looking to finally work on a specific problem. Contributors may collaborate with each other as much or as little as they want.
How do I prepare for sprints as a Project Leader?
Excellent question. This may be a long answer.
The first thing to do is to reflect on what you want to achieve in this sprint for the project. Is it to gain new contributors? Is it to solve a particular problem? Is it to discuss and improve collaboration with other contributors to the project?
How do I gain new contributors during sprints?
If you’re looking to bring new contributors to your project, then you should do the following:
- Prepare a set of newcomer-friendly tasks for people to work on
- Refresh your setup documentation
- Tell people that you’re going to be at the sprints
Prepare newcomer-friendly tasks
To gain a regular contributor at a sprint, you should try to have them achieve something they can be proud of. Opening a PR is great. Getting a PR merged is better. However, there’s a lot of overhead in getting code merged (running tests, updating docs, style guides, etc.), so having problems that are straightforward is crucial.
That is why you should have a collection of newcomer-friendly tasks for people. These should contain the steps to reproduce the problem and indicate what the solution is and where it should be placed. Yes, this sounds like it’s doing most of the thinking part of problem-solving, but remember what we said about the overhead and wanting to get a win for them.
Once you have the collection of newcomer-friendly tasks, try to reserve them. If it’s issues on a GitHub repo, maybe use a “Reserved” label or assign them to yourself. If you’re not a maintainer of the project but want to lead it, email the maintainer(s) explaining what you want to do.
Refresh your setup documentation
If you don’t have this documentation, please go write it.
You should work through the steps in your documentation step-by-step.
Please keep in mind, some people will not read all the text and just run the code pieces. If you have important information tucked away in the prose of your setup documentation, duplicate or reference it in the code segments.
Tell people you’re sprinting on your project
This serves a few purposes:
- It’s marketing for the project and brings attention to you and it
- It’s an implicit advertisement for the conference
- Prospective contributors can be told to do the setup work before the sprint
By telling people you’re sprinting on the project, you’re helping yourself, the project, and the conference and making your sprint time more efficient.
There are a few places you can write about this:
- Social media with the hashtags such as
#Djangofor discover-ability - The project’s communication platform (GitHub discussions, forum, Discord, Slack)
- The project’s documentation (release notes, the README, etc.)
- The conference Slack/chat platform
Who can be a Project Leader?
If you’re comfortable enough with a project that you can identify newcomer-friendly problems, then you can be a Project Leader. If you think you can but know you lack in-depth knowledge on challenging problems, that’s fine. When you can help people navigate the setup process, guide them to newcomer-friendly issues, and then guide them through the contributing process, that’s perfect.
You don’t need to be the expert on the project to help other people get started contributing.
How do I prepare for sprints as a prospective Contributor?
You should do the following to prepare as a prospective Contributor:
- Go through the setup documentation (and fix the docs where it’s out of date)
- Look for an issue to work on; start with those labeled as newcomer friendly
That’s probably sufficient. You want to minimize the amount of rote work that you’re doing in the sprints and maximize the time spent on collaboration. Having access to someone who can answer questions in person is extremely valuable. Ideally, you want them sharing information and context on the project, not on project setup overhead.
One last thing. Consider creating hour blocks on your calendar a few weeks after the conference to continue working on the project. It’s difficult to get all your work done in the sprints. Even if you have a PR merged, you’re likely to pick up another. Chances are that you will end the sprints with something unfinished. If you’re not a regular contributor to open-source software, you should try to go out of your way to create time to contribute. Sometimes mental gymnastics are helpful!
If you have thoughts, comments or questions, please let me know. You can find me on the Fediverse, Django Discord server or via email.