Skip to content

Rape Crisis Hackathon

Some Front-end developers coding

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.

A list of the GitHub issues

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.

Nope packages installing

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.