Allow queues to be sorted by times student was helped during session

[manavgabhawala]

It would be really useful to expose a setting to class/queue admin panels to allow the queue to be sorted by more than just the timestamp, using for example a count of the times the student has been helped during that office hours session. (Sessions can be automatically calculated from queue open to queue close).

The way this would work is each student/group will have a counter associated with the number of times they have been helped since the queue was opened. The queue will then be sorted first by number of times they have been helped and then by timestamp instead of just by timestamp. (Alternatively, instead of sorting by number of times it could just be a check for 0 vs more than 0 times helped. This could be an additional setting exposed if its deemed useful.) This will have a number of very useful side effects for OH. Finally, this number can actually be exposed on the queue so that students can see how many times they have been helped during that session. Of course the counters will reset once the queue is closed.

Firstly, this will discourage students from just jumping onto the queue until they really have something to ask thereby saving instructor time from having to go to students who don't really have a question, which could also work well with #85.

Secondly, this also helps instructors prioritize students who have never been helped at OH during that session which is one of the reasons the group feature was useful.

Finally, this would also solve #102 in a more transparent fashion to students as they don't need to think about different parameters, but would simply just know that requesting help multiple times reduces their priority.

[mterwill]

I'm a little concerned about the implications of sorting by anything other than timestamp.

Say I'm a diligent student who arrived early to office hours because I need a lot of help. I patiently roll through the queue three or four times.

Then, a continuous stream of people show up 30 minutes before office hours end. My request is starved at the bottom of the queue. I don't get helped. That doesn't seem fair.

Perhaps "number of times helped this session" would be better served as an indicator (see #84).

[mterwill]

but would simply just know that requesting help multiple times reduces their priority

sounds like it's penalizing students for having questions, which doesn't really seem in the spirit of office hours. I understand the challenge for big courses like 482 – hell, I was guilty of throwing myself back on the queue right after I got a question answered too. It was the only way to actually get helped. I agree there's a problem, I'm just not convinced this is the right solution.

[manavgabhawala]

Say I'm a diligent student who arrived early to office hours because I need a lot of help. I patiently roll through the queue three or four times. Then, a continuous stream of people show up 30 minutes before office hours end. My request is starved at the bottom of the queue. I don't get helped. That doesn't seem fair.

I think that seems fair, if you have been helped 3 or 4 times already during a particular OH session, I would give priority to students who have not been helped at all (but came late to OH say if for example they had a class during the start time of OH). Notice, this isn't persistent beyond a particular session. If it were a semester counter I could see this argument being valid because we don't want to penalize students for going to OH often, but for an especially crowded OH session it definitely makes sense to prioritize someone who hasn't been helped rather than someone who has already been helped. This would also help encourage more students to come to OH imo because students will know that even if they might be late to OH they have a good chance of being helped quickly without having to wait behind a really long line of students that have already been helped.

sounds like it's penalizing students for having questions, which doesn't really seem in the spirit of office hours. I understand the challenge for big courses like 482 – hell, I was guilty of throwing myself back on the queue right after I got a question answered too. It was the only way to actually get helped. I agree there's a problem, I'm just not convinced this is the right solution.

If you look at the flip side of this argument, we are currently penalizing students who come late to OH for simply not being available at the beginning of when OH started because they have to potentially wait behind a queue of students who have already been helped once.

Of course this should not be the default, but should be customizable and be an option for instructors to decide (I can definitely see this being useful in large course and less so in smaller ones). Its also especially useful because a lot of times OH are technically over but as an instructor I cannot leave in good conscience if there have been students that have been waiting for more than an hour (this happens a lot in big classes). If I knew I had already helped al the students on the queue, it will be easier to close the queue without having to clearing it.

[mterwill]

Waiting in any line is a function of capacity and time – both predictable factors. In my opinion a priority queue introduces too much variability. Students plan based on how many requests are ahead of them and I don't want to break that model.

I do agree the metric is useful for judgement calls like you mentioned above. I would like to revisit this once we have the ability to display additional information alongside requests.

[pmchen]

As an instructor, I would like to prioritize students who haven't had an opportunity to be helped over those whom I've already helped. That seems fairer to me.

The current system encourages everyone in the room to put themselves on the queue, and that degenerates into needing to check with everyone in the room to see if they have a question or not.

Ordering by timestamp is not particularly meaningful when students can add themselves onto the queue electronically.

[MiloATH]

I'm not entirely certain where the community stands on this topic. I've been working on a possible implementation. Currently, the feature allows for sorting by the number of previous resolved requests. There are likely some bugs as I don't know of a good way to test with multiple users. See the ordering SQL section. Is there a good way to test with multiple users locally?

I think it could significantly help with managing the size of office hour queues. However, I'm unsure if the number of previous resolved requests is the best metric by itself. If I've been waiting in queue for 2 hours, I would be irked if people kept jumping me. However, I do believe the number of previous resolved requests is an important metric.

In particular, it is common for a queue to open and >15 people to join in the span of 10 minutes. I think if two people join within 10 minutes of each other, then it makes sense to sort by the number of previous resolved requests. Does this seem like it might be a good compromise? If so, I think this could be implemented by adjusting the GROUP BY section of the ordering query.