Last Saturday, a handful of people from the Cape Town Front-end Developer meetup group got together to hack on the WordPress-based site for local NGO Rape Crisis Cape Town Trust. We ran into some pretty major stumbling blocks, and we didn’t get nearly as much done as we hoped. We did learn a lot, though, and we’re hoping do another hackathon soon to really get some improvements to the site done.
What went well
We set up a git repository and hosted it on GitHub. This let us take advantage of the team workflow features like Pull Requests that are really helpful when a group of people are working on different feature of the same code base.
After some fiddling with sticky notes and felt tip pens, in true developer style, we started using GitHub issues to track the things we wanted to do. This worked well, and let us pick up tasks that fit our mix of skills.
The format of the hackathon felt right: one day, lots of coffee, pizza for lunch, and a mix of developers. We’ll probably repeat that format for the next one.
What didn’t go so well
We didn’t do any preparation work before the hackathon. Our goal, broadly speaking, was to take the site’s existing Theme and make improvements and adjustments to it to bring it more inline with the Mobile First Responsive principles that we strive for in our code. When we started digging into the code of the current WordPress Theme, Headway, it started to become clear that that would be difficult to do, especially in the one day that we had.
Headway is designed to be used by people who don’t want to see the code: it offers a drag and drop, visual editor, approach to building the site. Being developers, that was the opposite of what we wanted!
After a lot of discussion, we decided that the best course of action would be to build a new Theme from scratch, including a solid workflow using the JavaScript task runner Grunt, and a Front-end Style Guide. We decided this was out of scope for the day, but that it would make a great project for the next one. We decided to see what we could do to the existing Theme during the rest of the day.
What we’d do differently next time
We spent a fair amount of time figuring out what we wanted to do, and how we were going to do it. Our biggest failure was that we spent a large amount of time poking at the Theme confirming that we couldn’t do what we wanted to.
We could have avoided this time sink by having a few of us doing a bit of prep work in advance. We’ll try and do this for the next one: it would make sense for us to set up an issue list and tasks to be done before the workshop so that we could concentrate on the doing rather than just the planning.