factn / resilience-app

Mutual Aid World - Local Resilience App. Providing ready made, constantly evolving software to meet the needs of local mutual aid projects.
https://mutualaidworld.gitbook.io/docs/
GNU General Public License v3.0
79 stars 65 forks source link

Regarding a bunch of issues raised by the designers in Figma #87

Closed utunga closed 4 years ago

utunga commented 4 years ago

Bunch of question from March 24 from the figma

March 24 As you’re working if there are questions/clarity that you need, put them here if we can resolve them later or in slack, if it will hold up your work.

  1. Who divides the mission into it’s specific tasks? How does this get communicated to the requester? 

  2. How do we want reuesters to communicate with doers? (Currently have text, phone, email...is text and phone redundant?) Commenting in app? Would comments be open to all people on the mission or specific to the worker/requester?

  3. Are doers and donors both types of “workers” performing “tasks”?
  4. General explanation of the money aspect would be helpful: who is paying whom? where/how does money transfer between them?
  5. How does a requester view comments?
  6. What’s the difference in function between the 2 facebook posts?
  7. Is the mission request created by Audrey or someone else? (Because the description is written in 3rd person) Who do workers contact?
  8. Do you have to rate a mission, in order to complete the mission?
9. Requester has opportunity to rate mission, with pathway to also rate individual tasks. Do they also rate individual workers? How does the mission / task rating impact the worker’s rating?
  9. Do the individual task ratings impact/override the overall mission rating?
  10. The grocery list type of task should be itemized in some way so that the Doer can go through each item in the list and no the total number of items etc.. to make sure nothing is missed and for accurate packing. (If the photo provided isn’t legible, should the Doer be able phone the Requester for clarification?).
  11. Is the Doer taking on the task expected to fulfill the order (go buy the items) and then the Requester pays the app, and app will pay out the Doer?
utunga commented 4 years ago

A lot of the time the answer to these question is going to be a process of discussion and working with the mutual aid groups to determine what they need. Nevertheless, I will attempt to shed some light where I can based on what I've heard.

Couple things that have changed since we got these questions.

  1. We have tried to move to an agile process where we build something simple and iterate. That means that we'll be simplifying down to much more simple designs then adding complexity over time... like this: (See the skateboard, scooter etc boxes to the right -->) image

  2. Based on the interviews with the actual on the ground groups one theme is emerging -- food! Farmers markets with too much food and no buyers, older struggling to get delivery and some people just not being able to afford food. They may have to struggle through with the systems they have for a bit longer but hoping we can bring a solution to them AS SOON AS POSSIBLE so we're gonna focus on that for a bit.

Anyway with those caveats/context let me try to shed some light on some of these questions

utunga commented 4 years ago
  1. Who divides the mission into it’s specific tasks? How does this get communicated to the requester? 


For the first iteration lets just go with one mission == one task. Makes it simpler! The mission we're gonna focus on is delivering food to someone so there's a shopping list, an address and funding for the food. Once that's all ready to go a volunteer can 'just go do it'.

  1. How do we want requesters communicate with doers? (Currently have text, phone, email...is text and phone redundant?) Commenting in app? Would comments be open to all people on the mission or specific to the worker/requester?


To keep things simple for first version how about we just make it communicate by SMS outside of the app?

Comments fields are good I guess and if so it should be assigned doer, requester and organiser only, I think. However we should bear in mind that a 'requester' may be elderly and have not have an account at all (they may have been added by the organiser). So it might work better if communication is via SMS as the starting point.

  1. Are doers and donors both types of “workers” performing “tasks”?

I personally would err towards making them very different. A doer does the task, a donor funds the task (or multiple tasks). Very different workflows. I don't think it helps to consider donation just another sub task (myself).

  1. General explanation of the money aspect would be helpful: who is paying whom? where/how does money transfer between them?

Payment rails is a big issue and we will need to tackle in future iterations. Again, in terms of getting things sorted ASAP, the suggestion (after talking with groups on the ground) is that we will have an single bank account per organisation (or possibly just one FactionCoop bank account) people use the online system to pay into that account and mark it for a specific mission or missions. Doers are then refunded from that single account afterwards. Not entirely sure on the details. We have a lot of work to do here to figure this out.

What we're trying to achieve is that a grocery list (or a 'food box') needs to get funded before it gets delivered. So the first thing is to create the missions (aka the shopping list), then, basically anyone can come along and fund it. So people can pay for their own food (online) or they can fund food for others. Doers then pay at the actual market (in the first insance) out of their own pocket and then once they have marked the mission done and accepted they get paid. If it doesnt get accepted, well, we have to figure that one out!

  1. How does a requester view comments?

See above. Maybe we don't need comments so much in version 1? or maybe a request gets a specific url and you can just see the comments that way?

  1. What’s the difference in function between the 2 facebook posts?

I think the difference is that one of them is shared by the/our organisation account and the other is shared by the user individually.

  1. Is the mission request created by Audrey or someone else? (Because the description is written in 3rd person) Who do workers contact?

Currently we don't really have a role for community organisers. We need to add that in. So a mission can created by a 'requester' or by an 'organiser'. Optionally missions may have to be approved by an organiser before they appar in teh list for that organisation.

  1. Do you have to rate a mission, in order to complete the mission?

As Tuan put it a mission goes from todo -> doing -> done -> donedone

So the doer marks it as 'done' then it gets rated and then it is 'donedone'. We may call that last stage 'accepted' though cause 'donedone', while fun, is going to get confusing.

  1. Requester has opportunity to rate mission, with pathway to also rate individual tasks. Do they also rate individual workers? How does the mission / task rating impact the worker’s rating?

Uh. I dunno. Lets just rate the missions as a while for now. Not the worker per se nor the sub tasks (if any). Did you get the groceries you ordered, roughly speaking? Good. Rate mission a success.

  1. Do the individual task ratings impact/override the overall mission rating?

No because they don't exist, imho. At least not in the first iteration.

  1. The grocery list type of task should be itemized in some way so that the Doer can go through each item in the list and no the total number of items etc.. to make sure nothing is missed and for accurate packing. (If the photo provided isn’t legible, should the Doer be able phone the Requester for clarification?).

Features specific to grocery lists would be awesome to add. Not sure how that looks though. Your point about being able to phone the requester is a really good point. We should add that! (Optional for the requester, though)

  1. Is the Doer taking on the task expected to fulfill the order (go buy the items) and then the Requester pays the app, and app will pay out the Doer?

For first iteration: Task is funded. Doer pays the food supplier. App pays the doer.

Sounds a bit harsh on the doer, but at the moment doers are paying out of pocket and sometimes they dont even get paid at all, so its an improvement.

Also we are trying to avoid use of physical cash at the door for obvious reasons.

mat10tng commented 4 years ago

This should move to wiki or to some google docs for relevancy