22nd February 2011. 12:51pm - http://eq.org.nz/

Volunteer Response Survey

One of the largest parts of running a project of this size is knowing how easy it is for the volunteers to participate, whether or not they would be willing to come back and do it again.
I would like to thank everyone who participated in this survey, the information gathered is really helpful for all of us.

Here is a summary of the responses (scroll to the bottom for a conclusion/next steps).

What Worked Well?

  • The team worked well - people just dug in to get things done.
  • Separating technical people from non-technical volunteers was useful in that it made volunteering seem less intimidating to those with less technical knowledge. 
  • Using github for development was great. Transparent and easy to use.
  • The many various (shared-editing) Google spreadsheets avoided the need for many other human coordinators or web apps.
  • The training worked well.
  • The chat environment was extremely useful, the people in the skype rooms were supportive, professional, and understanding. 
  • Communication tools at hand were well used to make sure other Volunteers were not left out of the loop. 
  • Reporting Tools were simple and effective, processes of verification were clear and consise.
  • The generosity showed by the core team of Catalyst folk, these guys were real heroes.
  • Having Quick tasks worked well - breaking larger tasks into easier to manage pieces

What didn’t work well?

  • Duplication of effort was frustrating.
  • Reports are clunky to use, especially if you are creating/updating a large number of reports.
  • Data that got out of date was hard to deal with. Perhaps have a way for old data to fade out of relevance if not updated. (Not mapped, but searchable). Have an easy way to update and say it’s still relevant.
  • Web interface didn’t support multi-location reports.
  • Skype was a pain for various reasons: 
    • Trying to keep up with the Skype flood, about 1000 IMs per day for 2 weeks with some important nuggets of needed information buried in the stream of raw data. 
    • Leaving the chat would have meant being unable to rejoin without being invited.
    • Not everyone can use it.
    • It stutters and throws up old messages, which is really bad when it’s an emergency help message that has already been dealt with.
  • The fact that the Ushahidi software delivers the same messages in the queue to all volunteers at once made things difficult to manage. I’d really like the software to show me:
    • who is logged in and volunteering
    • who is doing what - ideally Ushahidi could send out say, 10 messages at a time to each volunteer who is logged in.  Each volunteer would receive unique messages, and when finished could click ‘Next’ to get the next set of messages.  This would have helped us avoid lots of duplication, and it would be easier to manage volunteers because less communication about who’s doing what when would be required.
    • It would have been good to be able to tag (time-limited and expiring) a message I was working on. 
  • Knowing the state things were in. At times it was hard to know where to look to find documentation or notes about previous discussions and decisions that have been made.
  • As we moved on volunteers were hard to find and faded quickly.
  • I felt that there was a bunch of duplicated effort by different organisations eg
    • many people setting up the accomodation available sites,
    • I don’t think the Google People finder was used in conjunction with the work the Red Cross were doing
  • Unclear instructions by the media on how to use the shortcode.
  • There was not much information relating to what developer skills were required or how to get involved with the development effort other than the issues list and the communication channel. Not wanting to compromise existing efforts it was difficult to establish how I could slot into the dev effort. This ultimately resulted in a barrier to volunteering and I could not see how I could contribute despite having over 18 years software dev experience. 
  • Having to find the GPS co-ordinates, the zooming goes too fast and makes it difficult to pin on the map
  • My limited experience made the volunteer applicant management stand-out. I would suggest an automated response confirming receipt and directing the applicant to the very useful page on what information to provide. I took the lack of response as both an indication plenty of candidates were available and that you were busy, no problem. An automated confirmation would have allayed fears the email had gone astray and perhaps improved the information made available.
  • I thought that it would have been great if there was a centralised space that contained links to the different resources. It was a little time consuming having to troll through emails to find the link to the wiki and another email for google groups, and another for the volunteer and task lists, etc. Perhaps if there was a page in the admin section of the site that contained a list of quick links to these it would save valuable time.
  • Felt like sometimes there was no prioritisation of tasks 
  • We need a way to efficiently channel the oversupply of volunteers into useful endeavours. Crowdsourced twitter filtering is an easy example, eg. the use of the redspider monitor.
  • We should survey a bunch of Christchurch residents to find out more about: whether they heard of us, whether they used the site, what they thought the site was for, what info they wanted to see on it, and most importantly, what things they didn’t have that they really needed (that we could potentially supply). They’re a market, we’re a product. There’s no reason why we can’t do market research to build a better product.
  • We should have the applications ready to go at the push of a button next time. Most of our time in the first day was spent on things that we could have done in advance (except for the monitoring of course). I’m thinking something like a hi-tech, govt department, that’s run like a startup, to develop a useful web-based set of tools to help NZers with disasters. … (to) be well prepared for next time.

What would you do differently next time?

  • I’d try and get volunteers organised for week two, in week one. At least get a rested team together for a weekend after the first week. (Look after the team as much as possible.)
  • Start looking at getting business data synced from public databases (finda, google) etc, with a view to getting as much info into the system when it’s needed. (Business name and status information - Only status (and possibly a comment) is likely to alter over time after the crisis, so that should be the only thing that gets edited. (Businesses are relocated = closed and reopened in a new place)
  • Different technology, same people. We spent far too much volunteer time working around issues in the tech, it really needs to be revamped completely.
  • There were two many communications channels.  We had several Skype channels, plus an IRC channel, plus a Google Group, plus a list of volunteers’ email addresses, plus a wiki pg.  We never established one single way to communicate effectively with everyone.  Part of this is due to the nature of evolving projects, but if you began with a better plan for communications, it wouldn’t be so hard to try to centralise later on. 
  • Get email group happening early on 
  • Regular status emails
  • Chat 
    • Not use skype. 
    • IRC rather than Skype.
    • Different “rooms” for different roles 
  • Fly down to Wellington for the hackathon.
  • Have one person looking after the allocation of tasks on the spreadsheet and responsible for tracking completion or non completion (non judgementally).
  • Get involved sooner

Polls




Conclusion: Next Steps

  • New Chat System
    http://phirate.posterous.com/real-time-communication-in-a-crisis

    IRC is too difficult
    Skype is too “buggy”
    We need:
    • Rooms
      • a “landing” room for volunteers who are interested and haven’t been trained, but keep out spammers.
        This room needs a voice / screenshare capability, otherwise just direct people to Skype (for training). 
      • a “filterer” room
      • a “developers” room
      • also perhaps an “admin” room
    • Users
      • Should be tagged with their “roll”
        • Should be tagged as an “admin” so people know who to contact with help
    • A list of updates - what has been discussed during the day in chat
    • A “shout” feature - get the attention of a user by tagging their name so that chat can run in the background while they are focussed on other jobs.
    • A server to store chat history, retrievable by users and searchable.
    • Possibly a webapp (mobile probably not needed) with an executable version as well.
    • Needs to be useable by someone who has never used IRC - jump in and start helping.
  • Better Volunteer Recruitment
    Even just reading the above post you can see two points “We needed more volunteers”, “I tried to volunteer but didn’t get through to anyone”
    We should train more recruiters. 
  • Better Documentation
    List of what has been said in chat over the past day. 
  • Avoid Duplication
    List of what’s being done - for reports have Ushahidi “assign” posts to active users.
  • Fix issues in Github
    https://github.com/ccnz/Ushahidi_Web/issues 

Thanks,

 - Hayato Clearwater