FOR ARCHIVAL PURPOSES ONLY

The information in this wiki hasn't been maintained for a good while. Some of the projects described have since been deprecated.

In particular, the "Ushahidi Platform v3.x" section contains information that is often misleading. Many details about this version of Platform have changed since.

This website is an extraction of the original Ushahidi wiki into a static form. Because of that, functions like logging in, commenting or searching will not work.

For more documentation, please refer to https://docs.ushahidi.com

Skip to end of metadata
Go to start of metadata

 Wielding An Ushahidi-Shaped Hammer


(courtesy of George Chamales)

If someone sets up an Ushahidi Deployment on the Internet and no one’s around - does anyone care?

Start with the Questionnaire

  • go over it on the phone with them
  • that way they don’t need to be bothered to read it
  • pitch it to the customer as the “rapid deployment” questionnaire

Hitting the Sweet Spot for a Deployment

  • right number of reporters
  • right number of reports
  • right fidelity (information, location, timing) of reports
  • right number of people using / responding the information
  • right number of people publicising the deployment

Changing instances mid-way is hard and annoying

  • all the categories got messed up
  • had to add images, categories, news, verification types by hand
  • is going to be even more fun to migrate from 1.1 to 2.0 over
  • it’s even worse if you’re also switching domain names

Have your verifiers and team outside of the disaster area!

Faisal  (pakreport.org)- “one TV can start advertising us. got a few connections. but we need to setup logistics before that. power breakdowns are big problem for us right now”

Measuring the success of your deployment by the number of reports you’ve collected is dangerous.  Sure it’s tempting and by far the easiest way to do it, but it’s not the size of your reports, it’s how you use them.

Stuff you must do

  • understand the importance / difficulty of what you’re about to do
  • domain name
  • wiki
  • email groups
  • keep everyone in one big group to start with, specialize later
  • x specializations:  dev, media, management
  • deployment blog
  • team roster: name, location, telephone, email, responsibilities (spreadsheet)
  • skype channel
  • twitter handle
  • other stuff:  facebook account, google voice
  • backups of code and database
  • x if possible, replicate server
  • staging server and production server and local dev server
  • sysadmin commitment to staging changes before deploying -- nothing straight to production
  • use ssh keys when possible
  • use unique logins when possible
  • use non-shared hosting to ensure availability of sudo access and cron, etc.
  • have regular briefings
  • x public conference call for status reports
  • x blog posts - weekly?
  • set up standard ppt template for briefings / presentations to other people

Category Updating

  • what about building it on the fly?
  • having not only context, but sources
  • should have a description of each category

Who are you serving?

  • responders: collecting, ordering, and disseminating high-value, categorized information?
  • citizens: collecting and ordering requests for assistance?

Who are you communicating with?

Open Questions
  • what’s the easiest way to track all the various passwords you’re generating?
  • what are the most effective means to get the word out
Community Building
  • how do you make a deployment in a crisis last and grow into a long-term rallying point?

Clickatell Setup

  • check whether your api key is in use
  • see your reports on usage

Three Models

  • Collect Aid Requests:  need monitoring and coordination by aid agencies
  • Build Situational Awareness:  need people submitting info + vetted aid groups to ask questions to them
  • Share Aid Status:  need info from aid agencies, aid agencies / people looking
  • No labels