What we can learn when we accidentally a hackathon
Oslo.pm organized a Perl 6 Patterns hackathon a short while ago. I feel compelled to address some of the claims that have been made about this event, and hopefully set some records straight. The rumors have been going on for too long. Important issues need to be shed light on. We need more facts, and I hope that this journal entry can help.
Before the facts are served, I have to clarify which parts I played in the events during that fateful hackathon. It must admit I was present much of the event, maybe not fully in my fragile mind, but certainly in in the corporeal sense. I’ve done my best to manage the effects this event did to my psyche, so I hope these half-mad ramblings can serve as a fair heads-up or perhaps a cautionary guide for all who might choose to follow in the footsteps leading to and through the hackathon time-line.
Preparing for the inevitable
We were three who decided to make stuff happen. Jan (frettled), Karl Rune (krunen) and myself, Salve (sjn). We had only a vague idea of what we getting into, but luckily sense enough to spend some attention preparing for the event. Here follows the most important items on our list of pre-hackaton tasks. I choose to list these to give you an idea about our preparations, so others may learn from this. The points are listed in a rough chronological order.
- Pick a weekend and a venue. Meeting rooms and classrooms are especially well suited for hackathons, but make an effort at finding a venue that also has a space that is suited for quiet activities, and also isn’t too far away from food and drink.
- If you can pick a weekend just before or after a relevant conference, you can use this for your benefit. Conference organizers often appreciate when community members approach them offering to bring interesting people to their attention. They might even help you with the budget!
- Then approach a couple of the most prolific core members of a cabal of your choice, asking them if they would be interested in traveling to a distant country for some food, drink and hacking. Make sure to do this well in advance, at least six months, preferably 12.
You should now have a list of core participants. Make a very preliminary budget. It should include expenses for travel and hotel for your most wanted participants, and perhaps some of the “bonus” people if possible. It helps to keep down expenses, if some of the participants don’t mind sleeping on a couch, it means you might afford buying air fare for someone who lives further away. Also remember to add the following points to your budget:
- If they seem interested, ask them for a list of people they would like to meet at the hackathon. After receiving a couple of these lists, tally them up to see who should be contacted next. If you ask for a ranked list, it’ll be easier to figure out who to talk with in the beginning. Also, remember to tell them what your intentions with the list is – to find out who to help with funding first. When they’re giving you their list, they’re in fact pointing at someone they would like to meet and saying “these are the guys I’d like to help come to the hackathon”.
- Keep adding votes to your tally (having a spreadsheet to calculate this helps a lot), and keep on contacting the “most wanted” people, until you can see that your list stabilizes. At this point, you have a good idea about who you should make an extra effort for getting to the hackathon.
- For bonus points, contact each of the people on the list (or at least a couple of the “most wanted” ones) and ask if there are anyone outside the cabal that they would consider inviting. This might include academics, active newcomers to the community, experts in some related but important field, or people they have some other good experience working with. Add these to the list, and try to get them to come too, if you can.
- And most importantly, get commitments from the participants. They should be willing to publicly say “If you can manage to organize $event, I’ll come. In any case, I’ll put your $event in my calendar.”
The next task is to find funding. Having a budget ready helps, but you also need a good idea about any issues that need to be addressed in the community. (For the Perl 6 hackathon, we tried to focus on issues around visibility, teaching and teachability.) Find some topic that your attendees “get” and agree with, but keep in mind that hackathons often have a life of their own. The theme or goal you find, should only be used a guide for the participants. The biggest value in a hackathon isn’t a good topic, but rather the fact that people who usually don’t meet in person get an opportunity to do so.
Write a public web page that describes the hackathon, goals, who you’ve invited, and anything else useful (make sure to keep it up to date).
Write a sponsor proposal describing the hackathon, it’s goals, who you have invited and who have confirmed. Send this to any companies, foundations or other institution that might want to help make this happen.
At this stage, it helps a lot if you have access to a good community network (e.g. an active Perl Mongers group) where other members can take the sponsorship request to their bosses. Knowing who to contact helps, and already having a relationship with them helps much more.
If you already have some funding (e.g. your Perl Mongers group has enough to help with an initial sum), then make sure to tell about it! Some people think about risk management, and like the idea that they’re not the only ones funding an event.
Then, get people excited. Talk with the attendees about what you’ll do, about the social events, and about how nice it’ll be to have a weekend full of hacking and fun. Bring the best you can offer. Do they have good beer nearby? Tell about it. Great food? Cool places to visit? Tell about it, and ask your attendees to blog about their plans and expectations.
Finally, make sure you have a clear idea about the necessary cut-off dates and deadlines. For final go/no-go, set the date at least 6 weeks before the hackathon. If you can’t find enough funding, or if there are some other reasons the hackathon has to be downscaled (or even canceled), make the decision as early as sensible, and certainly no later than the final go/no-go date. Also, if there is a risk of a change of plans, make sure to tell the attendees about this possibility as early as you can. Other deadlines you might consider:
- Venue expenses, if any.
- Food expenses. Lunch for everyone every day; And if you can, dinner. Also remember plenty of 40cm rotary debuggers.
- Snacks and fluids for the hackathon.
- In-city travel expenses, if attendees have their lodging somewhere outside walking distance of the venue.
- Travel expenses for those who come from far away. Include travel expenses from and to your local airport/train station.
- Hotel expenses for those who prefer this. Pick a reasonably cheap hotel with easy travel to the venue. Don’t go super-cheap, since a good day of hacking requires a good night of sleep.
- Add a small buffer for unexpected expenses. You can do this by liberally rounding up the other items in the budget, or by having a separate item for it.
Much of the preparations involve talking with people, making sure everyone knows what’s going on, and finding the right people and enough funding. Do your best to find help for this; especially if the hackathon is organized in your spare time. If you can’t find help, consider scaling down your ambitions, but beware that this might make the hackathon less appealing for both sponsors and attendees.
If you have managed to find a good theme for your hackathon, you might also consider preparing some activities related to it. A workshop, a demonstration or something else to get the attendees interested or excited about the theme. But don’t spend too much time preparing. Schedule it early in the hackathon, and try to make the attendees care about your issues in a positive way. If you do your job well, they’ll take your examples and points into account when they do their other tasks during the weekend. But in any case, treat these events as a “bonus” – Nice to have, but not necessary for creating a successful event.
- When can the attendees book the cheapest flights? Set a signup deadline 1-2 weeks before this (take holidays and weekends into account).
- When does the venue or hotel add cancellation fees? Set your sign-up or pre-pay deadlines accordingly, giving yourself one or two weeks for handling late signup or cancellations.
- When should you announce the different deadlines? Preferably a week or three before the deadline itself. Announcement deadlines are deadlines too!
We started off our pre-hackathon schedule with three days of courses with Damian Conway as the instructor. Thursday evening, Damian gave his awe-inspiring lecture about Quaquaversal Nanomachine Programming in Multiple topologically connected timespaces, and by then the first attendees were already in Oslo in order to see the talk and to start the hacking early. We ended Thursday evening with a few beers at the Schouskjelleren microbrewery. We were quite pleased that even a couple “regular” Oslo.pm people showed up, and not just the die-hard Perl 6 fans.
Friday, we managed to find the early-comers a meeting room so they could dive into their weekend tasks. By dinner time most of the attendees had arrived, and we met up at Amundsen Bryggeri & Spiseri for a nice three-course and socializing to formally start off the hackathon.
And to top it off, several had by this time already blogged about their expectations for the event.
Saturday started showing the first signs of something being not as it should. Salve overslept, and since he was the only one with access to the building, everyone had to wait for him to get to the venue and let them in.
Somehow this didn’t deter the hacking, and several of the attendees blogged later about what they spent their time on. Karl Rune and Jan organized lunch and we had tasty pizza for dinner later in the evening. The day ended late, but not before a few more managed to blog about what happened.
Sunday, Salve managed to get up early, so everyone managed to dive into the code without delay. Lunch was nice, and dinner at a cheap Viet restaurant Salve was fond of, and the evening was rounded off at the Schouskjelleren microbrewery with good discussions and tasty brews.
Monday, everyone was already home or at least on their way.
So, what went wrong? What could improve?
Our biggest loss was that Damian became sick and wasn’t present for most of the event. A major reason for organizing the hackathon at all was because Damian was in town, and we thought it would be great to gather some of the #perl6 regulars while he was on this side of the planet. There’s not much one can do about things like these, but I do have to admit organizing all this seemed a little wasteful when the “guest of honor” had to stay at the hotel to sleep off a cold.
Furthermore, we didn’t spend much time on topics related to the hackathon theme. The hope was to discuss and come up with novel ways of teaching Perl 6, but with Damian out of the loop, no-one pressed to make anything happen in this regard. Too bad.
The lunch was nice, but not everyone seemed prepared to make their own sandwiches. Maybe it’s worth trying catering next time? (Personally I loved the food, but then again I’m used to having lunches like this.)
Other than that, things went reasonably well. 13 people signed up and 14 showed up. We kept our expenses down, meaning we could cover dinner all three days and even a little beer with the food. Everyone but two people have been reimbursed for their expenses, and the last ones have been thoroughly reminded of this.
I think it’s safe to say that despite our setbacks, the hackathon went pretty well. Code was written, we had a good time, Perl 6 newbies learned new things and Perl 6 hackers got to meet face-to-face and discuss. Happy times!
Finally, I’d like to thank the sponsors of the hackathon. Without their help, this event would not be much less successful.
- NUUG Foundation
- Oslo Perl Mongers
- Jan Ingvoldstad