When I first started attending Python conferences, my focus was entirely on the talks on the schedule. That’s not surprising, there’s no conference without talks! Over the years, though, I came to appreciate the so-called hallway track and the usual post-conference sprints that many events include. These days, I mostly come for those. Let’s talk about why.

Raw numbers

Before we get into subjective and soft reasons why sprints are great, just consider how productive they are for Python. To give you an idea, let’s focus on three Python conferences of different sizes on three continents.

At PyCon US 2025, 370 new PRs were open to the Python organization during, 286 to thecpython repository alone. Close to 300 PRs were merged into the Python GitHub organization during that time. That’s for four days of sprints. This is over 2X the number of PRs handled during the same period when there’s no sprint happening.

There’s been two days of sprints at EuroPython in Prague this year, but they didn’t disappoint either: 122 new PRs open to the Python organization, including 99 to thecpython repository. 79 PRs were merged into the Python GitHub organization during this time. This is 1.75X the number of PRs handled during a typical weekend.

Even single-day sprint days at conferences are pretty productive. At PyCon Korea earlier this August the attendees managed to open 59 new PRs to the Python organization, including 35 PRs to thecpython repository. Over 40 PRs were merged into the Python organization that day. Still 1.7X the typical velocity.

Hopefully, you’re seeing what I’m seeing: sprints can provide a measurable boost to an open-source project. The longer the sprints are, the bigger this boost is. This is because many contributions need more than a day to bake, some bugs can be pretty stubborn, and many features uncover surprising depth once you start implementing them.

Momentum

There’s something magical about a large group of people banding together to attack problems. While this is what open source is in general, adding together physical presence in the same physical space at the same time is the secret sauce. Real-time coordination really is more efficient. We can guess at reasons for this, but we can safely assume a big part is simply that humans are social animals. It’s easier to empathize with a person when they’re in the same room with you. In my experience, pointing at a screen still beats Internet communication.

Part of what makes sprints so productive is that it is a time-boxed period of uninterrupted time away from your usual work environment. And that’s true for everyone, so people have the ability to focus on a specific project or problem for an extended period of time. But since there’s a time limit to how long the sprints are, there’s also some productive pressure to ship something concrete by the end of your stay. So, it’s rare to see people playing games or doomscrolling during sprints. Instead, they want to ship something, even if it’s a humble small first contribution.

Better yet, after you spend some time with a person in real life, even online interactions with them afterwards change. My brain does this thing where it reads GitHub comments of people I know in their voice. This little thing additionally humanizes the pixels on screen and makes the interaction smoother. When you come to sprints, you build more lasting connections, because you don’t only talk about stuff in the hallway, you’re solving problems together.

You’re getting for free what you wouldn’t be able to buy if you tried

You’re solving problems together alongside developers from different companies, backgrounds and specialties. Some of them are maintainers of the projects you’re contributing to, with a wealth of expertise they’re sharing freely. You get immediate feedback, you can learn at a rate that is impossible to match online. You learn not only by doing and asking questions, but even just by watching others work. You discover better tools or ways to use them you didn’t know existed.

To put it bluntly, the experts you work with during sprints would be impossible to hire as tutors, and here you get to work with them free of charge. Think about it, that alone makes it worth staying for sprints. And don’t get cold feet, either, because...

You belong

I’ve heard some newcomers are worried that maybe the expected experience level is too high. I say you will definitely find something productive to do. I even blogged about this specifically for PyCon US this year, so you can read “What to Expect at PyCon US Sprints” to get an idea about how to make your experience great. The PyCon Korea sprint organizer and Steering Council member Donghee Na says: “I notice that the participants who had a good experience at last year’s sprint tend to rejoin the sprint this year. I hope that many of them come back next year too.” I’m seeing the same thing, and want to see even more of it. We do care about your experience.

Specifically at PyCon US, this year we tried something new. We split the CPython sprint room into two rooms: one dedicated to first-time contributors, and one to seasoned developers that needed to focus on some feature or bugfix they really wanted to ship before leaving Pittsburgh. It turned out great. Talking to attendees on both ends, I think both rooms enjoyed this setup and we will be repeating that for next year. While I was coordinating the first-time contributor room, I was heartened to see that quite a few veteran core developers joined me in the room. It was fun all four days!

At EuroPython, the setup this year was such that Petr Viktorin and I were coordinating the CPython sprint... or so we thought! In parallel, Adam Turner was leading the CPython documentation sprint, but attendees responded so well to him that he quickly organically became the de facto leader of the entire CPython sprint. Kudos, Adam, you did great!

Dedicated sprint events

It’s not all roses with sprints that are attached to conferences. After an intense few days of the larger event, people tend to get tired. Introverts run out of steam. Key people that you could use talking to don’t stay or are only available on the first day. If only there could be an event where core developers gather for a week just to sprint. No distracting talks and hallway tracks!

CPython actually does this annuallysince 2016 with the obvious online-only hiccup of 2020 and 2021. We do love those sprints as they are both productive and fun. Last year wereturned to Meta while this yearwe will be sprinting at Arm Ltd in Cambridge UK. Unlike the conference sprints, this is an invite-only event for core developers where we can focus on making the next version of Python shinier than it would otherwise be.

But maybe organizing sprint-first events makes sense in general? It seems to me like that could be pretty helpful. Or maybe this is already a thing? Let us know if you know of sprint-first events in your area.

And in the meantime, consider staying for sprints at the next conference you’re attending. It’s well worth it!