Are you familiar with development sprints, coding events held immediately after Python and Django conferences? They encourage attendees at the annual PyCon (or DjangoCon) or one of the many regional PyCons to stay and use the venue space, decked out with power and network, to work on open source projects with other Python developers and practitioners. Since everyone is flying in for the conference anyway, this unstructured time is a remarkable way to forge ahead on projects in person.
Scaling with people
One of the staple projects at these sprints for the last few years is BeeWare. Mentioned in multiple articles on Opensource.com, BeeWare is an extremely welcoming project for newcomers who want to help. To encourage participation, the BeeWare project has offered challenge coins for anyone who has contributed to the project. This can attract dozens of first-time project contributors to the sprint tables, who often need some support at the beginning to get up to speed with our project.
I got a @PyBeeWare challenge coin for contributing to BeeWare at @PyCaribbean! ??
Thanks @freakboy3742! ? pic.twitter.com/RptHkpxbMj— ✨ Trey Hunner ? (@treyhunner) February 20, 2017
After running over 20 development sprints around the world, we've needed new ways to, for want of a better term, wrangle these enthusiastic hordes of newcomers. This is above and beyond the general care and respect that we give to all our sprint participants. BeeWare operates under a code of conduct (and only runs at events with their own codes of conduct). Ultimately, anyone who has taken the time to come to the table, whether they've contributed before or are an old hand, must be treated with respect. A poor experience at our table for a first-time contributor could damage their entire outlook on open source.
On the other hand, people don't scale terribly well. Russell Keith-Magee, Beelevolent Dictator For Now of Beeware, can only mentor so many people at once. So we needed a way to ensure folks could get the information they need to get started and had more than one person to ask for help if they got stuck.
To handle this, we developed a second challenge coin: the Yak Herder. To earn this coin, you have to help two or more people earn their Yak Shaver coin. This has dramatically helped us scale our onboarding process for new contributors, while those who help also get a small token of our appreciation. We've also found that initiatives like the Git Help Desk at DjangoCon US help us and other projects by onboarding new folks to Git and GitHub in general, taking the strain off projects so they can focus on onboarding for their project specifically.
Scaling with software
Unfortunately, even with these steps, we've hit other bottlenecks at sprints, this time technological. With dozens of folks trying to submit pull requests to the same project at the same time, we often faced backlog with our continuous integration (CI) systems. The free tiers available for open source projects on platforms like Travis CI and CircleCI are an invaluable resource; but since they are a free service, they have parallelization limits.
BeeWare developed a scalable CI system a few years ago to allow us to scale for events, and this system works well for us. While Travis CI and Circle CI have paid plans, they don't scale to zero and don't work well for projects like BeeWare with very spikey loads.
If your project has similar spikes in CI, or you're looking for a system to run on your own kit, consider looking at BuildKite. BuildKite have been around for a while, but have only recently added GitHub SSO support and the ability to mark pipelines public, meaning you can use it with public repos just as you would with Travis CI or CircleCI. You could also configure your GitHub repo to use Google Cloud Build as it's CI system, which comes with 120 free build minutes a day ($0.003/min after that), and 10 concurrent builds as default.
If you have a more complex project with such CI needs, consider if a more advanced system like BuildKite or Google Cloud Build is right for your project. They do require more setup than Travis CI or Circle CI, but the benefits of a more configurable build system may outweight the initial setup requirements.
Summary
Overall, we've found that with active delegation, we can reduce the strain on both our principal engineers and critical infrastructure, which gives us more time to do the stuff we want to do—work on our project and enable others to help us.
Katie McLaughlin will present "Wrangling enthusiastic hordes" on May 4 at the PyCon Maintainer's Summit, part of PyCon 2019 in Cleveland.
Comments are closed.