The Haitian Earthquake saw the first significant uptick in responding entities. Gisli Olafsson brought this up the first time we’d met, at a talk of his at the Wilson Center. I was just starting to visually take notes (having broken my arm), and I was a year into leading a group called Geeks Without Bounds, one of the many technical response groups which had emerged and then stuck around. It was hard to know what we would be good at, where we fit in. Disaster response has such a long and complicated history, and the culture of technology is so used to being new, shiny, and the Fixer of All Things.
Seven years later, and the patterns of digital response are becoming so well ingrained in my soul that I can use the Socratic method to help new groups as they spin up without becoming frustrated, and insist on things like self care. There’s still a lot to learn – especially as our physical and digital environments are changing all the time – but here is what I have figured out about where digital/technical/whatever response fits into the larger response ecosystem: crowdsourcing (and microtasking), increasing everyday capacity, information communication technology, and easing collaboration through standards.
Because each of those is a hefty thing to speak about, this entry covers crowdsourcing and microtasking.
What’s the difference between crowdsourcing and microtasking?
Crowdsourcing is about gathering data, microtasking is about parsing through data. Both are predicated on a very large task being broken down into many tiny pieces, which can can then be done by relatively unskilled/untrained labor. Then all those individual contributions need to be able to re-combine into a logical Whole again without too much overhead. Because of the need for a very clear workflow, the problem-solving creativity of in this process exists in the creation of the workflow, the systems on which it runs, and the creation of the experience for the individual participant.
What follows is an example of an emerging crowdsourced practice and one with a smoother flow and two examples about microtasking. A later entry will cover how citizen science exists in the overlap between crowdsourcing and microtasking,
Rescue Requests and Dispatch
The way I’m used to seeing rescue requests happen is through an overloaded emergency response system asking people to stay in their homes and wait it out. It’s never sat well with me, but I’ve been at a loss as to how, as a remote responder, assist. During Harvey, the Coast Guard activated the Digital Humanitarian Network to help go through rescue requests on social media to provide them with summaries every 12 hours which they could then respond to. 12 hours is a long time to wait, even if it’s a quick cycle for the formal sector. Locals started using Zello to request and offer help via the Cajun Navy. (Let’s return to a rant on redundancy in dispatched resources based on a lack of sharing another time, yes?) Rescue.fm has since started working on ways to coordinate dispatch beyond scribbling on pieces of paper and spreadsheets. Good work, Zello, Cajun Navy, and Rescue.fm! I’m excited to see how this evolves over time, and to see such clear improvements to systems for mutual aid.
During Harvey response (and then again for Irma), Sketch City set up a workflow for volunteers to call shelters to ask for their capacity, available beds, location, etc. That information was then entered into a data structure which could be queried via SMS through code built by the HarveyAPI team.
Eventually, something like a data standard for health and human services could automate much of this process. But until and unless that happens, this sort of information doesn’t become available to people under stress unless folk are chipping in to make those phone calls and enter the data. Good work, Sketch City!
The remote mapping of regions (whether in crisis or not) is something that Humanitarian OpenStreetMap Team has been doing as a core component of digital response since before their mapping of Port-au-Prince in less time than it would have taken to set up a contract through a response agency. Their Tasker is a beacon of how anyone can get involved in helping a response (or “Putting the World’s Vulnerable People on the Map“). Those maps are then used by responders and locals to allocate resources, find useful paths across treacherous ground, or focus restoration efforts. This most recent round of hurricane response was no different, and for that we thank you.
People should be able to ask for, and offer, help in whatever language they are most comfortable in. Areas affected by extreme environmental events will always be home to multilingual populations, whether or not they are visible. The incoming and outgoing information is often so varied as to mean blanket translations won’t work. Thankfully, Meedan stepped in with their Bridge tool and community to create a workflow around translating individual messages, announcements of services, and some documentation of products. Without them, we would have been even more colonial than usual (another rant for another time).
In short, there are many people in the world who want to help, and many who need help. Often, they’re one and the same. Our role as remote responders and system-builders is to help them find each other and to interact with fewer things in the way. A good first step for many people wanting to help is to have a quick, easy way to contribute – often through crowdsourcing or microtasking. A next step to plug in for more complex and longer-term efforts is ethically desirable as well.
If we work together to build an ecosystem around different ways for people to contribute and request, we strengthen our social fabric and become more resilient.
With thanks to supporters on Patreon, who made it WAY less stressful to take the time to write all this down, and to Greg, Jeff, and others who reviewed the post.