So you want to organise a hack day?
These are based on my experience of organising SusHack in 2013 and 2014. For more information about SusHack, check out https://sushack.github.io
Overview
- What is the cause/purpose of your hack day?
- What will you call your hack day?
- Who can sponsor your hack day?
- Where will you host your hack day?
- How can you promote your hack day?
- Preparing for the day itself
- After the hack day
- Useful information from others
What is the cause/purpose of your hack day?
Having a cause/purpose isn’t necessary, but it can be useful to get the right kind of participants, the right kind of sponsorship, and the right channels to promote your hack day.
With SusHack, we went with theme of a “Sustainability Hack day” – something that didn’t already exist in Oxford, and so filled a niche.
We had participants and support from various “green” groups around Oxford and the South.
Due to the sustainability theme, we received sponsorship from my employer 2degrees (http://2degreesnetwork.com). I’ll talk more about what they provided as sponsorship later.
If you intend to hold your hack day at your employer’s office, it might be important to get some buy-in, if you want to have the support to use the office on a Saturday with a bunch of strangers.
What will you call your hack day?
The name isn’t that important, so long as it’s clear and memorable. The name “SusHack” is clearly an amalgamation of “Sustainable” and “Hack”.
You could incorporate the location in the name of your hack day (e.g. SusHack Oxford), but if your hack day is a resounding success and you wish to expand it beyond the original location, this name might not scale well.
If you’re using the format of an existing established hack day, then it’s cool to go with their naming convention, e.g. “Design Jam Oxford” for a Design Jam held in Oxford.
Who can sponsor your hack day?
- Your employer if they can provide space, wifi, etc.
- Github provide sponsorship for hack days, so take a look at https://community.github.com/
- Local takeaway/restaurants might be willing to give you discount as you’ll - most likely be doing a large order for them if you’re providing lunch
- If you’ve got a local Starbucks, you can talk to the branch manager and see about getting some sponsorship from them – generally at the discretion of the manager, they can provide enough coffee for all of your attendees, for free.
With SusHack we had the following sponsors:
| 2degrees | location, wifi, refreshments, breakfast pastries, lunch |
| Starbucks | coffee |
| Github | T-shirts, stickers, promo codes |
| Mission Burrito | discount code for our bulk lunch order |
| Love Hz | Prizes (books, devkits, etc.) for the second SusHack, because the first SusHack was targeted specifically at helping them launch their “Oxford Flood Network” |
Where will you host your hack day?
As I mentioned before, we used the office space of my employer to host SusHack on both occasions, this meant having access to the office on a Saturday.
If you go down the route of using your office space, you’ll need to make sure that any sensitive information is put away, that people clear the mess from their desks the day before, and that you’ve got somebody who can represent the business there.
You’ll need to go over the fire drill for the building, and ensure that the office is kept secure as your attendees will all have their valuable computers with them, and you don’t want somebody to just walk in and take things.
It’s a good idea to use lanyrd.com, eventbrite.com, meetup.com or your own attendee system, to keep a track of expected numbers and who you’re expecting to show on the day.
How can you promote your hack day?
First of all you could create a website. Github pages is a great place to host a (fairly) static site for free. You can use Jekyll to provide some sort of templating functionality.
If you’ve got a domain, you can use it with Github pages.
https://help.github.com/articles/setting-up-a-custom-domain-with-github-pages/
If you don’t want to create a full site, then lanyrd, eventbrite and meetup will let you post some basic information about your hack day.
When you setup your hack day, it’s worth creating an associated Twitter account so that you can inform people from one location rather than a personal Twitter account.
If you want to keep your potential attendees informed about plans, remind them about the day as it approaches, etc. You can use Mail Chimp to send out newsletters for free.
On the day itself, it’s worth using a hashtag on Twitter to keep all associated tweets together, and also worth periodically tweeting pictures, and information about what’s going on.
Preparing for the day itself
Before the hack day you might want to collect project ideas from potential attendees, to save time in the morning.
Have a whiteboard or flipchart and plenty of pens available so that people can contribute to a list of ideas.
Have plenty of space for attendees to organise in to teams around their project ideas.
Have plenty of Ethernet ports and power sockets available, and optionally Wi-fi. If it’s the company wi-fi you’re using, you might want an isolated subnet as the attendees are from outside of the company.
If you want people to be able to communicate from their computers, it’s worth setting up a channel on IRC (such as irc.freenode.net) so that you can easily share links, etc.
After the hack day
This is where you promote the successes (and failures!) of the day. Get attendees to blog about it, tweet their blog posts, retweet them from the main hack day Twitter account, get your company Twitter account to publicise that they were involved, etc.
If your projects are open source and hosted on Github, then encourage people to continue working on them.
Get thinking about the next hack day.
Useful information from others
Here are some links that were very useful when organising SusHack
- http://hackdaymanifesto.com/
- https://about.futurelearn.com/blog/run-internal-hackday/
- http://globaldev.co.uk/2012/04/how-to-run-a-hack-day/
- http://startupcafe.co.uk/2011/04/22/top-7-tips-on-running-a-hackdayweekend/
- https://jcp.org/aboutJava/communityprocess/community/How_to_run_a_Hackday.pdf
- http://blog.podio.com/2014/06/04/in-praise-of-hack-days/
Related posts
- Making GIMP feel less like punishment
GIMP has always had an interface problem. I’m not blaming the GIMP team (they’ve built something powerful on a shoestring). They’ve been clear they’re not interested in copying Photoshop wholesale; their FAQ argues that designing around actual user research beats imitating someone else’s interface decisions. Fair enough in principle, but coming from years as a Photoshop user, that design still feels hostile to me. I’m just one user story out of many they’ve had to design for, but it still expects me to learn its own way of doing things rather than offering a config closer to what I’m used to out of the box.
- Running a Tailscale exit node in a local VM
I run Tailscale on my laptops, phone and NAS, and wanted to add an exit node so I could route traffic through my own connection when I’m out and about. The obvious place to put it was the NAS, since it’s already always on, but the NAS also holds everything I’d least like exposed if something went wrong. Making it double up as an exit node, with every device’s outbound traffic flowing through it, didn’t sit right. What I wanted instead was a disposable, isolated VM living on the same machine doing that job, leaving the NAS untouched.
- Merge Commits Are Just Noise
Run git log --graph on most team projects and you’ll see the problem. Parallel lines everywhere, merge commits that just say “Merge branch ‘feature/x’ into develop”. None of it useful. It’s noise. I’ve been using a rebase-based workflow for years to avoid this. The history stays linear and the diffs stay readable. This post covers both the argument and the specific branch structure I use for team feature work.
Discussion
No interactions yet
Comments are closed
You can still reply from your own site with a Webmention.
