search

aerogear / OpenVolunteerPlatform

Platform for building volunteer management systems dedicated for local gov and charity organizations
https://openvolunteer.org
MIT License
52 stars 8 forks source link

MVP Discussion #59

Closed machi1990 closed 4 years ago

machi1990 commented 4 years ago

The main workflow for the MVP is being able to complete a volunteer action (from its creation to delivery), so that we can have something for the Demo.

The things that we’ll need for this are:

We’ll need to figure out what’s the best way to do some things that’s are to be done.

Some initial thoughts:

/cc @wtrocki @craicoverflow @joaedwar @kingsleyzissou

wtrocki commented 4 years ago

create a recipient (how should this be done?)

It can be batch inserted into the database or we can have recipient application as well (with form only initially) or we can create it in admin

Admin creation could be MVP

(I might be forgetting some)

What you mean by this?

We can create an action on the admin /client side (see #53) and then a volunteer can pick it up (once that is done the status is ASSIGNED). Once picked, it cannot be picked by another volunteer.

We need to formalize this better.

Idea 1

Action can be created in the scheduler (with some analytics added later). The scheduler will be able to create actions for delivery for some specific timeslots (once per day for the next 2 weeks or something like it). When actions are created they can be then accessible using the + button in the volunteer app. Volunteers can pick actions themselves.

Pros

Cons

Idea 2

I think might be more realistic is that people are getting 2 phase actions. First, they need to collect goods from the distribution center that is closer to them - auto assignment should happen on app level. When they arrive at distribution center then they are approved to deliver daily (ther is no way to pick up actions for more than a day - single day use

I guess it will be nice to research ways those initiatives operate to propose some solid working model here that we can base on.

We can have a separate recipient app to create a recipient.

Investigation needed if we can have 2 flavors in the single app

machi1990 commented 4 years ago

Admin creation could be MVP

Agree, we already have a recipient update view on admin side. We can continue the work there for MVP and move them to a recipient app when the time arrives.

(I might be forgetting some)

What you mean by this?

I was stating that there could be some other things that we'd like to have in the MVP.

wtrocki commented 4 years ago

I was stating that there could be some other things that we'd like to have in the MVP.

What we have above looks sensible, but it will be nice to see how we can actually work to make this useful.

Food banks can vary in their distribution methods, but they usually support a list of member organizations and maintain a warehouse of goods available for pick-up or delivery. Food banks typically receive foods in bulk and repackage them for delivery.

Volunteer might be working at the distribution center to prepare parcels etc. We might bring that as new type of action. I guess we cannot have enum - actions should be defined in the database.

machi1990 commented 4 years ago

I was stating that there could be some other things that we'd like to have in the MVP.

What we have above looks sensible, but it will be nice to see how we can actually work to make this useful.

Yes, looks reasonable for a MVP and we can always refine later.

Food banks can vary in their distribution methods, but they usually support a list of member organizations and maintain a warehouse of goods available for pick-up or delivery. Food banks typically receive foods in bulk and repackage them for delivery.

Volunteer might be working at the distribution center to prepare parcels etc. We might bring that as new type of action. I guess we cannot have enum - actions should be defined in the database.

So actions are already defined in database, what you actually mean is ActionType, which indeed could be anything by looking at your example. Also, I suppose it was there to define a scope hence the usage of an enum?

wtrocki commented 4 years ago

We have enum for 2 action.actionType:

This is too restrictive. We might need db for this rather than enum

machi1990 commented 4 years ago

We have enum for 2 action.actionType:

  • Call
  • Delivery.

So yes, we are talking about the same thing.

This is too restrictive. We might need db for this rather than enum

Agree, this could be just be persisted as a string, are we thinking of the same thing?

wtrocki commented 4 years ago

Yes. It should be possible to have it in the database

machi1990 commented 4 years ago

We need to formalize this better.

Idea 1

Action can be created in the scheduler (with some analytics added later). The scheduler will be able to create actions for delivery for some specific timeslots (once per day for the next 2 weeks or something like it). When actions are created they can be then accessible using the + button in the volunteer app. Volunteers can pick actions themselves.

Pros

  • Instant access to actions

Cons

  • Will not work in real-life scenarios: People can declare work but never do and do not deliver

Idea 2

I think might be more realistic is that people are getting 2 phase actions. First, they need to collect goods from the distribution center that is closer to them - auto assignment should happen on app level. When they arrive at distribution center then they are approved to deliver daily (ther is no way to pick up actions for more than a day - single day use

I guess it will be nice to research ways those initiatives operate to propose some solid working model here that we can base on.

Yes, also would good to see what other think of the two ideas.

We can have a separate recipient app to create a recipient.

Investigation needed if we can have 2 flavors in the single app

Why would we need 2 flavours?

wtrocki commented 4 years ago

Action can be created in the scheduler

I thought about it over the last days and it sounds cool but it brings serious problems around the availability of products and volunteers. If we schedule things automatically but we actually do not have products volunteers can drive to the distribution center and stuck without any delivery.

I have reached out to the couple of charities to give us info about the process. Still waiting. I think if we come up with distributed approach - where volunteer goes to the distribution center first - he logs there and get information about the current status of deliveries for the day. Then gets tasks view to deliver some goods.

Why would we need 2 flavours?

Recipient, Volunteer

Recipient can confirm that things were delivered etc. to track if volunteers do it.

Admin can still track progress. See stats, incidents etc. That will be easy to start with and incredibly flexible to extend./

machi1990 commented 4 years ago

If we schedule things automatically but we actually do not have products volunteers can drive to the distribution center and stuck without any delivery.

Yeap, we'll need some kind of minimal human intervention that's why I'll go for something a simple workflow:

I have reached out to the couple of charities to give us info about the process.

Thanks for the initiative. I am researching on how some charities /foundations work to see if we can refine some of the flows we have seen so far.

Recipient can confirm that things were delivered etc. to track if volunteers do it.

Admin can still track progress. See stats, incidents etc. That will be easy to start with and incredibly flexible to extend./

Yes. It may give us a starting point.

wtrocki commented 4 years ago

Recipient express a need (in form of preferred products?)

That is ok, but we cannot create action from this because - We do not know if products are there. We do not know stock information. Phisical products at the distribution center might be already taken by other volunteers etc.

Volunteers can view created tasks, and can pick task depending on their locality (zero intelligence on the app for now)

Locality to distribution center or recipients? This can be confusing as you can pick local people but you still need to go to the distribution center to collect this.

On the admin side, we can have assign task - task status is changed to ASSIGNED

What this means

A recipient/admin can approve a completed task - another status? APPROVED

Admins have zero time to monitor or approve tasks. The actions should be limited to scale this towards multiple volunteers.

wtrocki commented 4 years ago

I thought about it and I think there are challenges on building two use cases at once - with completely different workflows. We need to specialize on one.

Phone calls the only system

Phone calls are way different than actual delivery and we will struggle to incorporate both into this case. With Phone calls it is easier to engage.

Picking only phone calls resolve many issues and can help us to focus on simple workflow. For that we do not need to have map. Volunteers can pick up actions and action them almost instantly.

With Phone Calls/Chat this becomes really and glorified voice service with simple delivery. All we need is just number to person (or whatsup or anything).

Social problems of these solutions

If we provide platform like this that shares people phone numbers it will possibly exploit them for the potential abuse.

Recieving call from stranger can be hard thing that not many people will go with.

Voice communication has very limited impact on person wellbeing and in some cases it can contribute to even worse situation.

We do not have specified how receiving call from volunteer can help without giving volunteers some training and preparation. If that is happening then we have SOS helpline type of charity with standard ticketing system doing the most of the job.

Delivery only system

This was covered in the ideas above. Generally delivery system doesn't differ from the classical parcel delivery the only difference is that you get goods for free in more unpredictable unplanned fashion.

With only goods delivery (usually long date products, vouchers, clothing) we are getting and classical distribution problem with the issues with volunteers need to be more attached to the task. What I mean here is that if we pick this we need to make certain assumption - to become volunteer you need to be vetted or something like it, because there is just too many corner cases here.

With distribution problem (Your Location -> Hub -> Hub -> Recipient) volunteers can sign in into it.

Problems of this approach

I have though that we trying here to be too generic thus it is hard to settle on something really useful. If we provide Volunteer capabilities of the donors they can actually deliver food to the distribution center and then other volunteers can distribute it. Admins can monitor stats etc.

machi1990 commented 4 years ago

I have though that we trying here to be too generic thus it is hard to settle on something really useful. If we provide Volunteer capabilities of the donors they can actually deliver food to the distribution center and then other volunteers can distribute it. Admins can monitor stats etc.

I agree with you, since it is an MVP let’s focus on one particular use case and do it properly while at the same time being able to test the capabilities our the stuffs we are building.

I think the way we build would make it easy to add more features / use cases later.

To keep us focused these are the things we'd like to see to tackle for the MVP:

The use case we’ll to address is delivery of essential products for people in need, especially in time of crisis (think of Covid). This is an interesting use case as it will permit us to really explore some of the features we have recently developed in Graphback while solving an actual problem. While addressing this use case, we have an assumption that the volunteer are properly trained and we’ll be able to to the tasks they are assigned to do - this is based on trustworthy model.

What we have:

- The client side in a working state barring a couple minor adjustments
- CLI support
- Some business models that needs refinement
- A set of React components which is a good base to build the rest.
- Dockerfile and OpenShift templates
- And mostly a plan for the MVP

What’s needed for MVP.

- Review the business model and remove all the things we do not want, keep models highly focused on the use case we want to solve. Done - https://github.com/aerogear/OpenVolunteerPlatform/pull/61
- Updates and develop forms to address the CRUD capabilities we need.
- We already have CLI support, see if anything else is needed
- Fine tune the OpenShift templates so that it is OVP specific. See https://github.com/aerogear/OpenVolunteerPlatform/pull/65 which addresses the point initially. I think it will be completed once we have published a docker image of OVP. 
- Update graphback to latest dev release.
wtrocki commented 4 years ago

All good!

machi1990 commented 4 years ago

What’s needed for the MVP.

- Review the business model and remove all the things we do not want, keep models highly focused on the use case we want to solve.
- Updates and develop forms to address the CRUD capabilities we need.
- We already have CLI support, see if anything else is needed
- Fine tune the OpenShift templates so that it is OVP specific
- Update graphback to latest dev release.

Is it necessary to open an issue for each of these things? I'd say no, but wanted a second opinion on this.

wtrocki commented 4 years ago

Is it necessary to open an issue for each of these things?

It is up to yourself. I would personally just do quick wins without issue and then review the list once we have more people working on it. We have nice smooth and simple plan which is the most important here

machi1990 commented 4 years ago

To keep us focused these are the things we'd like to see to tackle for the MVP:

  • Build crud capabilities via forms and possibly Maps in admin app

Mostly, done.

  • Enable RBAC

Needs to be added after we have a aplha release of the authz plugin. https://github.com/aerogear/OpenVolunteerPlatform/issues/74 is tracking this issue.

  • The app needs to work offline (not required for the admin app) and to be more COVID-19 related,

Reverted in https://github.com/aerogear/OpenVolunteerPlatform/pull/70#event-3352315228 after some problem during updates. Can be quickly enabled once we have the offix schema plugin.

  • Easily deployable in OpenShift

Needs checking after https://github.com/aerogear/OpenVolunteerPlatform/pull/65, will see how we can deploy the app in openshift. This may probably bring this https://github.com/aerogear/OpenVolunteerPlatform/issues/47 into action.

Next on plate:

1) https://github.com/aerogear/OpenVolunteerPlatform/issues/77 2) https://github.com/aerogear/OpenVolunteerPlatform/issues/80 3) https://github.com/aerogear/OpenVolunteerPlatform/issues/78 4) https://github.com/aerogear/OpenVolunteerPlatform/issues/79 5) Create more data using the CRUD capabilities we have in the admin and see the results in client app. Partially done, but we'll need data about distribution centre in a radius of 40-60km. 6) Openshift deployment and refinement of the Dockerfile (it can use some love).

wtrocki commented 4 years ago

Closing. Amazing job @machi1990