search

illinois / queue

A microservice queue for holding open office hours
University of Illinois/NCSA Open Source License
82 stars 36 forks source link

Explore CBTF/PrairieLearn integration #225

Open nwalters512 opened 5 years ago

nwalters512 commented 5 years ago

The CBTF has recently started holding post-exam review sessions for some TAM courses, and this will likely expand in the future. While admission to the CBTF is currently done manually, we've been talking about building some software around the experience. The idea of using the queue to decide the order of admitting students was proposed. This issue is me exploring how we'd build that out loud.

I want to avoid building anything that's highly PL-specific. This would allow others to build interesting tools around or on top of the queue without any more additional work from us in the future. The queue is already heavily API-driven, so the scheduler (or any other service) should be able to manipulate the queue on its own. We'll need to build a token-based auth system so that we don't need to worry about sessions.

It'd be good to allow services to receive webhooks when something happens on the queue; I imagine we could send the same set of events/updates that we do via WebSocket to keep our clients in sync.

Another interesting idea I had is to allow some kind of programmatic admission control. This would allow the queue to hit an external API and ask "should this user be allowed to be admitted to the queue?" This could help us enforce policies like requiring students to have a "reservation" for an exam review session in the CBTF scheduler. This could also be useful for other courses that, for instance, want to automatically decide whether a topic is sufficiently detailed or if a student should be blacklisted from the queue.

Finally, we should look into allowing greater customization of how individual queues behave. Currently, all button labels/explanatory text/etc are hardcoded. It would be nice if we could remap labels to things that are better for specific use cases, such as changing "Start Answering" button to "Admit to CBTF", or changing the "X is now answering your question" to "Please report to a proctor to be seated".

mwest1066 commented 5 years ago

All of these items sound awesome. For CBTF external queuing in particular, the programmatic access control could be short-circuited by a "do not allow students to self-queue" option, because we'd be assuming that the scheduler is controlling all access.

nwalters512 commented 5 years ago

@mwest1066 my understanding from our talk yesterday was that students would be self-queueing. Or would the scheduler populate the queue each day with the list of students in the order that they registered for a session?

mwest1066 commented 5 years ago

I think we wouldn't want students to have to make a scheduler reservation and then to separately put themselves on the queue. It seems like it would be friendlier to auto-queue them, either when they make their reservation, or on the morning of the day of the reservation, or something. That is, I'm imagining that there is a one-to-one relationship between reservations and queue positions. Or is there another way to think about this?

mwest1066 commented 5 years ago

Another question we'd have for integration is the number of queues. The CBTF will queue students per-review-session and per-course, so on any given day there might be queues for:

10am TAM 210 10am TAM 212 6pm CS 225 6pm CS 233 (4 queues in total that are active for that day)

Is there a notion of sub-queues that would handle these separate queues, or would we need to allow an API endpoint to create (and delete?) queues, or something else?

nwalters512 commented 5 years ago

I think auto-queueing makes total sense! Hadn't thought about it like that, but that does make sense.

Queue creation/deletion already happens through API, so we wouldn't need to change anything there from the queue perspective. There isn't a notion of subqueues at the moment. I think a "big" queue per session makes sense, and then we could handle different courses/exams in there by topic. Or would there be a use case for maintaining separate queues of people per course?

mwest1066 commented 5 years ago

The current model being used is that each course is effectively a separate review session, even though several of these will be in the same room simultaneously. This is done to maintain a good student/TA ratio per course. For example, if there are 100 students queued up for CS 225, followed by 4 students queued for TAM 210, then we would want to take the first 6 students for CS 225 and all the TAM 210 students, irrespectively of their overall queue order. Otherwise the TAM 210 TAs will be sitting around with no one to help.

I guess this could be done by using one big queue per session and setting the topic to the course name, as you suggest. But this seems to defeat the point of the queue -- a TAM 210 student would see that they are number 104 on the queue and think they had time to go get some food, but then they would actually be in the very first group of students taken. Or is there a way to use topic grouping to detect that some students a long way down the queue will actually not have long to wait?

nwalters512 commented 5 years ago

Yeah, that makes sense. In that case, I imagine we could just create one queue per course/review session combo. Would the proctors need to see an aggregated view of all queues in one place? I'm picturing kind of a sideways-scrolling Trello-like thing that shows all current queues side-by-side. But would that be needed?