# Tutoring Center

The CS department runs a drop-in tutoring center staffed by undergraduate tutors who have already passed the courses they cover.
This area tracks who tutors what, when the center is staffed, who shows up, and what they came in for.
The point of collecting it is that the department currently decides tutoring hours by guessing, and the data to decide better can be collected when students walk through the door.

## Use cases

- A student applies to tutor, selects the courses they have passed with a B or better, and the coordinator approves some subset of those courses.
- The coordinator builds a staffing pattern for the term: which hours the center is open, and how many tutors are needed in each block.
- A tutor claims two three-hour blocks a week and is told they conflict with a block they already hold.
- A tutor cannot make a shift, releases it, and another tutor qualified for the same courses picks it up.
- A student walks in, checks in at a laptop by the door, names the course they need help with, and is queued.
- A tutor closes out a visit and records what the student was working on, chosen from a short list rather than typed freely.
- Six students arrive for one course at once and only one tutor covers it, so the queue grows and the wait is recorded.
- A student checks in for a course that no tutor on shift covers, and the system says so rather than queueing them indefinitely.
- The coordinator looks at last fall's traffic before deciding this fall's hours.
- At the end of the term, the coordinator reports total visits and hours per course to the department head.

## Proposed queries

- Which tutors are approved for CS 240, and which of them are on shift right now?
- Who is scheduled in the center on Tuesday afternoon this week?
- How many students visited for each course last term, by week?
- What was the average wait at each hour of the day, and where does it exceed fifteen minutes?
- Which courses generate visits that no scheduled tutor is approved to cover?
- How many distinct students used the center at least three times, and how many came once and never returned?
- Which shifts went unclaimed in the two weeks before an exam?
- How many hours did each tutor actually work, as opposed to sign up for?
- Does traffic for a course spike in the week before that course's exams, and by how much?
- Do students who visit the center more than five times in a term pass at a different rate than those who never come?

The last question cannot be answered from this area alone, since grades belong to the plans area.
It is listed anyway because it is the question the department head will ask, and it shapes what needs recording.

## Proposed tables

- **tutor**: one row is one student approved to tutor, in one term.
- **tutor_course**: one row is one course one tutor is approved to cover.
- **shift**: one row is one recurring block of staffed time in a term, such as Tuesdays 2:00 to 5:00.
- **assignment**: one row is one tutor claiming one shift.
- **absence**: one row is one occurrence of a claimed shift that the tutor released or missed.
- **visit**: one row is one student arriving at the center on one day for one course.
- **visit_topic**: one row is one topic recorded against one visit, since a visit may cover more than one.
- **topic**: one row is one item on the short list of things students come in for.

We are unsure whether `absence` should be its own table or a status on an occurrence of a shift.
Modeling it separately assumes shifts recur and occurrences are implied; the alternative is to materialize every occurrence of every shift, which is many more rows but makes attendance a simple lookup.
Both readings are defensible and we would want to see the queries before choosing.

## Boundaries

We need to read `course` and `term` from the core schema, and `student` to know that a check-in matches a real person.

We would like to read room information from the scheduling area, since the center occupies a room and rooms have capacity.
Because a team's tables may not reference another team's tables, we store the location as our own text field and treat scheduling's room inventory as something we may query later but never point at.

We would like to read completed courses and grades from the plans area, both to verify tutor eligibility and to answer the last question above.
Neither is possible before GP4, so tutor eligibility is recorded as an approval by the coordinator rather than derived.

Advising may eventually want to know that an advisee is a frequent visitor.
We expect to expose visit counts per student and nothing more detailed, since what a student came in for is not something an advisor needs.

## Assumptions

We assume a visit belongs to exactly one course even when the student has two problem sets open, and that the second course is captured as a topic rather than as a second visit.
We assume tutors are approved per course rather than per subject, and that approval does not expire between terms.
We assume the center does not take appointments, only drop-ins.

Three questions we cannot answer ourselves:

1. Does a student who leaves without being seen count as a visit?
2. Should the system prevent scheduling someone during a class they are enrolled in?
3. Who owns the topic list, and how often does it change?

## Out of scope

Payroll, because tutors are paid through a university system we cannot touch.
Appointment booking, because the center is deliberately drop-in and adding appointments would change how it operates.
Tutor performance evaluation, because collecting it would change the relationship between tutors and the students they help.
Online or asynchronous tutoring, because the center is a physical room and the check-in flow assumes someone walks in.
Any link to course grades beyond counting visits, because the analysis is worth doing and the plumbing is not ours.

## Team members

**Chris Mayfield** is a Professor of Computer Science at James Madison University.
His research focuses on CS education and faculty development at the undergraduate and high school levels.
He recently completed two NSF-funded projects: one that studies student engagement in CS1 ([2216454][1]) and one that supports high school CTE teachers ([2219770][2]).
He received a Ph.D. in Computer Science from Purdue University and bachelor’s degrees in CS and German from the University of Utah.

[1]: https://www.nsf.gov/awardsearch/showAward?AWD_ID=2216454
[2]: https://www.nsf.gov/awardsearch/showAward?AWD_ID=2219770