Written with Pablo Rey Mazón
A day before Hurricane Sandy touched down, netizens began to congregate via etherpads, Google Docs and IRC, assuming the name “HurricaneHackers.”
HurricaneHackers teamed up with Sandy CrisisCamps—a series of hackathons organized by CrisisCommons around the world—to host a hackathon at MIT Media Lab. About 30 participants worked together throughout the day to figure out how a remote set of volunteers could support Sandy relief with communication technologies.
Pablo and Denise were the main facilitators for the hackathon. With Pablo’s experience organizing OccupyData hackathons and Denise’s participation in hackathons, we knew that a common gathering place is powerful for imaginative and holistic thinking, and to matchmake that thinking with real world needs.
Hackathon team projects
A crucial difference between OccupyData and HurricaneHackers was the urgency of a crisis. Participants wanted to help existing projects without duplicating efforts. We rallied around a few of the official requests that CrisisCommons had documented, which resulted in two projects:
InnCrisis – Based on a request to determine hotel room availability as well as conversations in IRC with other SandyCrisis netizens, this team brainstormed how people with hotel loyalty points could donate their points to those who needed medium-term housing. After several hours researching legal precedents and getting in touch with official requesters, hotel loyalists and hotel PR, “we decided that the goals below were too ambitious to handle with the solutions and workflows we were designing towards, and so InnCrisis is presently paused.”- Needs assessments – Synthesizing several requests, this team forked into two projects: rapid needs assessment for first responders such as the Red Cross and long-term needs assessment for parties such as FEMA and shelters. By the end of the hackathon, they presented a tool that, “given a list of phone numbers and locations, [it will] feed into an application to call [survivors] automatically to determine if they have phone service, if they have power, etc”
Not finding a good fit with her skills and interests in any of the projects, Mayo Fuster spent the hackathon documenting technological tools coming out of Sandy and how often they were used by those affected by Sandy. As this record grows, analysts and researchers can eventually share quantitative data on which tools lend themselves to adoption and why.
Meanwhile, Lyre Calliope lobbied hackathon participants to coalesce under CrisisCamp Boston, reviving CCB as an ongoing group so that we could all grow together rather than starting afresh whenever Bostonian netizens rally around a crisis.
Denise’s lessons learned
With nine hours to crisscross the concept-to-demo process, project scope is crucial. Project leads who can contextualize existing needs or foresee needs will keep a team grounded and whittle down to essential tasks. To all my fellow non-tech nerds, we need you! You don’t have to be a technologist to contribute to smarter workflows. Hackathons often struggle to attract diverse skill sets, but “hacker” can mean anybody who dreams up smart shortcuts, tips and tricks to get things done (h/t LifeHacker).- Finally, there’s a lot of momentum around Sandy and a sense of urgency to provide immediate relief. It turns out that immediate needs are often already addressed by local dispatchers and ad-hoc organizers. In a city four hours away from New York, a hackathon can’t address primary needs like food and shelter, but how can we bottle some of the momentum for later, when Sandy survivors will need help from lawyers to file insurance claims? Participant Matt Stempeck—a Media Lab researcher exploring how to leverage diverse skills in the hackathon process—suggested building a skills pledge page in the midst of the momentum to continue the groundswell past phase one of crisis relief.
Pablo’s lessons learned
- Media attention and hackers response – HurricaneHackers found early resonance with media outlets (boing boing, cnet, techpresident), which brought a lot of attention and people. During the hackathon, we realized that journalists and their audiences may not be aware that we were developing demos, not ready-to-use platforms to take the place of on-the-ground organizations (Red Cross, FEMA, etc). Rather, HurricaneHackers was an outlet for netizenship. For example, there was people developing the #SandyAid Followup project, that tried to track follow up to aid requests using the #SandyAid hashtag. It was far from complete, and with all of its developers maxed out just building the platform, it was not ready for media coverage. This became problematic because it did not fall in line with social media advice during a disaster: “do not even attempt to set up a disaster recovery site unless you are fully prepared to devote yourself 24/7 to the effort.”
- Simplifying/reducing the channels of internal communication – There were too many communications channels to keep them all updated. At a global level we had a Trello board, a wiki, 2 skype chats, an irc channel and several emails; at the camp level we had the etherpads, a mind map and in-person meetings. We need tools that allow multiple users to edit simultaneously (sorry wikis, welcome etherpads and gdocs), free admission (sorry skype, welcome irc), and users who are familiar with those interfaces. Then we need to manage the order of in which communication is distributed through those tools.
- Think and work with the community of users – People naturally want to help, and many rallied around HurricaneHackers as an outlet. In the rush of the crisis, people also tend to jump into projects without enough reflection. Generally, programmers want to develop new tools, but as Mayo pointed out “projects that seem to be ‘alone’ and without connection to previously existing communities, or without association to trusted and visible actors, seem to face difficulties in engaging participation.” We should pay
morereal attention to the communities we are going to work with; not invent solutions to problems nobody has raised; and account for the time and people who will feed and use the project. - Have clear instructions, data and contact person to start a project: why, what, how, who, where – A basic hackathon rule is to get familiar with similar projects to avoid duplication. We dedicated the first part of the hackathon to understanding which Hurricane Sandy projects already existed. We then tried to tackle the Crisis Commons requests but had a hard time getting hold of the official requesters, which resulted in difficulty going deeper and staying focused on the best solutions to the problems.
To see or work off shared documentation across Sandy tech efforts, go to: