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.
I am visiting this sub-forum for the first time in months, as I have new issues to raise. But as long as Iām here, Iāll validate the above: the current countdown timer implementation is not irritating and angsty. Itās fine.
There is one aspect of it which is mildly annoying, so Iāll mention it, but itās minor enough that I doubt it will be changed. The current timer is 30 minutes, and it prompts after 20 about whether to extend or not. Those parts are fine. However, sometimes I am nearly finished, so I say āno, donāt extendā; and then it prompts me again at T-9!
It seems to me that if I said no, donāt extend, then it shouldnāt prompt again every minute! Once more at the end maybe (T-1), if I am so foolish as to reach that.
If we look at a mentoring request and decide not to take it, is there anything which releases it back to the pool faster than the 30min timeout? e.g. is there a handler to detect the page being closed, or anything like that?
If there isnāt already something strongly reliable, could we have a ānot taking at this timeā button? It should just cancel the lock, as I might pick up later (if still waiting); just canāt do it this minute.