Small Class Handling

[patudom]

Logic behind changes we just made:

• To advance to Stage 4, we want students to have at least 12 classmates (that's the gate condition to pass the Stage 4 waiting room).
• To have padding for absent students, we are making the small class condition be 15 students (Update small class size from 12 to 15 cds-api#156).
• To allow for weird edge cases, we are letting the teacher override the waiting room via the portal/dashboard and treat their class as a small class.

Expected class size

• Allow teacher to specify during class setup the expected number of students in the class - update db table (addressed in Add expected size to class cds-api#151)
• Allow teacher to specify during class setup the expected number of students in the class - update portal UI (addressed by Updates to item creation cds-portal#17)
• If expected number of students is <= 15, set small class flag to true - update db table (addressed in Add small class flag cds-api#152)

Asynchronous or synchronous

• Allow teacher to specify during class setup whether the data story will be synchronous or asynchronous - update db table (already exists in database, allowed via endpoint in Allow creating asynchronous class via endpoint cds-api#153)
• Allow teacher to specify during class setup whether the data story will be synchronous or asynchronous - update portal UI (addressed by Updates to item creation cds-portal#17)

If class is asynchronous, when students get to Stage 4:
Per conversation on 10/29/2024:

• Treat asynchronous classes the same way we treat small classes (so everyone in the class will get joined with the old class; not just the first 15 students - that simplifies our code and it makes the teacher dashboard make more sense.

- [ ] The first 15 students who complete velocity & distance measurements will see measurements from whoever in their class is already done, plus measurements from another class that we are showing them (without actually adding them to the other class).
- [ ] The 16th student & beyond will just see their class.

If class is synchronous:

• and N > 15, handle as a normal class
• and N <= 15, handle as a small class

Possible extras:

• Keep a list of the student IDs whose data is being showed to each student, so we can display them in the educator dashboard.
• Provide a "time out" feature where if a kid has been waiting for too long, we pop up a message to ask the teacher to check how everyone is doing; if they are not going to be able to meet the conditions to proceed, the teacher can do an override from their dashboard. Or we can just put a guideline that says to ask teacher for permission to proceed and then they can just hit next.

- [ ] If a certain amount of time has passed, give student the option to decide to proceed with a different class (If 1 student proceeds with a different class, we would want everyone to proceed with that same extra class; it doesn't make sense to give any random student that much power. Instead, we will let the teacher decide to override from the portal or dashboard).

Scheme for handling classes in db:

• Class summary data is pulled from db.
• Make sure "my class" is not included in data pulled from db. (in case "my class"'s age got generated by script overnight).
• Calculate my class age manually & add that to the classes histogram data.

Scheme for handling merged classes in db:

• Class summary data always shows the age for the union of the merged class data (so prior classes that got merged have their age overwritten in the db by the merged class's age value).
• For an active class, when all classes data are pulled from the db, filter out ages associated with my class and the class I was merged with.
• Calculate age for (my class + merged class) & add that to the classes histogram data.
• If we "run out" of classes to merge, we can add a 3rd class to previously merged classes and replace the age in the summary data with the age for the union of the 3 classes.