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).
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.
Do you like this blog post and need help with Next Generation Software Engineering, Platform Engineering or Blockchain & Smart Contracts? Contact us.