By Nisha Kumar, open source engineer, VMware
I’m a longtime Python developer, but until this year I had never been to PyCon, the largest international conference for Python users. I went this year because I wanted to run a development sprint for Tern, the open source project that I maintain. PyCon’s development sprints are a cross between an unconference and a hackathon. Attendees spend up to three days working on open source projects or meeting up with the maintainers.
Tern is an open source project that finds the metadata of the packages installed in a container image. In order to associate a container image layer with the imported packages, we needed a way of debugging a container layer by layer. Tools like Docker, runC or containerd do not allow you to deconstruct a container image and put it back together. That being said, I was hoping to enable Tern to achieve this at the PyCon sprint.
As a first-time sprint leader, I faced a pretty steep learning curve. In the end, I had a great experience, but there were several things I wish I’d known ahead of time that weren’t documented on the PyCon website. I’m going to share those with you here.
Arrive well before the sprints begin
Even though the development sprints always begin the day after the main conference concludes, you need to be there for the final keynotes at the very least. Right after the last keynote is given, sprint leaders pitch their project to the sprint participants. Luckily, a colleague suggested I go to the last day of the main conference, where I ran into a volunteer who told me about the pitch session. Bottom line: if you want new developers at your sprint, then you need to pitch!
Have your PyCon pitch ready
Because I was unaware of the pitch session, I had not prepared my pitch. You get just 45 seconds to make your case and you need to stand out and make those seconds count. It’s always a good idea to think about your pitch beforehand. Tern was especially challenging to pitch because it deals with compliance, which can sound boring on the surface. My pitch emphasized that we would be working on taking apart a container image and putting it back together. This seemed to have piqued some curiosity, as I got a lot of questions about Tern during the sprint.
Say you welcome newcomers (if you indeed do)
Sprints are an opportunity for current contributors to meet and talk about a project, discuss architectural and implementation details and get some coding done. But they are also an opportunity for people who are new to Python or to open source to come in, talk to the maintainers and learn how they can contribute. Therefore, it’s worth thinking about whether you want to advertise that you welcome newcomers. I did, partly because I wanted to be welcoming to all, but also because it attracts people who are experienced in the programming language but new to open source. It suggests that you are a friendly maintainer who is going to be pleasant to work with. Since your contributors are volunteering their time, this is a good thing to be signaling.
Plan what you will be working on
The PyCon website did have some information on how to prepare for a development sprint, which was useful up to a point. It emphasized that you need to be clear on your goals for the sprint and document all of the pieces that are required to get contributors up and running. But it did not offer much guidance on what a set of realistic goals might be. Having no idea what to expect, I created just one issue to work on and wrote up what I thought we would need to get started on that issue. Sometimes, contributors just want to look at a list of issues and focus on one they think they can tackle. With that said, it may be a good idea to have a goal and several issues targeting that goal.
You need a developer environment
Getting new contributors started takes up a good bit of time during the sprint. It’s a good idea to prepare a development environment to speed up this process. You can do this by creating a Vagrantfile or a virtual machine for developers to use. Tern is a young project with just a few contributors at present, and we did not have time to build a developer environment. Luckily, during my own sprint, one of the developers helped me create a Vagrant environment and then submitted documentation on how to do it. We’ll now have that at the ready for next year’s PyCon.
Think about onboarding
If, like me, you want to be newcomer-friendly, then you need to think about how to onboard your new contributors. Tern is in a tricky situation where it is young enough that there isn’t much code to navigate, but we also haven’t had time to put the rails in place to get people oriented when they join the project. Those rails are important so that new developers do not stumble around and end up discouraged. Luckily, I had a small enough team that I could give individual attention to each during onboarding.
Have modest expectations
If you go into the sprint convinced that your project is so awesome that you will obviously attract a lot of people, then you will probably feel bad when it only attracts a handful. But I had just the opposite experience. I was worried that I would be there coding by myself and was pleasantly surprised that I got five people who stuck with me for two days.
Indeed, for the lack of information that I had going in, things turned out pretty well.
We got good work done. I had those five contributors stick with me the whole time I was there, along with three or four others who came in and out. We had a total of four pull requests merged, with one in review, three issues assigned and now being worked on and two others filed for the future. Thanks to the sprint, Tern now has both a developer environment and a path to debugging container images layer by layer. We also have some new ideas on how to implement other aspects of Tern.
We raised the project’s profile pretty significantly. I had a lot of people come by to ask questions. That in itself was a win because that means that people were curious about why a project like this is needed. There were many people in the enterprise space that came up to me and said that they’ll be watching the project because they’re interested in using it. I have also noticed that the number of stars and forks on the project have increased since the event.
It was also great to have the chance to work with a diverse community of contributors who were not affiliated with VMware. They came from a wide range of backgrounds and I got to learn more about both their work and life. Running this development sprint was an enjoyable experience for me because of the people.
Lastly, I learned from the people I met as I investigated other sprints. I heard about other open source projects that might be relevant to the challenges we are addressing with Tern and that will feed back into our work.
If you are interested in contributing to Tern, check out our contributing guidelines where you will find instructions to join our Slack channel and submit a pull request. Stay tuned to the Open Source Blog for more on Tern and PyCon, and be sure to follow us on Twitter (@vmwopensource).
