Please click here to apply to the Crisis Mappers Volunteer Task Force.
_______________________________________________________
The disaster response to Haiti was unprecedented in terms of volunteer buy-in and contribution. It was also reactive. The hundreds of volunteers who rallied to the cause were certainly able and committed but one of the main challenges during the first few weeks was the need to train and maintain this informal network. The humanitarian community openly recognizes the important role that volunteer networks can play in crisis response. What they need now are guarantees that a trained and professionalized volunteer force can be on standby and activated within hours. The good news? Many of the volunteers I interacted with during the response to Haiti, Chile and now Pakistan are eager to join a professionalized volunteer standby team.
So what exactly are we waiting for? I posed this question to my colleagues George Chamales and Rob Munro in San Francisco yesterday. Indeed, there’s no reason to wait. We can get started now so we can take this initiative to the upcoming International Conference on Crisis Mapping (ICCM 2010) and get feedback from participants. The challenge, as mentioned in my previous blog post on Disaster Relief 2.0, is to find a way to interface an informal distributed network of volunteers with a highly organized and structured organization like UN OCHA. Three types of reliable networks are needed for this interface: (1) Tech Team; (2) Task Team; and (3) Crowd Force Team.
On the technical side, what colleagues and I have found to be particularly important is to have a group of software developers who are already highly experienced in deploying platforms like Ushahidi, FrontlineSMS, Sahana, etc. This is not about building new tools from scratch. The point here is to rapidly customize existing tools that have already seen action. On the Ushahidi side, there are more and more seasoned Ushahidi developers. These individuals are the ones who made the deployments in Haiti, Chile and Pakistan possible. This network of core technical and reliable volunteers doesn’t need to be large and it already exists.
What this group needs, however, is a support team that can take specific technical tasks given to them for implementation, e.g., fixing an important bug, etc. That way, the core team can focus on rapidly developing customized Ushahidi plugin’s and so on. We need to create a roster of standby software dev’s who are already qualified and ready to support the core team. This group largely exists already, but we need to formalize, professionalize and publicize this information on a dedicated site and turn them into a standby force.
The second type of standby group needed is the Task Team. These are individuals who are not software developers but savvy in media monitoring, geo-referencing, mapping, blogging on updates, etc. These individuals already exist, they played an invaluable role in contributing their time and skills to the responses in Haiti, Chile and Pakistan. Again, it’s just a matter of formalizing, professionalizing and publicizing the information, i.e., to render visible the capacity and assets that already exists, and to have them on standby.
This core task-based team also needs a strong support team for back-up, especially during the first few days of an emergency. This is where the Crowd Force Team comes in. This important team doesn’t need prior-training; only Internet access, browsing experience, an interest in online maps, news, etc. Perhaps most importantly, members of the Crowd Force Team are known for their energy, commitment, team-player attitude and can-do mentality.
We want to formalize this Standby Crisis Mappers Task Force in a professional manner. This means that individuals who want to be part of Tech, Task or Crowd Force Team need to apply. We will first focus on the Ushahidi platform. In the case of the Tech and Task team, interested applicants need to clearly demonstrate that they have the experience necessary to be part of the Standby Task Force. I would actually want to include representatives from the humanitarian community to participate in vetting the candidates who apply. Individuals who want to join the Crowd Force Team will also need to apply so we can keep a roster of the people power available along with their skill set.
There’s no reason we can’t do this. If we learned anything from Haiti, it’s that Community Emergency Response Teams (CERTs) don’t need to be physically present to contribute to disaster response thanks to online social networking tools and open source platforms like Ushahidi, etc. They can be part of the online community. We need CERTs 2.0 and just like traditional response teams, they should be trained and ready.
My experienced colleagues George Chamales and Anahi Ayala will lead the Technical and Task Teams respectively. Anahi will also coordinate the Crowd Force Team. They will help select the applicants, set up the appropriate communication channels and keep a calendar of which members of their teams are available for rapid response on a daily basis. Jaroslav Valuch and I will support George and Anahi in their efforts.
Please click here to apply to the Crisis Mappers Volunteer Task Force. Once we have developed a robust model for interfacing with the humanitarian community using the Ushahidi platform, we hope to work with other colleagues from FrontlineSMS, Sahana, etc., so that their qualified volunteers can be part of this dedicated Task Force.
iRevolutions 
Hi Patrick,
From the OCHA side, I have to say that I applaud the initiative – it should give us a more structured and consistent way to interact. As you know, I leveraged the Crisis Mappers group during my time in Pakistan (and was indirectly involved in Haiti) — one of my challenges was the fact that I was simply throwing my idea out to a group of individuals who I was not very familiar with. I had to ponder questions like: When will I get a response?, Will anyone help with the task?, Is there anyone in the group with the right skills?, and Will the work be completed? Are you expecting that part of the team leader(s) roles will be field and perhaps direct some of the support requests (similar to what I sent from Pakistan)?
Hopefully, with these teams and team leads in place, we will be able to shed more “light” on the talents of the various members. I am referring to Chris Andersons TED talk about the elements needed to really push Crowd Accelerated Innovation [Crowd, Light & Desire] when he says: “Light: clear open visibility of what the best people in that crowd are capable because that is how you will learn how you will be empowered”
(http://www.ted.com/talks/chris_anderson_how_web_video_powers_global_innovation.html?utm_source=newsletter_weekly_2010-09-14&utm_campaign=newsletter_weekly&utm_medium=email)
Regarding the establishment of a professional volunteer team, you may want to chat to MapAction (http://mapaction.org/) about the challenges that they face in running such a group (i.e. continual training, new volunteers, volunteers leaving, varying level of volunteer’s commitments, etc). They have been providing a sort of Crisis Mapping service for about 1o year know. I assume that they will have some ‘lessons learned’ that might be of value to you and the team leaders.
Thanks Andrej and Patrick.
Yes MapAction will be happy to contribute know-how to the setup of the new Standby Task Force. However our methods are more geared to operations in the field than coordinating an online group so it will be horses for courses.
As Andrej implies, predictability of response is crucial in humanitarian ops. So, we’d be keen to establish inter-operability protocols with the Task Force, and I assume the TF will want to do the same with other field-level partners.
Thanks very much, Nigel!
Patrick
Thanks – this initiative looks to be what we are looking for. Hopefully we can link this up with the discussion that my colleague Akiko Harayama will be facilitating at the Conference under the self organised session. Here’s a bit more on that:
Comment by Akiko Harayama on September 17, 2010 at 11:48am United Nations Office for the Coordination of Humanitarian Affairs
Title: We need you, let’s work together – Operational realities of managing information in humanitarian emergencies
Description: The common information management officer in the affected area has to work with low performance computer, often infected by virus spread by exchange of data through various usb keys, with up and down internet connectivity (more down than up), in agitated, crowded and rudimentary work environments. The operational reality is far from what you can imagine, especially in data management.
During an emergency, the United Nations Office for the Coordination of Humanitarian Affairs (OCHA) collects the minimum common operational datasets to enable the humanitarian community to use the same baseline data for interoperability. We collect data from different sources, with various levels of quality, in diverse formats that must be standardized and make the best data available to the users. This is one of the crucial activities in a sudden onset emergency, but its an intense and laborious task for our staff, already under pressure. Reaching out to partners or “crowd” to process and clean the data will help us to respond quicker.
Another area where we can foresee a link with you is in the area of emerging technology. You have new platforms and technology, we have the information network and humanitarian professional experience. By linking both, we will improve response that will ultimately help save lives and respond to the needs of affected populations.
Please, join us to our discussion, we will tell you our needs, gaps and challenges and we would love to hear your innovative ideas and knowledge. Let’s built a partnership and best practices.
Hi Olly, many thanks for your comment. I’m very much looking forward to discussing this with you and Akiko at the Conference.
I have a number of questions:
– I can think of several other groups that do this (and see themselves as “professionalized”) and I am curious what the real differentiator will be. In particular, what is the relationship with CrisisCommons? Will they work as brokers for these teams, and this will fit in as another “VTC” (as per: http://www.slideshare.net/poplifegirl/final-sloan-presentation) or is this totally independent? Should this be read as a critique of CrisisCommons?
– Who does this group represent — is it platform based, officially supporting Ushahidi, Frontline and Sahana?
– How will you provide guarantees for activation time or quality of work? Will there be actual service level agreements?
– Who will decide what the group works on? Will there be formal affiliation with agencies like OCHA? Or will leadership within your group decide?
– Who leads this group and how are they decided?
Thanks Chris, good questions all around. The point of the self-organized sessions at the upcoming conference is to engage such questions in a collaborative manner and work out some potential solutions with our partners in the humanitarian community. I’ve added some of my preliminary thoughts in response to your questions below. But first I’m curious why you didn’t provide me with this feedback when I shared the draft of this blog post with you by email a few days ago since I was really interested in getting your thoughts?
– I can think of several other groups that do this (and see themselves as “professionalized”) and I am curious what the real differentiator will be. In particular, what is the relationship with CrisisCommons? Will they work as brokers for these teams, and this will fit in as another “VTC” (as per: http://www.slideshare.net/poplifegirl/final-sloan-presentation) or is this totally independent? Should this be read as a critique of CrisisCommons?
My current focus and comparative advantage is necessarily with the Ushahidi platform and network. That’s what I know best and hence am most confident about. This explains why I’m experimenting with Ushahidi as a way to pilot this new Standby model. I know you already read this on my blog post but I want to emphasize that here again. Hence, I’m interested in recruiting those individuals (like you) who have already been particularly involved with Ushahidi and in some of the major responses this year, eg, Haiti, Chile and Pakistan. If our good friends at CrisisCommons were spearheading a (1) Standby Crisis Mappers Task Force and (2) focusing on Ushahidi then I would have of course joined those efforts. But CrisisCommons as you know is broader and goes beyond Ushahidi, FrontlineSMS, Sahana, etc., in it’s focus and mandate as per Heather Blanchard’s slide presentation. They don’t focus on just mapping and existing platforms, hence their name. That’s why I emailed the CrisisCommons leadership today after speaking with an OCHA colleague who needed a specific type of software program that had nothing to do with Ushahidi, etc. That’s also why I told a WFP colleague this evening that they should get in touch with CrisisCommons in order to get help on completing a platform they started building. And goodness no, Chris, this is not a critique of CrisisCommons. As Heather Leson from CrisisCommons clearly stated in the CrisisCommons Google Group today, CrisisCommons and the Standby Task Force efforts are “complementary, we all need preparedness.” I’m surprised that wasn’t obvious. Recruitment for the Standby Team is open to everyone interested, including our friends volunteering for CrisisCommons not to mention members Diaspora communities.
You mentioned you knew of several other groups that already do the model I’m proposing. CrisisCommons isn’t setting up a Standby Crisis Mapper Task Force based on the model I’m proposing, nor focusing on Ushahidi. So who are the several other groups you refer to?
– Who does this group represent — is it platform based, officially supporting Ushahidi, Frontline and Sahana?
As I wrote in my blog post, I’m proposing an iterative approach. And as I wrote above, I’m starting with the Ushahidi platform because that’s what I know best. Frontline, Sahana, etc, can obviously set up their own volunteer groups along whatever models they’d like. All I’m doing is starting with Ushahidi experiment with this approach. We’ll learn and iterate and share our lessons learned with everyone.
– How will you provide guarantees for activation time or quality of work? Will there be actual service level agreements?
This is a question that we all want to work out at the conference, or start to work out. I wish you would have written “How will *we* provide…” This a collaborative effort with our colleagues in the humanitarian community. My own suggestion as noted in my blog post was to create a roster of trained crisis mappers and to have them on standby or on call at designated times, ie, have preparedness and contingency plans, protocols, etc. ie, learn from our colleagues in the humanitarian field and adapt their model. I’m looking forward to learning more from our humanitarian colleagues about what approach would suit them best. I have no doubt that with the high caliber team that already exists we could set up an MOU with one humanitarian group to begin with. For example, say we work with organization A and they form an agreement with the Standby Team. Organization A will notify the Team when they want a deployment of Ushahidi with live crisis mapping for the first 72 hrs after a disaster. So the Team could make all the necessary arrangements to be prepared for that eventuality and pledge to deploy in say 4 hours after notification. As I discussed with several humanitarian colleagues in NY today, we could also be included in their regular disaster response simulations, so all can learn and improve in controlled environment. I obviously don’t have all the answers though, which is why I’m excited about the conference, especially since there is more political will than ever on the part of the humanitarian community to explore this kind of set-up. But again, we start small and do that well. We learn, iterate and move forward. We also learn from our colleagues at MapAction about their protocols for rapid deployment. They’ve already offered their kind support on this.
– Who will decide what the group works on? Will there be formal affiliation with agencies like OCHA? Or will leadership within your group decide?
I personally would much prefer that a partner like OCHA lets the Standby Team know where/when to deploy. But again, this is where our humanitarian colleagues can let us know what kind of set up might work best for them.
– Who leads this group and how are they decided?
My hope is that this will be a joint partnership with a humanitarian group with joint decision-making. I hope this can be decided on during our conversations at the conference. Right now I’ve asked George, Anahi and Jaro to help me get this started since they are especially qualified and I’ve had a very positive experience working with them in the past. But it’s an open group and anyone who wants to join and be part of the conversations and get things done is more than welcome to. I sincerely hope you will join us and make sure we not only reflect on the questions you raised but also ensure that we’re more than a talking group, we’re a doing group.
I’m curious why you didn’t provide me with this feedback when I shared the draft of this blog post with you by email a few days ago since I was really interested in getting your thoughts?
Sorry, I just didn’t have time!
this is not a critique of CrisisCommons. As Heather Leson from CrisisCommons clearly stated in the CrisisCommons Google Group today, CrisisCommons and the Standby Task Force efforts are “complementary, we all need preparedness.” I’m surprised that wasn’t obvious.
But remember Heather’s comment was in response to someone else asking about this effort: “Competition or complementary?” So thanks for your elaboration — I don’t think that it was obvious. I am speaking a little as a devil’s advocate, because I think I know what you are saying, but I think this really needed confirmation.
I see nothing wrong with criticizing CrisisCommons (I helped organize the Portland event in January and self-identify a member), or even creating completely external mechanisms: — diversity and independence is key, as in Open Source generally. But this is a serious proposal, and it does overlap significantly in its “crisis effort brokerage” role, hence my question.
I’m starting with the Ushahidi platform
Absolutely sensible to start with Ushahidi-base projects — I think this fact was not clear in the original post (or I just missed it).
I have no doubt that with the high caliber team that already exists we could set up an MOU with one humanitarian group to begin with.
I would not take membership for granted. In my reading of the situation: If you can better standardize value transferred to Crisis Relief Orgs, while you keep the Volunteer Technology Community (hackers) happy, you win.
But this is really hard to do, and I think many Volunteer Technology Geeks would not join the tech group, as it has been sketched so far.
Here’s why:
1.) hackers hate giving guarantees. It’s the internet, after all.
2.) hackers hate being on call, particularly doing “data triage.” I have worked in on-call web operations since 2005. Once I had to carry a pager! And basically, it was horrible. Imagine if you had to wake up and fix your laptop every time a program crashed. 🙂 In the last 2 years I have started doing “deployment work” in crisis situations. It was way worse! During the January Haitian response in particular, I was particularly unprepared. Psychologically speaking, it is very dangerous to involve yourself in “saving lives” (because presumably the converse must be: when you mess up, people die.) I am not the only one who did not handle this well — though there are some that are quite capable, and you’re damn right they need to be put to work. 🙂 But it isn’t for everyone. I actually encourage you to be extremely selective, and not totally open, if you really need to deliver guaranteed services. Look at the huge hacker dropout rate on projects in 2010.
3.) hackers already have productive methods. I personally feel that I could be more productive working as I have been: with incremental commits to various codebases, than to commit to new program-specific deployments. This is what makes me feel more certain that I am doing good work, and I think this is a permanent aspect of Open Source mentality.
4.) hackers are always at risk of overcommitment. Following hacker best practices, I hope to avoid dropout by not over committing myself. I need to first guarantee stability to my family and loved ones. I want to do more productive, long term work where there may not be a lot of media attention, which allows me to work over the course of a lifetime, not just a few intense months.
5.) hackers are independent: My motives frequently do not align with the initiatives of large international agencies. I would not contractually obligate myself to OCHA without knowing what we would work on ahead of time. I feel perfectly useful without them telling me what to do. If I happen to want to work on one of their projects, I would leap at the chance for a partnership — but this has to be at my discretion.
As you describe in the opening paragraph of your post, we want to be proactive, not reactive. In this sense, don’t want to be on standby — I want to do the work every day.
I think that this general principle also applies to the nontechnical team, though I hope I made it clear I am thinking about this in the programming and system administration context.
Anyway, I am sure it will be an incredible tech team. I absolutely appreciate the effort, but want to be clear about why I would not join as it as been described. All of the issues I raised are personal, not universal to all humanitarian hackers, but I do not think they are unique.
I would not take membership for granted.
Neither would I. Hence George, Anahi, Jaro and I actually going through the recruitment process. As mentioned in my blog post, we don’t need a large tech team. Remember, we’re working on an already existing platform, Ushahidi, and taking appropriate measures to be as prepared as possible, eg, pre-deployment with pre-set categories ready to go; Swift River platform on standby to facilitate media monitoring, etc. Also, I would expect that the partner humanitarian organization staff also have a dedicated long code in their mobile phone address books ready to go, as well as Ushahidi smart phone apps already in sync with the pre-deployed Ushahidi platform, and staff would already be trained on how to report. In other words, I see a small, adaptive and effective tech team. I’ve just had a look at the recruitment database and we thus far have 94 individual signed up (in just 72 hours). Even if only 10% of these are tech savvy Ushahidi devs, that’s more than enough and allows two groups to take shifts. Also, as I noted in my reply, I have a very specific timeline in mind in terms of support to a humanitarian organization re a specific crisis. It would not be ever ending.
On the Task Force team, the point would also be taking shifts. This was the first piece of advice that FEMA gave us early during the deployment in Haiti. We weren’t prepared and did a lousy job at setting up a schedule based on shifts. I would also add that we do have a good track record of membership, from Haiti, to Chile and now to Pakistan. So three data points. Are these perfect? No, of course not, but they were also reactive and not pro-active, and also the first 3 data points where we all learned a lot. Again, what I have in mind is support to humanitarian organizations with a fixed time period. And again, if we maximize preparedness and planning, the burden on the members of the Task Force is less than in a reactive situation. Lets also keep in mind that Haiti was very, very unusual. Most disasters are more along the lines of a Chile.
1.) hackers hate giving guarantees. It’s the internet, after all.
We’ve already got a core Tech Team already committed. This is not about being or not being a hacker. Everyone’s different. A number of software dev’s I know want to get engaged in the kind of framework we are proposing precisely because then they know that the hours they put into the response will be tied directly to a humanitarian organization on the ground that directly solicited the support. It won’t just be “hacking” for hacking sake simply because they want to feel good about themselves. The fact that this would be formalized is actually an important incentive for the software dev’s I know and who have had bad experiences in the past where they spent weekends hacking on software that wasn’t used. I think we have to be careful about considering “hackers” as a monolithic bloc and going just by stereotypes.
2.) hackers hate being on call, particularly doing “data triage.”
Again, we already have 94 people who responded to this recruitment knowing precisely that this would mean to be on call. This is not for everyone. This will be a self-selected group of individuals. Also, on the data triage, we’re looking at leveraging Swift River and micro-tasking to make this less time intensive. But again, this is not for everyone. If people don’t want to help out OCHA (for example) in a partnership to tag incoming text messages (part of which can be automated) coming from Malaysia, then they just don’t sign up. Also, the point of having multiple teams on the ready is important so that we create a more resilient preparedness team. The disaster response community has been learning these lessons for decades to make this more manageable. It’s time we learn best practices from our colleagues.
I personally feel that I could be more productive working as I have been: with incremental commits to various codebases, than to commit to new program-specific deployments. This is what makes me feel more certain that I am doing good work, and I think this is a permanent aspect of Open Source mentality.
Again, we all work differently and this is your personal preference. On the good work though, surely you’d want to know that your incremental commits are actually being used in a meaningful way. But again, this is not for everyone and we’ve already got 94 people signed up in 72 hours. And of course you are under no obligation to join. This will certainly be a self-selected group focused on one platform to begin with.
4.) hackers are always at risk of overcommitment.
Some are, perhaps, but again we’re not recruiting exclusively from the hacker community and the Standby Team is not exclusively a hacking team by any means. Hence formalizing this and professionalizing the standby team. We would not be the first standby team on the planet so we would learn from others and take guidance from our humanitarian colleagues on how best to set up. We will also carefully select members of the Team and make sure we create a robust network with no single points of failure, ie, with redundancy.
5.) hackers are independent: My motives frequently do not align with the initiatives of large international agencies.
Yes, and again we are not recruiting hackers exclusively and they are not a monolithic group. And again, some of the folks I’ve spoken to are frustrated that their work is not directly tied to legit international agencies who have humanitarian professionals with dozens of years of experience and who are physically on the ground responding. They want to help and do so in a meaningful way. Not just hack away and hope that someone will find their work helpful. So this is actually an incentive to many people.
As you describe in the opening paragraph of your post, we want to be proactive, not reactive. In this sense, don’t want to be on standby — I want to do the work every day.
Great! No one is preventing anyone from working every day.
You know, your questions did get me thinking about CrisisCommons. Have you shared these questions with them? They seem more pertinent to the mandate they are pursuing.
Thanks for the fast responses, Patrick, exciting stuff all around. I am so glad to hear about the early turnout yesterday.
(Please note that all of my concerns about “hackers” were only addressing volunteer programmers and system administrators, not the management or the non-technical volunteers. )
Pingback: My Introductory Remarks at ICCM 2010 | iRevolution
Pingback: The Best Part of ICCM 2010, Not. | iRevolution
Pingback: Developing a Model for Tapping Technical Volunteers: From Crisis Mappers to DHS’s NET Guard « idisaster 2.0
Pingback: Crowdsourcing the Angry Skies: The SKYWARN Volunteer Network | iRevolution
Pingback: Crisis Mapping Libya: This is No Haiti | iRevolution
Pingback: Crisis Mapping Libya: This is No Haiti
Pingback: Changing the World One Map at a Time | iRevolution
Pingback: Changing the World One Map at a Time
Pingback: Watching Ushahidi’s Mumbai response unfold, with co-founder Erik Hersman | Krantenkoppen Tech
Pingback: The Standby Volunteer Task Force: One Year On
Pingback: The Standby Volunteer Task Force: One Year On | iRevolution
Pingback: Volunteer for crisis mapping efforts | diana maps