Share this

Last Wednesday (June 6, 2018), I ran a Haskell Hackathon after LambdaConf. The turnout certainly wasn't the same as Zurihac, but I was quite happy with the crowd, the participation, and the interactions.

I wanted to share a bit of how we ran this hackathon, why I liked it so much, some ideas that got brought up, and my hopes for future such events.

How it worked

The keyword for this hackathon was informal. There were no official planned talks, though we did end up having some impromptu lightning talks. People were of course free to work on any project or tasks they felt like; a few people even snuck in some Rust. But the general idea was:

  • I prepared a list of issues on a few different open source projects (see the haskell-hackathon repo)
  • People “staked claimed” in issues they wanted to work on
  • Lots of pair programming, giving people a chance to learn from each other
  • I tried to help people understand the projects, and generally be as helpful as possible

I'd hoped that others in the community would submit some issues to be worked on. In the end, all of the issues came from me, and ended up being fairly Stack-heavy. We ended up having 12 issues total, of which almost all of them were worked on at the hackathon.

The positives

I was really impressed with how enthusiastic and ambitious the participants were. I wasn't sure if a big project like Stack would be too intimidating. Quite the contrary; I wish I had scoured the Stack issue tracker a bit harder to find more newcomer-friendly issues. Even issues that I'd marked as fairly challenging ended up getting picked up and resolved.

It seemed to me that the combination of easy pair programming to work through tough problems, plus having someone (me) well versed in the codebase available to help if needed, really gave people a chance to try something new. And (again, to me) people really liked getting a chance to contribute something significant to a real world project used by so many people.

Another positive: there were people of various skill levels present. Even people who weren't ready to dive into advanced issues themselves were happy to sit over someone else's shoulder and observe. I also got to learn some new techniques from this (I'd somehow completely missed the git grep command). One person spent significant time helping someone newer to coding get up-and-running with Vim (objectively the greatest editor ever created, of course).

All in all, I had a great time at this hackathon, and enjoyed interacting with everyone. It seemed like the other participants felt the same way. Many thanks to everyone who attended, and to the LambdaConf organizers and volunteers for taking care of all of the logistics.

Improving Stack maintainership

Since Stack was being worked on by so many people, we started discussing some aspects of its maintenance. I'll probably have some more blog posts on this in the future, but I wanted to bootstrap some of the public discussion with my notes here:

  • Matt Audesse, one of the Stack issue triagers, opened a pull request introducing some more formal structure around Stack maintenance. This is based on some offline conversations among Stack maintainers, and some docs that I wrote. If people are interested in contributing more significantly to Stack, that's a good place to start: review the PR, add some comments, and consider volunteering to be a Stack issue triager or some other role.

  • One open question in that PR is how to handle triaging of old issues. A common approach used by open source projects is to automatically close issues that haven't seen activity in a certain time via a bot. There was a strong push at the hackathon to make this happen. It's likely that we'll start a more serious discussion in the issue tracker about this.

  • As my previous personal blog post stated, I'm worried about the bus factor on some projects, including Stack. There are parts of the codebase that only a few people (and sometimes only one) truly understand. I'd like to be more proactive about solving that problem, but it's going to require people diving in and really getting their hands dirty. The best example of this is the issue I opened about improving SourceMaps and buildplans.

If any of this interests you, please consider joining our Gitter channel. There are multiple people available—myself certainly included—who would be happy to help mentor someone into getting more involved in the codebase, whether at a hackathon or remotely. Speaking of which…

Future events/next steps

I'd definitely like to do more such low-key hackathons again in the future. The focus on pair programming, providing some tasks from real projects, and encouraging people to work on their own interests seems to be a great fit. I can also picture a two day event, with day one being some training sessions and day two being a hackathon to practice those new skills, working out really well.

If anyone out there is interested in doing something like this in your area, please let me know. I'd arrange one in my home town, but I think I'm the only functional programmer in a 10km radius :(. I'd also like to see if some kind of remote setup could work for something like this, either fully remote (everyone's working from home with some open audio chat) or semi-remote (multiple teams in different places).