john / drive.vote Goto Github PK

A system-wide admin page for use by DevProgress staff so we can see if ride zones are overloaded, etc.

When viewing all rides after running the Brooklyn HQ sim, you see three rows in the table, but five pins on the map. I could be misunderstanding, but I'd expect to see one row for every pin.

See /admin/ride_zones

C3 in https://docs.google.com/spreadsheets/d/1ye8kV01ss17R7Imhmkh_7pw5-aLnWpcBizKvgaCr5FA/edit#gid=0

There is now a ride-zone specific ride scheduler for voters. It creates a ride and a conversation and sends a confirming text. This is just a reminder to make sure the conversation ends up in information complete lifecycle so any text from voter goes to "needs help" and doesn't start the bot.

Be sure to use Ruby 2.3.1, and add these add-ons:

• Heroku Postgres
• Deploy Hooks
• New Relic APM
• Papertrail
• Redis Cloud

Just texted the app, which behaved perfectly--but it took me a few minutes to realize that, because when viewing the dashboard, as opposed to the modal, it's pretty subtle when a a new message has come in. This may especially be the case when the row is in 'alert' status--the red background makes it hard to read new text, which is especially an issue because that's exactly when you most need to read it.

A dispatcher will be looking at a large map UI, with pins showing locations of drivers and rides for voters. The map needs to respond to update events about each driver and ride (ride events and driver events), which will be sent via a websocket.

Implement a sample page with a map showing drivers and rides that can be manipulated via a simple Javascript API with new ride and driver information. Adjust the appearance of pins so a dispatcher can find interesting points, such as:

1. An available driver with no active ride (active_ride = null), to send them somewhere or assign them something.
2. An active ride that’s waiting for a pickup (status = "driver_assigned") with a driver assigned to that ride.
3. A ride near the scheduled time without an assigned driver (status = "waiting_assignment") .

Markers on the map should have a meaningful hover state, possibly with a tooltip.

Do this work inside public/map next to the existing Map code. Then, @geraldhuff can connect to the new code as part of eventReceived() in dispatch.js.

When creating a ride zone, allow the DtV admin to optionally create a new user at the same time, and give that person admin privileges just for the rz being created.

Cell B12 from https://docs.google.com/spreadsheets/d/1ye8kV01ss17R7Imhmkh_7pw5-aLnWpcBizKvgaCr5FA/edit#gid=0

@john Can you expand on what this means?

A small box under the map, something like:

Should use the ride zone slug, and be more human-readable. Right now it's:
/users/sign_up?zone=7

Should be something like:
/volunteer_to_drive/toledo_oh

Issue with Devise prevented this from being done initially.

It's gonna get long.

Right now our admin pages are only for internal DevPro use. We need to add an admin page for each ride zone, so dispatchers/rz admins can see their stuff, but no one else's. Admin page should include:

• An index: /ride_zone/:slug/admin
• Page for promoting volunteers with the :unassigned_driver role to have the full :driver role (see #133)

There are more but that's off the top of my head.

Question: are all dispatchers also ride zone administrators, or should they be separate roles?

Need to figure out if Rails.configuration should hold logger to make it accessible

We're on 2.2.5. I think the latest table is 2.3.1?

Would be good to at least order by proximity, but also to consider a better UI element. Currently an unsorted dropdown:

While it won't test twilio interactions, we should be able to multithread the simulator and fake thousands of simultaneous operations

Thanks!

Per discussion with @decause and others on demo call from Wed Aug 29, it's clear we need documented stats and data regarding capacity, failure modes, and threat models. Completely valid diligence.

Starting this issue to try and create a burn-down list of what stats we are collecting so we don't accidentally spend time collecting/documenting/examining the wrong thing.

Let's keep this top-level bullet as a summary burndown list and use the comment thread for discussion.

Live burndown list (anyone should feel free to edit):

• Document threat model
• Document "crisis" response plan in case of various failures
• Document how to handle DoS from malicious party (warning: may actually include APT attackers....but maybe we don't want to worry about them...)
• Measured Twillio capacity and backup plan for various Twillio failure scenarios.
• Measure geographic latency
• Understand how driver behaves under different mobile network loads.
• Understand database load. We can scale webservers easily, but the current deployment doesn't shard by ride-zone or similar which means the DB is the bottleneck.
• PM task: develop impact measurements for "surgical strike"... estimate how many more people can we get to polls in important districts.

If the definition changes for an old simulation it should gracefully handle that.

Create assets.drive.vote domain, backed by Cloudfront/S3, then create CSP policy restricting to that domain.

Would add some security, and also simplify deployment of the driver app, which is a React app (ie all client-side) which lives in a separate repo from the dispatcher app. The dispatcher app serves an html wrapper from https://drive.vote/driving, which loads the React app

But we need to have it be nullable or take a value to indicate to bot it isn't set yet

There's a lot right now, makes it hard to read the map, and the whole dispatch page.

When driver location is updated, it checks the roles table to see if the user is a driver to determine if it should broadcast a “driver updated” event

we can save a joined SELECT by storing the driver’s ride zone in the user record

this would need to be maintained on any rolify change (add/remove of roles)

We can test using the simulation for the DB layer, but it'd be good to test it black-box via http.

Do it using the AWS ElasticBeanstalk setup. Also do it on Heroku to get stats on the platform difference.

The SimDefinition yml file can define ride zone characteristics and the Simulation can create the ride zone if it doesn't exist.

Link to /users/sign_in. Needed primarily for dispatchers.

Right now the select for drivers and dispatchers loads all Users in the db. Should scope to only offer Users within the vicinity of the ride zone, maybe 100 miles.

Tracking ticket for AWS move.

Current issues:

• Who owns the account?
• How do we script machine setup?
• Let's get Continuous Deploy going.

Facts:

• Everything runs on Heroku right now.
• Heroku runs on AWS and will always be more expensive since we're paying the middle-man.
• Heroku is only free for very very small demo loads. Moving to AWS will always cost less.
• You CANNOT go to a production load (you probably can't even do a load test) on Heroku without money.
• Heroku deploys a "monolithic app" so load and scaling tests on Heroku are not representative on AWS.
• There are 2 needs for AWS: development environment (grows with number of devs) and production enviornment (grows with number of users)
• Having a ready to use, fast to set up, AWS Dev environment is CRITICAL for developing apps fast. Blocking here costs us dev time, hard. We also can't get load numbers easily for this because, well, the point of a dev environment in AWS is to generate those numbers.
• Having a prod environment should be done based on cost estimates generated fro the dev environment.

Albert hypothesis:
You likely will need 2 budgets. One for the dev enviornment that should just be some sort of flat amount that's buying freedom for the devs. The second should be for a real prod environment that's based on real number gathered from load testing on a dev environment.

You likely only want 1 AWS account (maybe 2?) and then give each group their own VPC within that account. What you do NOT want to do is create and pay for 1 AWS account per app.

Create Test plan?
Execute it?

Not sure exactly what the desired behavior is here, but drivers and voters probably need a way to communicate directly.

One option would be to display the voter's phone # in the driver app and hand off to the phones native messaging client. Pro: probably the easiest. Con(?): privacy concern of sharing numbers? Also, that conservation wouldn't be available to the app (and dispatchers)

2nd option, route everything through Twlio. Con: presumably way more work. Though I guess we could still use the native messaging app on the drivers phone, with the special number

https://drive.vote/users/sign_up. Probably api key issue with google places API.

Same as users have. Use Phony for normalization.

Right now volunteer drivers enter the system with an :unassigned_driver role. There needs to be an admin page where ride zone admins can see all volunteers, vet them in any way they want, and then promote them to the :driver role.

When blacklisted no conversation or message is created, isn't displayed in dispatcher UI. Though we may want to log SMSs from blacklisted numbers.

If an ride zone has low ride demand, high dispatch capability, and/or is seeing high abandonment rates with the bot, they might want to disable it.

Pointers:
rails g migration AddBotDisabledToRideZone
add_column :ride_zones, :bot_disabled, boolean

In twilio_service.rb ~ line 23 add a check for @ride_zone.bot_disabled

On the dispatch/show view page add a button to enable/disable the bot boolean

In api/v1/ride_zones_controller.rb add endpoint to enable(true/false) the bot which updates the DB

• Confirmation should give confirm/cancel/chat options: "Reply 1 to confirm, 2 to cancel, 3 if you have a question"
• If they cancel via text, cancel the ride.

Closely related to #150. Need to:

• Get AWS creds
• Pick tech (chef, puppet, fog, docker, etc.)
• Pick where code goes--existing repo, generic devops repo?
• Write it. More?

Use github protected branches to disable merge commit for master and production. Also force CI to be green.