Post-hackathon recap

Picking a place

We went for cheap this time out. For all we knew, it would be Andy, Pete and Chip sitting around scratching our butts. Our only real requirements were:

Wifi

Meeting room near sleeping rooms

Relatively inexpensive

Near commerce, preferably including a 24-hour store

Able to bring in our own food

We were out in far northwest suburban Crystal Lake, which may have been harder to get to, but we wouldn't have been to get $79 any closer to the city. We also were not interested in having a lot of other interesting things in the area, since the goal was to have people working on code.

When we got down to it, we found that there was no Ethernet in the walls, and for the one guy with a laptop without wifi, Pete had to route his Internet traffic to a hub for him. Having the ability to get on the network through a jack would have been a big win, both for that guy, and to have alternate, backup WAPs.

The BYOfood requirement was the first thing on our minds, because we'd gotten in trouble at YAPC::NA 2006 for bringing in our own pizza & snacks, because Sodhexo cornered the IIT food market. They were pretty upset with us. This excluded the local Holiday Inn.

Continuous space usage was important. Losing out Sunday morning, to a long-standing church group, meant fewer people showed up. We wound up clustered in the breakfast nook and around the pool with laptops waiting for our space to become free again. More people may have shown up Sunday had our space been available the entire time. Still, we had until 6am on Sunday to use the space, and we were in there until 2am.

Not having a VGA projector was a problem, leaving Ken Krugler scrambling to get one a few hours before his presentation. We should have been more explicit that he would need to supply one if he needed it, since we were doing no presentations. Turns out the hotel thought we meant an "overhead projector" and not a "laptop projector" in our discussions.

More than the presentations, it would have been good if people working on projects could have had a common screen to work, or to do demonstrations to the groups. Also worthwhile would have been the social aspects of showing movies when hacking was done for the night.

When people actually show up

You can't plan for everything. Power outage, thunderstorm, etc.

Dinner by democracy works to a point - 12 Chinese dishes was OK, but 3 thin and 8 pan pizzas was about 3 pans too many. (If we had paid for the pizzas, it might have been a bigger issue.)

Always be sure to have labels, both for humans and their belongings. We emptied my labelmaker, and the corny "Hello My Name Is" tags were indispensable when we had 30 people clustered around six tables on Saturday night.

Having defined start/stop times might have been helpful, so people knew when to show up.

There were a handful of people who came in and said "How can I help? Who do I talk to?" Next time, project owners should have very specific, bite-sized tasks that people can work on as soon as they walk in the door. If possible, those tasks should cover a range of skill levels.

Snacks were purchased as needed. This helped cut down on waste (although there is quite a bit left over) at the expense of lower food costs, because they weren't bought from Costco or Sam's Club. If a good store is nearby, get some basics and let people decide what else they want. (We spent less on snacks at this hackathon than at the one after YAPC.) The key is, we bought small at first, and bought more later.

Location

Public transit wasn't as good at this location, so Andy and Pete did a lot of shuttling people around. (For that matter, we did a lot of not shuttling people around as communications got crossed.) The jury is out as to whether this was good or bad, as it removed more distractions and kept people together and hacking.

We didn't make explicitly clear in the site that people should fly into O'Hare. All our discussions of getting to the hotel assumed that people would fly into O'Hare, and not Midway. Since Midway is served by a number of low-cost airlines, a few people went through Midway and had a much harder time getting out to Crystal Lake than they should have. This was aggravated by the bad weather Thursday and Friday.

Try and line up taxi recommendations for next time. If people can cluster arrival or departure, a $90 taxi among 3-4 people may be better than wasting 2-3 extra hours with public transit.

Projects

Have a focus, but don't force people to do it. If someone comes into the room, be able to answer the question, "What can I do to help?"

Be able to introduce a newbie and have them help right away. We had more new people contributing to Parrot during the hackathon than established programmers.

Don't be afraid to vocalize questions. "Does anyone know X" will often get a couple bites. Jim Keenan specifically mentioned how free he felt to collaborate and ask "dumb" questions of the group. Bill says he's heard it from half a dozen people.

Have one or two status/boasting meetings. Let people discuss what they've done and what they still need to do. Aggregating status and success highlights all the work being done. Showing successes after the hackathon is crucial, both for future energy and future sponsors, so do not neglect this.

People won't use a central wiki unless you keep poking them, and then they'll do it just to stop the poking. Pete wound up taking most of the attendance, and the major portion of the successes page came from Saturday night's meeting. HOWEVER, the Wiki was invaluable in prepping projects and people for the weekend.

It helped having different tables designated, with signs, for which projects they were devoted to. There was a Perl::Critic table and three Parrot tables.

As the day wore on, there was more tendency for people to break into smaller groups.

There was a perception among many before that the hackathon was all Perl 6. We need to make sure that it's understood to be about any Perl project.

A lot of people wound up working on Parrot than we expected. There were six Parrot folks at the start of the hackathon, and fourteen when it was over.

chromatic's oreillynet article

The Perl community is not new to hackathons; the Pugs hackathon in Toronto in 2005 before YAPC::NA is one of the best known. However, most of these sprints took place before or after conferences: OSCON, YAPC, et cetera.

I went to the Chicago Perl Hackathon this past weekend. Barring some troubles during the trip, it went flawlessly.

The organizers, Andy Lester and Pete Krawczyk, found a small hotel in a little town outside of the Chicago suburbs. It was accessible from public transportation, had a small conference room for us, and was within walking distance of a handful of restaurants.

Better yet, we had tables, chairs, wifi, electricity, and snacks.

Though there were a few out of towners (a couple of us from Portland, two from Seattle, a couple of people from California, two from New York City, and one from the UK), most of the attendees were from the midwest. This was a goal, and it was a great help. The total attendance was somewhere around thirty people.

Two projects dominated the event. One was the Perl::Critic project. Several attendeed squashed bugs, refined policies, and improved one of the most useful software development tools I’ve used in years.

The biggest success may have been for the Parrot project, however. Six of the attendees were Parrot contributors before the weekend started (including your author) and by the end of Saturday night, we had added eight more contributors.

I spent the weekend fixing broken tests in Parrot, and had the time to add a couple of new features. (My big goal — fixing Parrot::Embed on non-Unix platforms — didn’t quite happen, but Jerry Gay and I did track down some of the problems.) This cleaning was necessary for Chip Salzenberg (also in attendance) to release Parrot 0.4.7, codename “Caique”. We also took advantage of being in person to discuss some weighty design issues related to our object system. Unfortunately, three of the core Parrot developers couldn’t be there, but we caught up on IRC with Leo Toetsch and Patrick Michaud.

Was it a success? By all means! The best part was sitting down with people who’d never touched Parrot before and walking through adding a new feature or fixing a bug. For example, Jerry and I helped Jim Keenan compile Parrot for the first time. He’d found a bug in our configuration process. Though Jerry and I both recognized the error (being very much too familiar with compiling Parrot), walking Jim through the fix on his own virtually would have taken a lot of time. It went much faster in person, and now Jim is providing patches to related build files.

If you ask any of the other attendees, you’ll hear similar stories – especially, I hope, from people new to a project. A few people dropped by for a few hours without any particular plans, just hoping that they could contribute to something.

To me, that’s the real goal of a hackathon. I’m very proud of the work we’ve done on the Parrot release, but I’m even prouder that we helped eight more people contribute to Parrot. Maybe some of them will never contribute again, and that’s okay. Maybe some of them will continue to produce good patches and even become committers. I’d like that a lot.

However, each of them tried something new and contributed to a project that’s bigger than any single person. All of the developers of the project are better for their work, and all of the current and future users of the project benefit too. You can, of course, start to contribute to almost any free software project without ever leaving your house, but if it takes flying halfway across the country in wild weather and giving up a weekend every now and then to help someone else make that jump, I think it’s well worth it.

TPF, how about a west coast hackathon sometime early next year? Portland’s nice.

Andy & Pete: Thanks again for your efforts in organizing the Chicago Perl Hackathon. When you get a chance, I'd like to learn more about the financial costs of putting the hackathon on. I'd like to help organize one in the Northeast but will need to know the cost structure first.