Because it was rushed, we implemented the APIs are purely JSON-encoded GET requests. We should enforce POST on these requests.

If possible, we should think about adding some validation or rate limiting to the requests, so we don't get DDOS'd by some malicious actor!

Bonus: I think we have very little input sanitation for our requests. That would probably be helpful to do as well!

The matching algorithm initially wrote for this Hackathon is a bit rough. This task is blocked on the addition of organization_needs, but once that is done we should query not using LIKE rather some smarter logic, along with (maybe) built in Postgres geolocation logic.

Also we should probably come back with something as a default. No match isn't helpful, even if there's no perfect match

In addition to the "I Want to Help!" button on the homepage, it would be helpful to show an overview of what exactly is needed donation-wise. This would be a matter of scraping the JSON data and showing it as a D3 histogram or something of the sorts.

Additionally, depending on how much information we have, we could track how many of each item have been donated.

The /organizations endpoint does the job, but we should:

1. Sort by latitude/longitude relative to that of the caller
2. Paginate! Right now we're returning a huge amount of organizations in every call, if we had a browsing view we'd probably want to scroll through, so having pages would be helpful

We should finalize the NGINX setup for both local and production development. Right now the production branch needs to be rebased over master to avoid risk. But we should ensure NGINX works locally and merge the branch into master.

We should have a form through which organizations can register and submit their needs

Currently the way the UI works is such that when we enter a ZIP code and find a match, we might say "Oops I mistyped my ZIP" but we need to refresh the page to reset it. Instead it would be helpful to reset the form entirely when switching back to the ZIP code field.

One nice thing to have would be Google SEO so that we would appear in search results!

We made some good progress on a deployment script for getting our master code onto our EC2 instance, but it didn't quite pan out. We should ensure that we have a working deployment script (maybe a hook from GitHub?) that automatically runs the latest version of the codebase on our EC2 instance. Note that the server is currently running on a tmux window, so we'll likely need to play with that as part of this task.

Shannon to talk with getusppe volunteers slack channel

Right now you can still access http://crisisconnect.live. We should forward all of those requests to https://crisisconnect.live

Strangely, www.crisisconnect.live doesn't work with the www in the front of the URL. Rather only naked URLs work. We should allow www in front of the DNS locator.

Another tradeoff we made in the hackathon was to tell people where to donate. In a perfect world we would be able to forward their payments directly without having to forward them to another step.

We would likely want to leverage the Stripe/Square APIs to do this. It could be tricky finding data on how exactly to send money, but this is worth investigating.

@vasujain found some react templates that might add a bit of sparkle. @kguinto also had some ideas around using existing library components to get more nice stuff easier.

Right now the organization ID is denoted by a random 32 bit number. While this will very likely be unique, it is not guaranteed to be so. We can even just set an AUTO INCREMENT directive in Postgres instead of doing this.

I love our matching flow, and believe it's a huge part of the value of this application. But it could also be nice to have a separate view that hits the organizations/ endpoint to see organizations in your area

Some of the code structure is definitely a bit...hacky. Hence hackathon! But we should clean it up so it's a bit safer to use in production. Specifically adding directories, cleaning up imports, putting more in our config.py file, comments, etc.

We noticed during the hackathon that new developers were having a hard time setting up from scratch. This was largely due to having to manually create a database and tables.

After this task is completed, we should be able to run bash build.sh completely from scratch and have everything ready.

Right now we have no externally facing data on how many visitors on the site, how many people are clicking which button, etc.

We should add this data!

We should hit the newly created ride request from the UI and show that a car is on its way (ideally with an estimate, depending on what the API is able to come back with)

Adding Kube would be a great way to manage our container deployments as well as handle any potential scaling issues we might run into!

We should implement an API that takes in details of a Lyft ride request and sends a car to their location

The current model of modeling needs of an organization is done with a needs column in the Organizations table on Postgres. This doesn't work great when you want to have subsets or more complex matching. We should instead:

CREATE TABLE organization_needs(
    organization_id int PRIMARY KEY NOT NULL,
    need string NOT NULL
);

And we should also drop the needs column from the Organizations table. This means we'll also need to touch up the data insertion script, and the add-organization[s] endpoints to instead insert into this new table.