# RFC Template

<!-- _All sections of this template are REQUIRED. If you feel a section doesn’t apply, simply put “N/A” under it._ -->

## Background

https://docs.google.com/document/d/1cvlJLuucFMTWM5XXrcPqt2unfDz6cATBZbATc6-4nFc/edit#heading=h.ioz3r...

https://docs.google.com/document/d/1yIDSTTnnT0oeN5l2DGKdHNjByo7j-vOGlf1mWiw6kC8/edit#heading=h.9du41...

https://miro.com/app/board/uXjVP-heUYM=/

New Rudder Deployment

- tags to route users/mentors to the right place
Three hour blocks for mentors. 2 or 3 at a time.
Leaning towards data science only.
Open the queue before the mentors arrive.
- we would need to override our check for no mentors/office hours as a deployment setting
Disable wait time/position being shown while outside of office hours
One AR at a time (maybe multiple in the future)
Email notifications
- we would need to adapt from IRCC
Intake form
- may need to remove/hide some questions
Adding one or two if statement questions to feedback
- keep existing questions, this would be in addition too
-

<!-- _Brief description of a problem you're trying to solve. Link to product brief / Figma / etc._ -->

### Problem Descriptions

1. Learners should be able to submit Assistance Requests before the queue opens
2. Assistance Request and Feedback forms should be able to have different questions in the case of a pre-queue request
3. An email should be sent out to the learner a certain number of hours after their request is finished to remind them to submit feedback
4. All of the above changes should be configureable via deployment settings

<!-- _Concise overview of potential solutions._ -->

## Concise Problem Solutions

1. Remove "Queue Closed" assistance request button blocker from frontend
2. Forms:
- (Assistance Request form) Check upon opening request form if queue is closed and display form fields accordingly
- (Feedback form) Check upon opening feedback form if the request was submitted outside queue hours and display fields accordingly
3. Upon finishing an assistance, create a delayed job to send reminder email to learner
4. Create new deployment settings for the following variables: whether or not requests can be submitted before queue opens, how long to wait after assistance request is finished before sending feedback reminder email

## Prior Art/Research

<!-- _Research beforehand on how problems in this domain have been solved elsewhere in the tech world. Include links to relevant papers, blog posts, or other research that would be helpful to understand how this problem was solved, or any parallels between other problems in this domain and the current problem._ -->

### P2P

A similar problem to the pre-queue assistance requests mentioned above is being worked on currently. In the PRP initiative, one goal is to make it possible to submit an assistance request without it finding its way into the queue immediately. [PR for P2P RFC](https://github.com/lighthouse-labs/tech-docs/pull/31)

## Stakeholders

- Eng authors/owners: Harry Lowson
- Sponsor(s):
- Quinn
- Iksung
- EM/PM: June Sapara

## Definitions and Acronyms

- **PPS**: Post-Program Support - a Rudder initiative that aims to provide students support _after_ they finish an LHL program
- **AR**: Assistance Request - A request for assistance submitted by a learner using Rudder
- **The Queue** - where ARs can be tracked / managed by mentors on Rudder
- **Pre-queue AR** - An assistance request that's been submitted before the queue is open

## Useful Discoveries

- Sidekiq workers have a `perform_in` method which schedules a job a certain number of minutes/hours/months from current time -> [SO](https://stackoverflow.com/questions/44921116/how-can-i-use-sidekiq-delay-with-a-worker)
- There's also a `perform_at` method
- Names of the new fields in the AR form will have to be added to request params

# Proposal

<!-- _How do you propose to solve the said problem?_

_Please include a diagram if relevant_ -->

## Workflows/Scenarios

<!-- _For the non-trivial workflows (e.g. CRUD in the UI doesn't need to be covered unless it triggers non-trivial downstream actions) describe their general workflow, e.g._

1. Input comes from service A
2. Calls service B with args xyz
3. Etc.

_The purpose here is to communicate overall data flow through the system and also reason about failure scenarios between each step. E.g. if call on step 2 fails, how do we know/recover/etc._ -->

### Request form is filled out before queue opens

In the frontend, "Queue Closed" will now indicate that certain questions are to be used in the request form, rather than disable the request button (depending on deployment setting `features`.`request_submission_outside_queue_hours`)

1. Learner clicks "Request Assistance" button
2. "Queue Closed" variable checked to determine which fields to present
3. Hard-coded fields presented to user

### Request is submitted before queue opens

The interactors in the `RequestAssistance` will have to be searched for any action involving a `queue_task`, and then these actions will have to be separated out into a different interactor(s). I suspect this will be the trickiest part of the MVP of the PPS feature

1. Assistance request created like normal
2. Actions involving queue tasks, i.e., creating tasks and assigning them to mentors, are delayed until the queue is open
3. All other Request Assistance actions happen as normal
4. When queue opens, status of AR is checked before activating queue task actions (perhaps peers helped, recommendations helped, learner cancelled, etc.)

### Learner is sent feedback reminder email

1. When an assistance is finished, the `features`.`learner_feedback_reminder_email_enabled` deployment setting on relevant AR is checked
2. If the feedback reminder email feature is turned on, `features`.`learner_feedback_reminder_email_delay` is checked to see how long to wait before feedback reminder email is sent out
3. Delayed job created to send email created by `LearnerMailer`

### Feedback form for pre-queue AR is filled out

I'll add a field in the `AssistanceRequestSerializer` for whether or not the request was submitted within the queue hours. That way, it can simply be looked up in the frontend.

1. `assistanceRequest`.`submittedOutsideQueueHours` checked
2. Appropriate hard-coded form fields are shown to the mentor/learner

## ERROR flows

<!-- _What do expected/common error flows looks like? i.e. if there is a common user flow that could happen that would end in a non-happy state, how is that handled?_ -->

- Request submission outside queue hours enabled but queue schedule doesn't exist or hours are null so calculation of whether or not queue is open fails (more like an anticipated bug than an error flow)
-

## Schemas

<!-- _This section describes the data (types/schemas) that will be stored both on disk (see New Database tables section) and sent between systems (see Service Endpoints/Schemas section). Also any external partner schemas (data sent to 3rd parties, received from 3rd parties)._

_It's also helpful to *include specific examples*, e.g. a typical row in this table/typical call in this JSON looks like x/y/z, as the concrete example will help readers quickly graph what the designers are intending (more than just type declarations can do, as awesome as type declarations are)._

_Having ~one section/database or per service is generally fine, unless your doc is smaller._

_The fidelity here is not perfection/this should never change, nor “is this a long or an int” scrutiny of types, but enough detail to show the flow of data between systems with a general notion of what the messages/payload are, and how how messages/payload change with the major boundary cases._ -->

### New deployment settings

- `features`.`request_submission_outside_queue_hours`: Boolean - if `true`, learners will be able to submit requests before the queue opens. Defaults to `false`.
- `features`.`learner_feedback_reminder_email_enabled`: Boolean - if `true`, an email which reminds the learner to provide feedback on the assistance is sent out after the assistance is finished. Defaults to `false`
- `features`.`learner_feedback_reminder_email_delay`: Number - the amount of time (in minutes) to wait after an assistance is finished before sending out the feedback reminder email. Defaults to `180`

### New Assistance Request columns

Two new columns will be added to the `assistance_requests` table:

1. `submission_queue_start`: the time the queue was scheduled to start on the day THIS REQUEST was submitted
2. `submission_queue_end`: the time the queue was scheduled to end on the day THIS REQUEST was submitted

These columns will be used in an `assistance_request` model method that indicates whether or not the AR was submitted outside queue hours. I'm favouring this approach over simply saving a boolean on the AR that indicates the same thing because the `submission_queue_start` and `submission_queue_end` columns could provide useful insights about the AR after it's been submitted, and although the `queue_schedule` record might contain the same information, it could also be changed after the AR is submitted.

### New Feedback columns

There will need to be new Feedback columns for the new feedback fields. Not sure how these will look yet.

## New Database Tables

<!-- ### Table name

| Name | Type | Description/Notes |
| -------- | -------- | ------------------ |
| name | varchar | name of user |
| age | smallint | age of user |
| approved | boolean | can this user post |

Operational info:

- What new/existing database/database cluster will each table be in?
- If doing a new database/cluster, include rationale vs. existing databases/systems
- Are there any columns that will be obvious high-volume queries/indexes? -->

N/A

## New Service Endpoints/Schemas

<!-- _This section should cover any new endpoints being added to existing or new systems._ -->

N/A

## APIs (If Needed)

<!-- If your RFC covers a new library, e.g. tracking or rate limiting or what not, describe what the actual proposed API looks like, e.g. with class/method names/parameters. -->

N/A

# Considerations

## PRODUCT considerations

<!-- What should the behavior be for various types/groups of users? e.g. LHL program students vs external clients. -->

N/A

## Data considerations

<!-- Check in with ?someone from data team? about potential implications on the Data team (e.g. is a data brief needed). If you have any specific questions then list them out. -->

- Anyone from data see any issues with the two new columns mentioned in the Schemas section?
- Data should be notified about the new feedback columns for dashboard purposes.

## Security & Privacy considerations

<!-- These questions should remain at a fairly high level since they are intended to help determine whether a more focused security/privacy review is actually required, and if so, in which areas. -->

N/A

## High-Level Security Exposures

<!-- Check any that apply and tag ?people?

Does the new product/feature involve making changes or adding new solutions to/for any of the following below?

- User Management
- Authentication
- Authorization (i.e. User Role Permissions)
- Data Confidentiality
- Accountability (Audit Logs)
- Session Management
- API’s or Data Exchange
- Storage solution for PII
- High-Level Privacy Exposures

Does the new product/feature involve making changes that could raise any privacy concerns such as:

- Does this exposes PII to anyone other than the person it describes?
- Could it increase the amount of information displayed about an individual?
- Are we sharing new or more data with an external service/company?
- Will we collect any new types of PII/Personal Data for this product?
- Other -->

N/A

## Performance considerations

<!-- What SLAs does this service:

- Provide to others? How many requests/sec are expected? What is general latency?
- Expect from others? How many requests/sec will be sent to downstream services? What is the general latency expectation?
- Can you dark launch to evaluate read & write patterns/reliability before launching to users (separately from a user-facing feature flag, e.g. ideally you could dark launch to 100% before even beginning a feature flag rollout)?
- Will this need a more formal ops-review? -->

N/A

## Cost analysis

<!-- _Will there be any incremental costs associated with this feature/service? Is there a forecast and have you let SREs know?_ -->

N/A

# LEGAL

## COPPA / U13

<!-- Does this new product/feature need any special consideration for under-13 users? Describe how it will be handled. Reminder that u13s require special treatment by law.

- FERPA
- GDRP
- ISO 27001 -->

N/A

# Outstanding/Blocking Questions

<!-- Section for RFC Author and reviewers (EMs/PMs/others) to flag issues as specific questions that they think need resolution.

- Person: Question/concern...
- Person: Question/concern... -->

1. Should pre-queue ARs be piggybackable? I assume yes, but thought I'd ask...
1. Same question for notifying peers about these requests. Same assumption (yes notify them)
1. What's a good default delay time before sending out the feedback reminder email?

# Followup work

<!--
_Should anything else happen after the proposed solution is implemented (code, data cleanup, etc.)_ -->