RARE TechnologiesIn this blog I want to tell you what it takes to organize an open source coding sprint – find a venue, set an agenda and then actually run it.
Tom Sawyer running a sprint in 1876.
‘Tom, let ME whitewash a little.’
Tom considered, was about to consent; but he altered his mind:
‘No — no — I reckon it wouldn’t hardly do, Ben.
You see, Aunt Polly’s awful particular about this fence — right here on the street, you know — but if it was the back fence I wouldn’t mind and SHE wouldn’t.
Yes, she’s awful particular about this fence; it’s got to be done very careful; I reckon there ain’t one boy in a thousand, maybe two thousand, that can do it the way it’s got to be done.’
— Mark Twain, The Adventures of Tom Sawyer (1876)
I am retiring from the position of community manager at gensim, an open-source project which I’ve been running for more than a year. It was awesome! Now I want to share my experience organizing an open source sprint based on the 8 sprints we ran in in the last 12 months in 5 countries: Brazil, Germany, India, Russia and USA.
Warming up the scene
For the past year my routine was to change location every couple of months. Yes, it’s the hyped digital nomad lifestyle. It was fun for a year but that’s enough. It has become quite routine. Every place is the same. Land in a new country, get an uber to an airbnb, go out with the host. And in every city I ran a coding sprint for a couple of dozen people, sometimes several times. The key is to warm up a scene slowly over time. First, just go to a local meetup, maybe give a lightning talk, say hi to the organizers. Arrange to give a 20-minute talk at the next event. After the talk, pass a piece of paper around to collect emails of people interested in your sprint. Now you have your launch team! Ask them if they know a company who is hiring in your field – they are your sprint venue! They would love to give you their office on a Sunday and might even buy you lunch.
Creating an event page
Ask one of the local meetups to market it as their event at meetup.com. It’s a win-win – you get access to the local audience and they get awesome events in their meetup.
Writing the event description. Take a page out of the Tom Sawyer’s life! Create a barrier to entry. It shouldn’t be hard. I ask people to apply with their resumes. And I do reject applicants for who in my opinion will get nothing from the sprint. I have seen people walk out in a middle of a sprint, feeling lost, the content being over their head. It’s a terrifying social experience and there is no benefit for all parties involved. Feeling selected also motivates people to actually turn up at 9 am on a Sunday morning. The usual meetup event ratio of 50% attendance can really ruin a chamber event of 20-30 people which a coding sprint usually is. So you need something that brings it up to 70-80% and applying via email with a resume is such a tool.
Setting the sprint agenda
Don’t plan to accomplish anything hard. Divide your expectations by 10. Shoot for getting documentation or one line bug-fixes.
Yes, I know you are a smart woman and you can accomplish some serious mega feature if you lock yourself in a room with your friends, aka other core-devs, even for 90 minutes. But that event is called “a project meeting”, not a public sprint.
One Sunday, 9 am – 5 pm with a lunch break is only 5 hours in front of code out of which 4 is spent getting familiar with the codebase. If you want people to sign up then think about what you can give to the people, not what you want to take from them. We usually run a “Learn machine learning by improving our tutorials” sprint. A lot of people want to learn machine learning so it gathers a good crowd. It is useful to us too. We have a lot of tutorials and they don’t always have the clearest possible explanation or just run slightly differently in the latest version of the software. Watching a live human brain boil as they read your tutorial is a very useful thing to get you to the “Absolute Beginner Quickstart” Ver. #27. Can your project help them build a blog page? Program their home assistant? Pick something that will benefit both you and participants. And you should also label some bugs as “sprint_sized” the night before. But please don’t push them on people – fixing them benefits the project much more than the participant.
It’s good to seat people into small groups of 6 people based on the broad feature that they are working on so that they can talk and help each other. Having a shared google doc with the task helps to direct people to tasks and record their achievements. At the end of the day, let every team talk about what they did. Let them know in the morning that it will happen at 5 so that people start preparing and not leave early. That end of day presentation gives people a sense of accomplishment even though they didn’t leave a mark in your commit log.
During the sprint
As a sprint organiser you are the host. The project is your house and the participants are your guests. They came here to be entertained. They didn’t come here to work. (See the Tom Sawyer cartoon caption above.) They have already endured a full week of deadline pressure and repetitive chores. They have already gotten the paycheck to buy a nice house with a garden in the best area of the city. They didn’t come to you for money. They came to your house for the joy of coding, of learning something new, of contributing, and for the joy of sharing their skills to make the world a better place. It’s your job to be the joy provider. Be freaking nice to them. Ask about their ambitious plans to use your project, what motivates them to attend. Slack them the link to “your first pull request” tutorial with the nicest smile you have. In the long-term view, helping somebody make their first open-source contribution is more important than fixing that flaky Windows multi-threading unit test. In 50 years, when open-source software has eaten the world, they will remember you and your project as their first contribution!
What should you personally be doing during the sprint? Just helping others. Please make a sign saying “Please interrupt me” and stick it to the back of your laptop. It clearly signals your intention to get zero of your own work done and just enable others to contribute. That is your job as a good host. You have the rest of the year to be alone in your bedroom thoughtfully reviewing pull requests.
“Please do!”.
After the sprint
Nothing happens after the sprint. You have to click “Merge” on the PRs during the sprint. That github button releases the famous “mergeytocin” hormone in the contributor’s brain. A strong link between the high, your face and your project is formed that moment. In the Russian language “happiness” is “счастье” means “contributing”, “being a part of something”. That is a general homo sapiens trait all over the world. People come to your sprint to feel the joy of being a part of something and you have to give them closure by “git merge”. A perfectly good PR that you “didn’t have time to click merge” during the sprint is a lost opportunity in this neuro-linguistic programming.
If a participant didn’t submit a PR during the sprint then forget it – you will never see that fix. They probably had a perfectly valid reason – wanted to put final polishing touches next weekend before sharing it with your harsh critical code formatting eye, whatever theirs and yours efforts are lost. Well, at least you made a new friend during the sprint lunch.
If a PR was raised during the sprint but not merged because it needed more work – then you are in luck. You have a new task in your project suitable for a beginner getting acquainted with the code. Such tasks are gold as they grow the community and give beginners confidence. And what about the original creator of this unfinished PR? You will never see them again. Yes, there is a github ping etiquette. But in reality, they just make people feel bad about themselves so they write you excuses about meetings or being on vacation. Fate may have it that your ping worked and they come back and finish it but most probably it wasn’t because of you. They are probably job hunting and heard a rumour that having a column of 7 green github activity squares brings a job. If they really cared about that feature, they would have finished it before your coding sprint.
Go forth and proselytize!
Ok, hope it was useful – now you know how to rock up to a city and get some community action going. Deal them a dose of altruistic joy in exchange for the three lines of their code.
Thanks to Hobson Lane and Ivan Menshikh for proof-reading the early drafts.
