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.
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’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.
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.
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…
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).
Subscribe to our blog via email
Email subscriptions come from our Atom feed and are handled by Blogtrottr. You will only receive notifications of blog posts, and can unsubscribe any time.
