Greetings.
I just finished typing the first mentoring comment to a solution, with proof reading and nice formatting and all, only to be notified upon submitting that another mentor was faster.
Does the UI for mentors provide visual feedback for this situation that I did not see? If not, would it be possible to do this?
When you click the button to start mentoring, you have a 30 minute “lock” on the exercise. If you’re going to take longer, you may want to “reserve” it with a placeholder comment.
Also, it may sometimes say that it is locked by another mentor when in fact the student has withdrawn the request for mentoring. That is most certainly the case if you get the message before the thirty-minute deadline.
guilty as charged … it took me more than 30 min to find concise words for what I actually wanted to say.
But if there is a time-based reservation, how about puttings something like “this request for mentoring is reserved until HH:MM TZ” near the editor as a reminder?
Note, right below the “Start mentoring” button, there’s a footer which reads:
You have 30 minutes until the session returns to the queue for others to mentor.
But, yes, that doesn’t show a concrete end time. A count down timer or warning might be helpful. Or stress inducing.
yep, there it is. Those who read, do have an advantage 
Still, out of sight is out of mind. So a static reminder close to the editor (not a live countdown) would be appreciated.
A few days ago I had 2-3 cases where I started commenting only to be told it had been taken, well short of 60 (or 30) minutes. It was enough to seem like a server / software glitch, not students randomly retracting sessions.
The text also changed around the same time from 30 to 60 minutes – which made me think ‘ah, current code churn’…
Please don’t do a live countdown, which would be distracting. @swsch’s suggestion of showing the end time + TZ sounds good; or possibly show start & end times. (TZ and/or start time could link to the ‘set my timezone’ dialog :)
It would be nice it the message were more accurate in that situation, but it’s not a priority, I guess.
@iHiD I’m not a frontend guy, but could a websockety thing be used to notify the pending mentor that the request has been withdrawn or another mentor has taken over?
That does happen. I have learned that if I know it is going to be a little bit of time (more than I want to potentially “throw away” by having them retract the request) I may do a quick message saying that I am working on the feedback. That should “lock it” to you, while they can still hit that “End discussion” button, at least the information you have worked on is not thrown away. They can still choose to use it or ignore it.
But then it allows me to not worry about that count-down at all.
Indeed, and I have taken to doing that when my initial feedback is going to be long.
BUT. During the period when it felt like locks weren’t working right, it also felt like someone else was doing that aggressively. I would look at the queue, see there were 11 pending requests, do a really quick simple one, then there were 2 pending requests; which felt like someone had opened all the requests that interested them, posted a ‘nail it down’ initial comment, and immediately switched to the next.
I really don’t want the interface & overall experience to encourage mentors to do that. I don’t want to feel like I’m in a ‘race’ for some rare commodity, and I *really don’t want to feel like I’m in such a race where others may be misacting :(
=====
There’s a software protocol here, currently between the server and the mentor’s web page client, which at the moment seems to have just these steps:
client → server: request and lock this request for a while
server, eventually: timeout lock
client → server, eventually: possess this request [ fails if timed out ]
I guess it should be slightly more interactive, e.g. adding some of these possible interactions (I’m not trying to propose exactly which ones, but open it for possible discussion):
server → client: lock is going to time out in N sec (N should be at least 5 minutes…)
client → mentor-at-keyboard: server says lock’s going to time out in N sec
client → server: mentor-at-keyboard has typed M characters into an edit buffer
client → server: mentor-at-keyboard says please hang on
I do it sparingly, only after I’ve been working for a while and suspect I’m approaching the time limit. I’ve infrequently seen a queue “collapse”. When I have seen it, I want to say it was when there were a bunch of easy ones like lasagna, where any beginner mentor could do it. I always thought it was just a bunch of mentors that took them, but I suppose it could be a single mentor doing a quick response “lock-in”.
Yeah, this feels like a sensible solution that’s relatively straight forward for us to deal with. I’ll speak to @dem4ron about it
Update for everyone. Aron’s going to be working on two features:
"This session is locked until xxx UTC (52 minutes from now"). With 10 minutes left, you’ll get a modal that asks if you’d like to extend that time.Let me know if you have any thoughts/requests. I’d like to get a first cut of these two tweaks added and then we can always refine, so I’ll probably kick more complex ideas down the road a little but I’m still open to them.
You can track the PRs here:
And here are the “user stories” (which in Exercism world is me recording a loom for someone while getting eaten by mosquitos):
A post was split to a new topic: Bug when posting a mentoring comment on a solution with a new iteration
I and at least one other commenter asked please don’t include a continuously updating timer. That’s irritating and angsty. Just show the end-time, leave it up to the viewer to mentally model what that means relative to the passing of realtime.
I guess I would find it reasonable for it to do a one-time vaguely-active alert thing, like: 5 minutes from expiry, update the end-time on screen: from ‘normal’ to red color (and bold, for color-challenged viewers).
I think if it’s subtle at the very bottom mid-sentence it won’t be something people notice unless they look for it. So I think we try it to start with and if people find it causes them irritation we can remove it.