# Campus visits

## Overview

In the Math and CS Department, the current workflow for campus visits works as follows.
 1. The department secretary receives a campus visit request from the campus visit office.
 1. The secretary sends an email to the computer science professors asking if someone could take the visit.  Information pertaining to the visit is included in this email (prospective student's name, anticipated major, hometown, date of visit, and possible times that could be scheduled that day).
 1. Professors email back saying that they can take the visit (or not) and at what time.

The main problem is with the last step.  Professors will often delay in responding, for a variety of reasons.  For example:
 - A professor might be *technically* available for a certain day, but it would be hectic to fit it in so they would rather someone else take that one.
 - Professors might delay in responding, reasoning that if they delay then someone else will take it.
 - A professor might not be able to take the visit, but won't actually respond saying so.

This results in the secretary having to send multiple emails asking for someone to take the visit, and/or the CS chair polling the secretary to see if a visit is taken yet.  When an incoming student doesn't know if they will be meeting with a professor it sets a bad impression, especially for those who travel great distances for the campus visit. 

## System expectations

We would like a system to address the following:

- There should be some way of encouraging a balance between the number of visits assigned to various professors (perhaps there should be a record of number of visits taken, etc.)
- We expect a quick turnaround time, so that the student has confirmation of which professor they are meeting with in, say, within a few days of the visit info coming to the department secretary.
- The system should eliminate the need for the secretary to nag and for the CS chair to keep polling to see if visits are taken or not.
- Address the "social loafing" problem by managing better communication between the professors (for example, some quick and convenient way of expressing "I can do this visit if nobody else is available, but I would rather not").  The system may take this information into account when sending auto-notifications to the faculty.

## Entities

- Users
    - *Coordinator* (boolean) - true iff the user coordinates between CV office and faculty.
    - *Admin* (boolean) - true for superuser priviledges, such as creating and deleting users.
    - *Guide* (boolean) - true iff the user can do campus visits for Computer Science.
    - *Unavailable times* - (for guides only) a weekly schedule of regularly unavailable times for campus visits
- Visits
    - *Visitors* - a list of people in the visiting group
    - *Possible times* - a list of time intervals in which the visitors are available on the visit day
    - *Day* - a calendar day for which the visit has been scheduled of the campus visit office 
    - *Decided time* - a time at which the guide has agreed to meet for this visit
    - *Decided guide* - the guide which has agreed to conduct this visit
    - *Status* - the current status of this visit:
        - *Proposed* - created by the CV office, but no guide assigned
        - *assigned* - a guide has agreed to do the visit, at a decided time
        - *completed* - the guide has conducted the visit
        - *cancelled* - the visit has been cancelled before it could be conducted
- Visitors
    - *Role* - the type of visitor: prospective student, parent, or guest (other).
    - *Antipicated start semester* - the start semester, as reported by the CV office
    - *Antipicated majors, minors* - desired major(s) and minor(s), from the CV office
    - *Type* - category (for prospective students only): high school, transfer, or non-traditional
    - *Hometown* - name of city and state of origin
    - *Notes* - other information pertaining to the visit that should be made known to its guide
- Committment - the level of committment expressed by a given guide for a given visit 
    - *Level* - possible values for involvement are: unknown, cannot, prefer not, can do, will do

![UML Diagram](uml.png "Entity relations")

## Events



TODO: Have conflicts reported by the system if detected.