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).