Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Small Class Handling #660

Open
12 of 20 tasks
patudom opened this issue Oct 15, 2024 · 0 comments
Open
12 of 20 tasks

Small Class Handling #660

patudom opened this issue Oct 15, 2024 · 0 comments
Assignees
Labels
3. next in queue Fix or implement after 1s and 2s are done

Comments

@patudom
Copy link
Contributor

patudom commented Oct 15, 2024

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). (Implemented in Add stage 4 waiting room #554)
  • 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

Asynchronous or synchronous

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:

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. (Handled in Allow omitting class when fetching all data cds-api#160)
  • Calculate age for (my class + merged class) & add that to the classes histogram data. (Handled in Add class info to all data #688)
  • 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.
@patudom patudom added the 3. next in queue Fix or implement after 1s and 2s are done label Oct 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3. next in queue Fix or implement after 1s and 2s are done
Projects
None yet
Development

No branches or pull requests

2 participants