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.
Any response to this?
You can look at a solution and not accept it after looking at it simply by not clicking on the “mentor this” button.
After you click it, I have not seen a way to move the timer to “now” to disable the hold.
Pending session holds pertaining to a particular mentor should be terminated if that mentor opens a different pending session. That wouldn’t fix the issue 100%, but most practical cases (plus go some way to preventing an antisocial mentor from trying to ‘hog’ sessions, which I have no evidence of, just seems like a potential for mal action which would be better if it didn’t exist)
Sorry - it’s best to open new issues for new suggestions else I’ll miss things.
It seems like a good idea, but it’s not something that I see a huge priority for atm. The vast majority of time people are only going to lock a solution if they’ve decided to mentor it, so it feels like a small use-case with low consequences (ie there’s just a 30min delay).