This is a work-in-progress guide to help event hosts plan, organize, and facilitate journalism hack day events. This guide will be built out with more details and examples, but all of the documentation will grow from this framework:
-
Define your goals. What do you want your hack day to accomplish? You can help answer that question by thinking about the purpose, theme, and audience of your event.
-
Do what you gotta do to have fun meeting those goals. The main thing to keep in mind is that once you have your goal defined, trust yourself that you know how to help your participants have fun and meet that goal. To that end, there are a ton of existing guides to help you figure out the details of how to actually manage the logistics of one of these events.
-
[Reportback.](#documentation-reporting back-and-follow-through) Close the loop. Did you meet your goals? Did you learn something from organizing the event? Share out what you learned.
So, a hack day. There are a lot of different perceptions of hack days. The typical view is that of mute hackers furiously typing at computers, fueled by caffeine and adrenaline and after 24 or 48 hours they emerge with a magical thing, built out of fury and sweat and lack of sleep. Those events happen, but your event may bear little resemblance to that, and that's perfectly fine. What should your event look like? It's helpful to think about these areas:
What do you want your hack day to accomplish? The answer to this question should motivate the rest of your work and how you engage with this guide. For a tech company, they may want a hack day to help spread the word about a new tool or API. Contrary to popular belief, the purpose of your hack day is unlikely to be to build a brand new widget whatsit from scratch. Some great, and realistic, purposes include: building a sense of community, building connections between teams, fostering a better understanding of the work other groups do.
In the process of achieving those goals, teams will do excellent work together and may even have a fancy new tool to show off at the end. But, it's useful to keep in mind that demos are not the end all be all of a hack day. You get to decide what you want to get done during the day you're organizing. And colleagues (like OpenNews!) are always available to help you talk through realistic expectation setting.
Part of that expectation setting is also setting some expectation. Leaving things completely open ended is no better than unrealistic ideas about the next whatsit.
Hack the news! Well, that's pretty broad. It can be helpful for you as an organizer and for participants to have a more specific event theme. It can be a particular topic, such as newsgaming, a question, a geographic area, a data set, it's really up to you. A more specific theme can help you focus recruitment for speakers and participants, and it helps direct the brainstorming for teams. You can also experiment with the theme. Random Hacks of Kindness for example, is pretty broad: hacking for social good, but every event includes partner organizations that come with ideas and data sets. It gives focus, but also allows for flexibility.
So who do you want to have at your event? You know the community you're organizing for best. You should be in touch with them as you're developing the purpose and theme for your event; then come the invitations. You probably have some people in mind who you'd love to have at your event. Invite them. It can be a good idea to get a core group of folks committed before you even publicly announce the date so you know ahead of time about possible conflicts and know for sure that you'll have some attendees.
You'll also probably want to do an open invitation. In thinking about the composition of your event overall, you'll want to consider three areas:
- Skills: The ratio of participants is a critical part of the success of a journalism hack day. A good ratio to aim for is 2 developers for every 1 journalist. Even for an event that is meant to appeal to journalists, this ratio helps ensure that teams will be able to work together in such a way that everyone is able to contribute and no team member is overtaxed. The more detail you can get about the skills of your attendees, the better. It's pretty common for there to be fewer designers/front-end devs than back-end devs. You may want a lot of data gurus at your event. Think about the skills you'll need for the types of projects teams will be working on, and build that into the event registration. You can manage the ratio of attendees by asking people to self identify when they register for the event, and monitoring the number of different participant types.
- Experience: If you're expecting a lot of new folks, be sure to also invite some more experienced folks and ask if they'd be willing to help in a mentor-type role. If you're expecting a lot of folks who regularly attend hack days, keep that in mind when developing the agenda for the day. The experience level with hack days, independent of skill level, can change how you approach designing your event.
- Enthusiasm: In thinking about the purpose of your event, what deliverables do you want? Why do participants want to attend your event? To work with a team they already know? To gain a skill? To meet new people? To save journalism? Getting to know what your community is enthusiastic about will also help shape the event.
You don't have to reinvent the wheel and you do not have to figure out all the minutiae yourself. What you need help with will vary depending on your organizing team's skillset. Your goal should be to have an event that meets the goals you and your community have laid out. You don't have to follow anyone else's definition of what a hack day is, but, if you want tips and suggestions, they abound:
- Mozilla's hack jam guide
- Hack Weekends Guide
- The Hack Day Manifesto
- check your local community for examples
- please suggest more examples
Also, don't get too wrapped up with the whole hack day thing. It's an event with people who want to have fun and do good work. That describes a lot of types of events. If you know that people love X type of food at every other event you've gone to but you've only ever seen pizza at hack days, order the food people love. You don't have to serve pizza and Red Bull. (Caffeine and carbs and sugar are popular hack day accessories though.)
You've read up on things and you have some ideas for your event. You should build an organizing team to plan and host the event. This team should have a minimum of two people. For journalism hack days, it's helpful to have one person who is really connected with the journalism community and one person who is connected to the technology community. Having people from both communities involved with organizing will be a huge help in terms of agenda setting and outreach. Beyond your main constituencies, it's helpful to have team members with particular skill sets such as outreach, logistics, fundraising, and day-of event facilitation. These don't all have to be different people, but a team with a variety of skillsets allows you to delegate tasks without any single organizer getting too overwhelmed.
Also, at least one of the organizers should have participated in a hack day before (preferably a few). The perspective of a hack day newcomer is super valuable, but it's good for at least one of the central organizers to have experience with the event style. Even if the event wasn't great, it probably still taught some lessons to inform your own organizing.
You gotta find a place and set a date. Where to hold the event? Where have you attended similar events? Contact the organizers of those events and see what suggestions they have. If possible, strike a sponsorship deal with the space so that you promote their space with your event details and they give you access to the space for free/low cost. Some good places to start looking for spaces:
- the companies of news orgs or tech companies
- coworking spaces, maybe you are a member of one
- universities
- community groups, libraries, nonprofits
You should start reaching out to possible event spaces early in your planning because they may have limited date availability that will affect when you can schedule your event. Also, you know your community best. Maybe there are tons of available spaces. Maybe event space is at a huge premium and will be a major cost for your event.
Note: The Hack Weekends Guide has a lot of great tips in considering spaces including network capacity, accessibility, security, etc. These considerations are even more important if you'll be the first ones to host an event like a hack day in a certain space. Some spaces sort of know the drill, but you can't assume that and will want to check in with the space hosts on a lot of details about the space to make sure it will work for your event.
How are you going to pay for the space and everything else you have planned? Sponsorships are the primary way hack days are paid for. Companies that care about what you do contribute some amount of money or in-kind donation of things like space and food to help you have a great event. Typically, in exchange, the company gets some acknowledgement on your event materials and a hearty shout out and thank you during your event. Sponsorships can get far more detailed and complex, but that's a decent starting place.
Who do you ask? Hopefully someone on your organizing committee already has this fundraising skill set. For most small scale event you'll want to ask local companies you know. You can ask your favorite coffee shop to donate the morning coffee. Ask a local web hosting company if they could contribute space. OpenNews offers sponsorship. Your local tech community might offer small grants.
Your main costs are likely to be food and space and luckily those are things that can be donated in-kind, which can often be a less intimidating thing to ask for than money. But you should also feel comfortable asking for money. Think about what a sponsor gets in exchange for supporting your event: How do the sponsor's goals align with your event's goals? How does a healthy journalism technology community benefit your sponsor? How has your loyalty to the local business benefited them in the past?
Fundraising is a huge area, and the source of a tremendous amount of anxiety. That's a big part of why OpenNews' sponsorships are so straightforward. What other questions about fundraising do you have?
Most events offer an open online registration via Eventbrite, Ticketleap, Brown Paper Tickets, or some similar service. Some events go the webform route, but the ticketing services offer some nice automated emails and sign up management tools that you might not have with a webform.
The sign-up technology you utilize is not nearly as important as what you put on the form.
- Tone: Again, direct this at your audience, but be aware, overly friendly or jokey registration pages can be alienating to some people, particularly new participants. Use clear, inclusive language.
- Details: Include all the relevant event details on this page: location, date, any procedure for accessing the venue, event theme, etc. Triple check that all of this information is correct. And then check it again.
- Participant types: You should ask people to self identify with their skill set. This will make it easy for you to track and control the proportion of different skill types at the event. Use clear, descriptive language of the participant types. Also, do include an "other" option for people who maybe fall into a few types or are unsure how to answer. You can always email people to clarify later.
- Contact info and additional questions: Most forms require name and email. Beyond that, it can be helpful to ask for organizational affiliation, Twitter handle, website, and other contact or identifying information. You may also want to ask things like "How did you hear about the event?" Be conscious of which questions are required and optional. It'd be a bummer if someone couldn't register for your event just cause they don't use Twitter.
Once you have an event registration page, you'll want to tell people about your event! You may also have a website and Twitter account just for your event. Someone on your organizing committee may have designed a nifty logo you can use to brand your event. Spread the word via whichever platforms your community uses most. Attend events in your community and ask if you can give a quick plug about your upcoming event.
A great way to promote your event can be through partnerships. Organizations in your community might be willing to cross list your event and suggest it to your members. Your event sponsors are also a great source of help promoting your event (and by extension their investment in your event!).
And, don't be shy: send individual, personalized emails. Invite people you meet at events. Person to person invitations, like for any event, is one of the single best ways to get people involved with your event. And hey, if that person can't make it, ask if they'll invite their network.
Also, reach out to national groups like the Online News Association that have events listings. And of course, let us know so we can add the event to the Source events listing.
People should be well fed throughout your entire event. Meals should be covered for every meal-time you have people at the event. I am still trying to figure out the appropriate estimate on how to order ahead for an event, so any suggestions on that equation, please do share. If you can afford it, ordering too much is preferable to ordering too little. You don't want people distracted by being hungry.
In addition to meals you should provide a steady stream of caffeine and sugar. Have coffee/tea (whatever your participants prefer) available at all times, and especially in the morning. Snacks are crucial, especially in the mid-afternoon slump. A nice assortment of junk food and nuts/fruit is ideal.
To dispel a common misconception about hack days: you are not required to offer prizes.
An enormous amount of organizing time and fundraising effort is often spent on chasing after prizes. Prizes are totally and completely optional. It is extraordinarily unlikely that people are attending your event with the prize as the sole motivator. It's probably not even a primary motivator. It's just not why people attend journalism hack days. Some other hack days are extremely focused on prizes, but these events are not. If you feel like you really need to offer prizes, make sure they can be shared by a team (good luck cutting an iPad in five parts) and keep them practical. Maybe your sponsors would like to offer a license for one of their services. Maybe winners could cowork with a local news development team for a day. You can get creative, but really, go back to what your goals are for your event. Are you goals served by prizes? If so, what should those prizes look like?
Planning the program can be tricky. Are people going to be heads down working? Will participants be working with a new tool or data set that requires training? Are there exciting developments in your community you'd like to tell people about to get them motivated for the weekend? Maybe you'd like to close with a speaker that will issue a motivating call to action for next steps. Speakers are not required as part of the program, but think about if they will help you meet your goals.
Once you get everyone in one physical location, how will they be completing their work? Will everyone bring their own laptop? Can you have data sets pre-downloaded? Will people have the appropriate development environment for the project they choose to work on? Will they need hosting support? Are they familiar with git and github? This should already be known because you checked with the space host, but, will the wireless actually work?
This is one of those areas that seems to be different for every event. Definitely looking for more tips/suggestions here. Seems like a lot could be dealt with beforehand or early in the event, and yet it often comes as a surprise.
Home/SOHO offices WIFI routers tend to collapse when too many devices are connected to it. If your budget allows it, buy ethernet hubs and cables (cheap 8 ports switches handle the load better that the wireless networks). If your budget doesn't, ask the participants if they can bring their wired equipements.
Obviously, face to face is a key benefit of a hackathon. However, we found that it works quite well to add written tools to the mix:
- an IRC channel. You can create one on freenode is a convenient way to notify participants in an unobstrutive way (pizza are delivered, does someone know how to do XY?...). It also helps keeping a log of the discussions. Useful if one participant takes a break and wants to know what has happened when he/she slept
- etherpad/google doc Document/FAQ. For instance if you work on a common dataset, information about the structure, tips on how to use command line tools to search and extract...
The precise timing of the agenda will vary depending on the type of event. But here is the basic flow:
- Informal introductions - people need to meet each other. This often happens casually offer pizza or coffee as people begin to filter into the event. Build in some time for people to get in, get settled.
- Welcome and expectation setting - the facilitator should go over the goals of the event and the general expectations for participants.
- Formal introductions - participants should introduce themselves in a quick ice breaker to help people get to know each other, their interests, skills, and something fun.
- Ideation - you want to get the project ideas out there. This phase can take a lot of different forms, but basically you want to allow everyone with an idea to share it and put it down on paper/white board.
- Project formation - idea pitchers should lead discussion of their idea, and other participants should check out the available ideas. The facilitator will help guide this process, which might involve combining ideas, redirecting people with certain skills to certain projects to give feedback, etc. This can be very tricky
- Team formation - once the projects are narrowed down, the teams should start to form (this can happen concurrently). A really good project idea might turn out not to have enough team members interested and that's fine. At the end of this step, everyone should be on a team, and begin working on a project idea.
- A great pre-planning tip: when possible, pre-formed or mostly pre-formed teams can have a big head start coming into events.
- WORK - go team! Event organizers should be on-hand to help field questions and offer support, but teams should be given a giant chunk of time to just work.
- Check in - after several hours/at the end of the day there should be some sort of formal check in. This can be a go-round from the teams themselves. Another less disruptive approach is for an event organizer to go around and interview teams with a set of questions and upload the answers to a wiki/etherpad. It's important for there to be some sort of documentation of work that the teams are doing.
- More work - teams should keep working, with regular updates about how much time is left during the event.
- Demo - teams should share their work! This can also take many forms. The traditional format is a series of PowerPoint presentations, but that's not the only option. A science fair style approach can be fun.
- Wrapup/next steps - the event facilitator should close out the event with lots of excitement, appreciation, and "job well done"s as well as description of any next steps.
On the event day, it's good to have different people filling different roles. The most critical roles:
- Event facilitator - this person leads the opening and expectation setting and sets the tone for the entire event. This person should be comfortable talking with groups and able to monitor the event and judge when to intervene to help out a team or adjust the agenda.
- Facilitator sidekick - the facilitator needs a point person helper. This person should be available to follow up on issues for the facilitator and deal with logistical items such as organizing food, clean up, etc as necessary. This person can also serve as the documenter-in-chief helping teams document their projects as well as taking photos and keeping track of the event for the organizers.
- Tech expert - you'll want at least one of these people who can field questions, help people get their laptops set up, deal with issues, and generally just provide the comfort that there is a point person with tech skills so participants know there is someone they can go to for help. If you're working with particular APIs or technologies at your event, this person should be skilled in those.
- Enthusiasm ringer - this can be a participant, but I think it helps to have someone who is just SO EXCITED TO BE THERE and they are able to convey that energy in a way that is infectious and not annoying.
- others?
Facilitation can be really hard. It can. It doesn't come naturally to everyone. It takes a while to learn how to read and respond to a crowd. If you've been involved with your community for a long time, you already have a head start cause you are familiar with the people at your event. Great.
Through Mozilla, I've been lucky enough to learn from Gunner (Allen Gunn of Aspiration Tech) who is just a phenomenal event facilitator. A few things I've picked up from him about how he sets the tone at the beginning of the event.
- He starts by laying out the purpose and expectations for the event with an enthusiasm that feels genuine.
- He reviews shared rules (which he himself also follows):
- Respect time and schedule - we will all be aware of the schedule and not waste or impose on each other's time
- Respect communication - we will be mindful of vocabulary by avoiding use of jargon and defining terms when they arise
- Rule of one, rule of n - each person should speak 1/nth of the time. Find yourself talking more? Step back. Talking less? Step up. The rules are simple, straightforward, and all oriented toward respect and inclusion of all participants. It sets the perfect tone.
- He monitors the event and intervenes when a team seems to need assistance or redirection. He also reads the crowd and adjusts the schedule as necessary to respond to energy levels/engagement.
These are all tactics that anyone can use. Treating people with respect and expecting the same from them goes an awful long way.
In addition to facilitation, it can be helpful to have an event code of conduct. The Python Conference has a great example.
Another thing to consider is privacy. Ask people if they want their picture taken. This can be a question in registration or something you deal with on the event day.
Codes of conduct are great because you have a description of what you'll do if an issue arises (however unlikely you may believe that to be). They also have the added benefit of showing participants that you're thinking about conduct, privacy, and safety, which is a great thing convey.
Congratulations, you held your event! You should tell everyone about it. During the event itself, you should have created some mechanism for teams to track their projects (a wiki, etherpad, github, hackdash).
After the event, write a post about how it went so that the community can learn from you. Examples include:
- HackJersey
- Hacks for Democracy
- Knight Lab
- Add yours here
Depending on the goal of your event, you might have some follow up project nights. You might have a reportback at the next Hacks/Hackers chapter meeting in your city. Leave your event participants with some options for next steps so they can stay engaged.
How can we help with your events? But also, how can this doc be improved? Some things I know I want to build out:
- info about open space technology format (h/t @LizBarry from TransparencyCamp 13)
- more examples
- more about the role hack days play in the community engagement and project development pipelines
- more about additional events related to said pipeline
- more about what logistics people want help with
- formatting. These are so many words, how to make readable?
Lots of links above to be compiled (and added to) here.
This guide is inspired by Singly's Ultimate Guide to Hack Weekends and h/t to CaptainCalliope for suggesting it.
The crowd at the hack day session at TransparencyCamp13 really helped me push through and finish the first long draft of this on the train back to Philly. Thanks!
Many more credits to come.
I work for OpenNews. We provide sponsorships to folks organizing hack days that work on real-world journalism problems. A lot of people, all over the world, are interested in holding events that bring together journalists, developers, designers, data specialists, and other folks excited about technology and journalism. This guide is meant to help organizers of events plan, execute, and document their hack days. Please contribute suggestions and contact OpenNews if you'd like to host an event.
OpenNews sponsors a lot of hack days. We do that to support awesome events. Some things we ask of event organizers:
- credit us as a sponsor (just ask for logos or any other files you need)
- tell us about your attendees: who attended? how many people?
- tell us about the projects: what got built? how many projects? links, please
- tell us about the experience: join a community call, forwarded us your debrief blog post to circulate, and if you have some noteworthy takeaways, tell Source about it.
- Contribute to this repo.
- Find me on Twitter @erika_owens
- Email: erika@mozillafoundation.org
These are some examples with a few thoughts on each format. Pick the one that seems like it'll meet your needs and is feasible with the level of planning/financial support you have.
- Typically a full-day, weekend event. Sometimes with a couple hour evening meet and greet the night before.
- Great for community-focused events, first timers, and events with limited time.
- Not as great for actually building stuff. In a day, after groups form, problems are identified, there just isn't that much time to actually get to the hacking part of the day.
- Good option when people might commute a fair distance for the event, but not have funds for hotel.
- Probably the most common hack day format. Full-days on Saturday and Sunday, sometimes with an evening pre-event on Friday.
- Wide variation in what it means to take up the entire weekend. Some events follow a semi-work day, some events are 48-hours of hack hack hacking.
- Can be extremely taxing on the organizing group, especially if the event goes overnight.
- Weekend is a good amount of time to make progress on a project and get it to a point where a team can decide if they'll keep at it after the hack day or let it go.
- Weekend can strain teams that aren't in the best shape. A day is over before it begins, but a weekend can really drag if the team doesn't gel/can't pick a topic/doesn't have a good mix of skills to delegate tasks.
- Most events are completely open to the public. You should personally invite some folks, but most events also have an open call.
- Great for building connections across different groups.
- Can be a great way for an organization to show off its space, its ideas, its leadership, etc.
- There can be a lot of unknowns, and the events require close watch of event registrations to make sure it's a good mix of folks.
- Requires a critical mass of community members. Ideally, a hack day happens after a series of other events that have established interest from developers and journalists in the local community. It's tremendously difficult to pull of an event in an area without an existing community to support, and participate, in the efforts.
- Can be a great way to spark leadership interest and demonstrate cross-team collaboration.
- Lots of great examples from outside of journalism, but increasingly within journalism as well, NYC, NPR, WNYC, Boston Globe etc
- Can be a way to test out and gauge interest in larger events and foster buy-in for a public event.
- Often takes place during the work day, on a single weekday.
- Some organizations host events that are primarily attended by staff, but also open to the public.
- Can be a good way to ensure that there is a baseline of participants
- Can be great way to get news org connected to broader community, and help community learn more about news org.
- Sometimes encounters sticky issues of who owns a story
- Some events take place in several cities at the same time, RHoK, Developing Latin America, etc.
- Gives chance for people in many places to participate, but can be logistically very challenging.
- TechCamps - weekend event with neat mix of teaching/learning with hacking
- Editors' Labs - weekend event, also, mix "master class" sessions with hands-on hacking
- AOP Hack Day - look at my notes
- Open Data Day - a scrape-a-thon
- Documentation-a-thon
- Start-a-thon
- SEPTA hack days, topical themes.
- add more examples and links
Note: Remote assistance. Sometimes, a team has a question that no one physically present can answer. Or a team member can only participate in person for part of the event. Or someone wants to join in, but can't make it to the space. Some events are experimenting with having more remote participants. These participants can help a ton in a pinch -- connecting via Twitter, IRC, email, sometimes even Skype -- but it can make the community building aspect of a hack day more challenging. If it seems that a lot of participants won't be able to attend in person, look at if a different day or style of event might be better. Participants don't have to sign their lives away for a weekend, but there is definitely a sense of camaraderie that comes from working with a group at the same table for hours on end.