# Backlog refinement

## Prepare DB for Matching:

### Import UNIV data (new unis / uni to edit / uni to delete )
#### Import from a document (new unis or uni to edit) [1 day]
* HTML page -> import uni
* API that is going to import the document and send it to the database (JS function, calls python function on server)
* Add data to the database (unify it if common keys)
#### Write information manually on the interface [1 day]
* HTML page -> add/delete/edit uni
* API that is going to send the information entered on the HTML page into the database
* Add / delete / modify data in the database
### Import STUDENTS data: (new students/ students to edit/ delete)
#### Import from a document [1 day]
* HTML page -> import students
* API that is going to import the document, check that the students meet the requirements (add a tag if not -> see NOTE) and send it to the database
* Add data to the database (unify it if common keys)
#### Write information manually on the interface [1 day]
* HTML page -> add/delete/uni students
* API that is going to check that the students meet the requirements (add a tag if not -> see NOTE) and send it to the database
* Add / delete / modify data in the database

**NOTE:** Check exchange requirements (valid wishlist) - > if not respected put a tag on the student
Check Uni requirements - > if not respected put a tag on the student
### Set matching hyperparameters (manually on the interface)
#### Weight of GPA vs Motivation letter grade
* HTML page to tweak the parameters
#### Force student into a specific uni
* HTML page to assign a student to a specific university
#### apply the parameters :
* apply button on the html page
* launch the algo with new hyperparameters

## Front-end views and descriptions, functions
### Views
* __Login__
* Something something GCP
* __Home__
* Link to matching, comparison (diff), student, and university pages
* __Matching criteria__
* Set weights of GPA and motivation for each university
* Create and remove manual matches between a student and a university
* __Matching results__
* Sort/view by all, school, zone
* Save result
* __Past matching results__
* View saved matching
* Delete saved matching
* __Matching comparison__
* Select 2 previously saved matchings
* __Student overview__
* View students with notifications of missing files, components
* Link to individual pages
* __Individual student data__
* __Add student__
* __Edit student__
* __University overview__
* __Add university__
* __Edit university__
### React Components (formatting)
* Sidebar
*

## Visualize matching (Matching results)
#### HTML page
#### JS call to backend
* fetch
*
*
#### API to fetch data (of the matching already computed by the algo) from DB
* Query for each view [1 day per view]
### Resource & DB

High priority: this part of the project sets interfaces.

1. Write JSONSchema descriptors for each resource. Those descriptors will be linked to in documentation. They are the most rigorous form of documentation.
2. Write Django models to implement the resource storage system (database, implicitly). Link to JSONSchema descriptors in docstrings.
3. Write specific documentation on each resource's methods using RFC 2119 keywords

## Diff tool for humans [3 days]
[Teo and Grey]
### Save matchings (from results page) with a name and unique ID.
- Save button. User has option to add the matching to the history.
- When saving a matching, the user can give it a name (default name is the hyperparameters)
- Delete saved? see all saved?
- Maximal history size for lisibility?
### Input 2 complete matchings for comparison
#### API: Get matching based on its ID
#### html/js: select from drop down? Go to page with all saved matchings, select 2 (or more?) to compare?
- get matchings somehow ?? (interface)
### Statistics
- Difference (absolute/relative) in input parameters
- Difference? # of #1, #2,... picks
- Number of students included on the matching
- Geographical distribution
- Output: Visualization? Histograms?

html:
diff
view/delete saved : possibly combine with diff?

db:

### JAM (Just Another Matching)

## Interface
* Every function we do will assume to have the correct input as a parameter
* The purpose of the interface is to take a request from the front end (possibly in a diff language like JS) and ‘interpret’ it and call the correct functions in the backend with the correct input.
* Do we do one general interface that deals with all functions, or one per backend function?
* I believe we should have one interface per backend function. This will make it better for us to work on it in parallel, will make it easier to test and less prone to bugs.