Haiti

---

Haiti RMS (Request Management System)

• Requirements/Blueprint: ​http://wiki.sahana.lk/doku.php/haiti:requirements#request_management_system

University of Wisonsin Python club are leading on this: #sahanarms

Suggest following the New Module Development tutorial as this is new functionality for Py:

• DeveloperGuidelinesNewModule

Keep it real simple to start with - get something usable quickly, which we can then refine later if we gets needs to do so.

UPDATE - 100117 02:36am

• Added draft of rms to launchpad branch (~uwthw/sahana/rms)
• Draft script for Cron job of GeoRSS feed from Ushahidi is in applications/sahana/cron/entry2record.py
  • TODO write check for duplicates in GUID
  • TODO get access to older Ushahidi logs
  • TODO scrape additional data from Ushahidi link in each record (e.g. category)
  • Need Cron job timing decision and command to be written

STATUS - experimental

• form for request (sahana/rms/request_aid) & pledge (sahana/rms/pledge_aid)
  • no data validation
  • limited formatting

NEXT STEPS

• build logic for matching pledge and request

<chamindra> Basically there will be loads of requests for aid coming from the field 
<chamindra> by sms, through calls and otherwise
<chamindra> and people will have to enter these (millions) of requests quickly into the system for tracking
<chamindra> there is no time for complex workflows and approvals, so the system has to be extremely quick
<chamindra> if we can enter everything for a request in one html form that would be ideal
<chamindra> similarly there will be loads of people offering donations of aid of various things
<chamindra> often they cannot be used immediately 
<chamindra> but they need to be tracked so that when a need arises the donation and the person who offered it can be found
<chamindra> This is the main objective of the request management system, to connect people who need aid and people who are offering it
<chamindra> however to do the matching you need to agree to some measures
<chamindra> I need 100 Kg of Rice
<chamindra> bit the person that pledges can only offer 40Kg
<chamindra> so you match it but note that there is 60Kg remaining to be delivered
<chamindra> but you need to track the remainder that was not fulfilled

<chamindra> so we now have an added part of getting unstructured data from various sources
<chamindra> basicially someone is recording some information about aid, without reviewing the content and send it to us
<chamindra> first step is someone needs to convert that to a request for aid or pledge
<chamindra> so on click of the queue that is coming in (as a GeoRSS feed from Ushidhi right now of their SMS messages) you convert it to the first step of a request or a pledge
<chamindra> once you click that item is no longer in the pending queue (it has been read and processed)
<chamindra> So let's think through what a typical situation would be
<chamindra> someone would make a call with a request or sms a request
<chamindra> fist step would be to enter what is needed
<chamindra> and it will be a list of items
chamindra> sometimes they will just say "food" or "water" without a quantity
<chamindra> but then you need to ask for how many people
<chamindra> which is why that field is there for
<chamindra> units are not compulsory
<scopatz> How specific does, say the food field need to be?  
<scopatz> For instance, is Rice good enough, or do we need to be very specific like Brown Rice
<chamindra> IMO not very
<chamindra> possibly you can have a highlevel drop down category
<nicopresto> AJAX dropdown
<scopatz> Right that is what I was thinking
<chamindra> no ones going to care with the rice is brown or white right now me thinks :-)
<scopatz> because the alternative would be a foods string that then gets parsed
<chamindra> but you are right in some instances
<chamindra> like if it is pork or for religious reasons
<chamindra> so possible as you said one high level category
<scopatz> OK so we'll come up with a representative list for a drop down menu
<chamindra> food, water, aid, medical, etc
<scopatz> Great, that makes life easier for the matching
<chamindra> and a free text box for the sub category
<chamindra> on the free text thing, there reason is that strcuture can create a bottle neck
<chamindra> unless that process can be made easier.. like using an AJAX lookup so that you avoid spelling mistakes
<flavour> We have an AJAX autocomplete widget in SahanaPy
<flavour> I can help with that
<flavour> For use where dropdowns become unwieldy
scopatz> Maybe we'll add that later, I think the goal now is to get the basic RMS up and running
<flavour> scopatz: Yes, that's icing...getting *something* quickly is key

<chamindra> also you will have many types of items per request
<chamindra> one request will consist of multiple items (like a shopping list)
<chamindra> so each one needs type, description, units, quantity
<chamindra> but you can consider the whole request being from one contact, phone, and for a number of people
<chamindra> good to have a backup phone and contact as well, in case the primary disappears
<chamindra> but that is optional

<chamindra> one last bit
<chamindra> and that is the matching part
<chamindra> once you get a request.. you can do a lookup and see if there is a potential match for it in the pledges
<chamindra> and vice versa
<chamindra> so even immidiately as they are on the call, they can respond saying there might be some options
<chamindra> at the end of the request, show a list of potential full and partial matches to the request

<chamindra> remember think simple intuitive interface
<chamindra> no complex workflows and approvals

---

Haiti