The conference starts days before the first official talk. There’s topic-specific summits, sponsor presentations, and deep-dive tutorials that are definitely worth checking out. Similarly, the conference does not end with the last talk. For the next four days, groups of enthusiasts rally around their projects and sprint on making them better in person. Some say it’s the best part of the conference, actually. Let’s take a closer look then!
Who organizes the sprints?
Sprints at PyCon US are organized by the attendees. The conference provides the space with tables, power strips, Internet connectivity, and, for the first two days, catered lunches. The attendees band together to work on their open-source and community projects of choice.
You can expect bigger projects like CPython, Django, Flask, or BeeWare, to have their own dedicated rooms to hack on their stuff. Smaller projects either group together topically or just join a random friendly room with empty seats.
Of course, the general rules around health and safety apply to the sprints as well. Same goes for the code of conduct. PyCon US staff is still around during sprints, so you can talk to them or to the Sprints chairs, Tania Allard and Cheuk Ting Ho, if you need any help.
Who comes to sprints? Do I need to come for 4 days?
You’ll find project maintainers, seasoned contributors, community organizers, and first-time contributors alike. Everybody’s welcome!
Most don’t stay for all four days, so understandably, everybody wants to maximize what they get out of the experience. So come prepared. Especially if you’re only coming for a single day. Our recommendation would be to stay for at least two, this gives it enough time to set everything up and actually create a pull request with a bugfix or feature.
But if you can only spare one day, that’s fine, too. Let’s cover some ways in which you can make your experience the best.
Which project should I join for sprints?
This is a question worth answering before coming. Sprints work best for contributors who are already users of a given project. If you know a project like, say, CPython or Django well enough, you probably stumbled upon a bug in that software in the past. Maybe you looked into how some internals of that software work. Maybe you thought about making a change to it in the past. Or maybe you at least saw enough tracebacks that you feel somewhat familiar with the software you’re using.
The most impactful way to participate in sprints is to choose a project you’re familiar with, at least as a user. The project maintainers who come to sprints are helpful people and want you to succeed with your contribution. Meet them halfway and choose a project you already use. There’s not enough time during the sprints for maintainers to install software for the first time and explain how it works on somebody else’s laptop.
Of course, there’s going to be exceptions to every rule. If you first learned about some library or framework at the conference and you’re very excited to get involved, by all means join the sprint for that project!
First PR to CPython
For CPython in particular, the maintainers at the sprint recommend that sprint attendees have at least 2 years of experience as users of the Python programming language. A sprint isn’t the best place to learn the basics of programming. But it’s totally okay to be new at contributing to Python. In fact, this year we’ll be trying something new: a dedicated space for first-time contributors to CPython to make sure the experts around you are best-equipped to help you get your first pull request merged. Look for the dedicated “First PR to CPython” signage on the sprint room list.
Are there any easy issues to work on?
This depends on the project. Some issue trackers contain issues marked as “easy” or “help wanted”. You can look at those first. Sometimes such issues are a bit of a trap. When an “easy” issue is still open 3+ years later, it often means there’s something not particularly easy about it.
Asking the maintainers present at the sprint for an issue to fix is another way to get something to work on. That will often mean that you’ll get involved with whatever that maintainer already planned to work on. This might be super interesting or pretty boring to you, depending on what that particular topic area is.
So the best way to find an issue to work on is to scratch your own itch. Fix that bug you also stumbled upon. Add this thing you once wished a library had. Open the list of issues in a library you used last week. Maybe you’ll be able to reproduce a problem, add a test, and fix it.
In fact, a related cool way to get involved is to have a laptop with an environment that the maintainer usually doesn’t work with. If you see issues on the tracker that need reproducing on Windows or macOS or FreeBSD and this just happens to be the platform that you’re on right now, that’s perfect!
Speak up!
Sprints are different from tutorials and talks. Everybody, including the experts in the room, hunker down and work on something. If you get stuck with an issue, others around you will probably not notice. A good rule of thumb is to fight with an issue for 45 minutes, and if you’re not making progress, let others know where you’re stuck. They might be able to help unblock you.
Some maintainers will suggest pair programming, or will be open to the idea if you suggest it. So that’s a thing you can try as well if you’re both interested in solving a particular problem.
Sometimes two newcomers band together to work on a single issue. This can also be a good strategy and it’s more fun to attack a problem with another person interested in solving it.
Preparing your work environment
While the conference is ready for even a large cohort of sprinters to all access wifi at the same time during sprints, it’s best to avoid the network congestion on the first day when a lot of people first “git clone” their projects.
If you know the project you want to contribute to, clone their repository before coming. Try to build it and run tests. Even if they’re failing for you, you are already way ahead.
If you don’t have a project chosen yet, you can still prepare a few things in advance. Install and configure your text editor of choice, and if you already have one, run a round of updates before coming. If you’re using any system-wide package manager like Apt or Homebrew, updating your installed packages before coming is a good idea.
Keep in mind that you will be working with other people. If you have a privacy screen on your laptop, it might be helpful to get rid of it for the time of the sprint. Or bring a different device. If you keep your terminal font size tiny to fit a ton of information on screen, you might want to figure out how to increase that font temporarily at least for the sprints so people you collaborate with can see what’s going on. This also applies to text editors and their color schemes. Think about your display brightness.
Similarly, if your keyboard layout is esoteric, it will make it harder for others to type on your laptop if you need help. Maybe you can find a quick way to toggle between layouts to allow others to write stuff.
Stay safe
The following section might sound a bit scary, but we’re sharing it as common-sense advice for any large gathering of industry professionals where technology is widely actively used. Don’t let it deter you from coming!
First things first. Backup your system before coming to the event. You might drop it, you might spill liquid on it, you might leave it at a restaurant or issue just the wrong command on the terminal in the heat of the moment and lose your data. They are all unlikely events, but they all happen at conferences. Backup your system.
This is a large event. People are generally nice and helpful. But if you leave your laptop or phone unattended, somebody might take it, deliberately or not. If you do decide to leave your hardware at the table, put some unique stickers on it, so people don’t mistake it for their own. This is especially effective when it comes to smaller accessories like laptop chargers. If you’re in need for stickers, you’ll find lots of them in the expo hall during the conference!
Finally, don’t get hacked. You will be active on a conference-wide network. Keep your system up-to-date, don’t bring laptops with legacy operating systems that are no longer receiving security updates. Unless you know and trust the person you’re interacting with, be vigilant about system-wide software they want you to install and settings they want you to change. Don’t allow strangers to connect devices to your laptop or phone, whether they’re thumb drives, keyboards, slide clickers, USB-C chargers, or anything else.
Have fun!
If everything above sounds like a lot, it’s only because it’s a list of tips gained through 15 years of experience attending sprints at programming conferences. It’s there to allow you to prepare, but don’t overthink it! Join us, you might really love it.
Sprints are fun, surprisingly productive, and sometimes spark big things! We also can’t overstate the importance of putting a face to a name. “Don’t be a stranger” is good advice. Connecting a GitHub account name with a good experience you had at a conference is a great way to build trust and fast-track online collaboration in the future!
And that’s that. The mysterious sprints demystified! Come and see for yourself whether they’re really the best part of PyCon US.
Guest post by Łukasz Langa
Comments