Some details of mentoring session timeouts

Exercism Mentoring Chat
1

Hi. A few months ago, the mentoring setup was changed so that if a student doesn’t respond for 30 days, the session times out. Both the mentor and student can still comment after that, but the session remains in a ‘timed out’ limbo state in which the student cannot upload new iterations.

I have had a couple cases where the student did eventually come back and want to continue, with new iterations and everything. The first time that happened we were able to just discuss the code and come to a happy conclusion in the old half-dead session.

In another case I asked the student to find the ‘start a private session’ UI and send me a mentoring request for the same exercise. Today, I came back to that old session to find that they had indeed pasted in a private mentoring request URL. Following that gets me to a page asking whether I want to accept the private session. Following that gets me … right back to the existing, broken-in-limbo, session.

The current instance is this mentoring session:

exercism dot org/mentoring/discussions/abfede3e8b9a4316bf05ee73c56766c1

and this private mentoring request link:

exercism dot org/mentoring/external_requests/72fd54f793594fa79bf9926609f21d26

I imagine these will not be visible to non-staff, but even if they are, there is no harm. (Links are intentionally kneecapped to prevent inclusion of useless previews.)

So I have two somewhat divergent, but related requests here:

  1. when the student responds in a timed-out-after-30-days session, please unlimbo it; put it back to a normal state where the student can still upload new iterations

  2. do something different in the situation where a mentor clicks to accept a private mentoring request for a tuple of { student, mentor, track, exercise } which is already populated. My preference for what to do differently is a dialog telling me (the responding mentor) that such a mentoring session already exists, offering me choices of (A) open the existing session [ which shall have been rejuvenated as requested above ] or (B) start a new session in which the first code iteration will be the one the student was on at the time they raised the private request.

BTW, choice (A) here should not destroy the private mentoring request, leaving open the possibility that I might later decide (B) is a better option. (A) is what currently happens; except the rejuvenating part.

Also BTW, choosing (B) should hopefully not destroy the previous session, just relegate it to history.

One reason I might want (B) is if the existing session already has a large number of iterations. The mentoring UI gets somewhat cumbersome when there are 10-20 iterations already in play; a clean start could be nice in those cases.

2

Thanks for starting the thread :slight_smile:

As far as I am aware, students can always upload iterations. Iterations aren’t linked to mentoring at all. So I’m confused about that’s the conclusion you’ve come to. Are we miscommunicating that somewhere? Or is something breaking for the student?

I think we should start the discussion there before digging into the other points.

3

I’ve used the student-end of Exercism UI very little, so I’m in the weird position of mostly not being able to tech support them on that end of things.

I will go check – OK, I posted to the student with the current issue, asking him to try different methods to create new iterations. We’ll see what happens.

=====

The bit about ‘limbo state’ remains. The mentoring session timed out. Since then, both parties have had active discussion over the last few days. But the bottom of the discussion thread always ends with a floating fake-entry ‘This discussion timed out\n\nThanks for mentoring %s.’

4

I can offer the following further observations:

  • there are definitely way(s) for students to upload new iterations after a timeout. I have now had two different students successfully do so
  • I suspect that there are two different ways, specifically, doing it through the Exercism per-exercise web page (not in the mentoring UI), and doing it from the command line tools on one’s own system
  • ONE student (qnikst) did it in a way which, once the new iteration was uploaded, my mentoring UI no longer claimed to be in the ‘timed out’ and ‘ended’ states
  • the OTHER student (sawcce) did it in a way which still remained in both of those states
  • neither student has answered my queries as to whether they submitted their new iteration(s) from the GUI or command line (note, I put their IDs here so I have a semantically accessible back-reference…)
  • the one whose method turned off the ‘ended’ and ‘timed out’ states eventually ended the session in the normal manner, after which it returned to the ‘timed out’ state

‘timed out’ state means that there is an ‘extra’ item in the conversation pane, floating after any actual conversation, including newly added comments, stating ‘This discussion timed out’.

‘Ended’ state means there is an ‘Ended’ box on the top line.

I would like to see changes along the lines of:

  • any student comment or exercise upload ends the ‘timed out’ state
  • students should still be able to upload new iterations from their mentoring UI while in ‘timed out’ state (which would then end the state) – note, again, that I don’t really know what that looks like; what I do know is that students seem to believe there is no way to upload iterations once in 'timed out 'state, so something must be absent or look different in their mentoring panel
5

One of my students also timed out, but messaged me about “The last iteration” and it took me a moment to realize why I did not get the notifications I still expect to get (but not in “Inbox”) when students do this, but they had (the timing I can not quite know) apparently noticed it was timed out, re-requested mentoring and then made two iterations, and a comment. Of course, I do not expect to see notifications for this case, but it was not until after I had started responding to the new iterations in the old timed out session, that I thought to check “Did they re-request mentoring”? they did, and so I manually carried over the conversation for continuity in the new session.

I keep all “my side” of the conversations locally, so I have all the historical information and iterations recorded, while they will likely have to go back and forth (also not intimately knowledgeable on the student side any more) between to get the historical part of the conversation, if they need to during the now a bit disjointed conversation.

6

Hmmm, that is interestingly different from my experience in several ways!

I do get notifications of new student activity on timed-out sessions. (Although, come to think of it, this is probably ‘my fault’. As soon as the site started timing out sessions, I started rigorously always commenting in such sessions, saying more or less ‘Hi, although the site timed this out, please continue if you are not done’ – that probably resets a flag such that I do get further notifications).

But secondly, when I had a student raise a new mentoring request for a timed-out session, it didn’t create a new session, just redirected back to the existing (and timed-out) session!

When your student re-requested mentoring, was that a public request which you then happened to catch before any other mentor? Mine was a private mentoring request I had them generate & paste the link into the old timed-out session.

7

I was alerted (off platform) that he had submitted, went to the “finished” sections and investigated the last finished exercise from the user and dropped in.

I then downloaded the latest iteration, and started responding, then I noticed that he had sent a new (public) mentor request. At this point I had no notifications, so he must have done so before he had submitted the other iterations, because normally, yes, I believe I still get notifications until they request mentoring again, when they submit another iteration.

Though, I often do make a comment once it times out, I stopped recently, since I believe that what I say is also reflected in the timeout message for them. (not positive.)

I did end up picking up the new request before someone else picked it up though.

8

Ah, I don’t really know what they see when a session times out, but I know it cannot possibly say that I, the individual mentor, consider this business Not Concluded, so please do continue if you happen to come back…

9

– so I think we learn that same-mentor responding to a new mentoring request for the same [student, track, exercise] creates a new mentoring session. Whereas same-mentor following a private mentoring invitation to the same [student, track, exercise, mentor] – reopens the existing session. I wish it were otherwise. There are other reasons to open a new session. The comments section can get unwieldy to scroll…

10

The iterations and comments after those iterations can be linked, so that can help alleviate the scrolling issue somewhat.

But often I will take what they comment and convert it to markdown and add it to notes in github. (git notes add) I can always then search the conversation easily. I do not always do so, though.

But I have the practice of “information I want to keep I control, not the remote service.” Because, you never know when you will not be connected or that service will be down.

11

Jeremy has mentioned before that a session ending triggers a bunch of other state (ability to add testimonial, update contribution points, update the number of mentoring sessions which occurred). Jeremy has mentioned that, since ending a session triggers those other state changes, it is hard to roll back that state and reopen a session. As such, ending a session is a non-reversible state change. Once a session ends, it is permanently ended.

Mentoring sessions are tied to all of a student’s iterations. Iterations can be added/removed independent of mentoring sessions. Iterations can be added/removed prior to a session, during the current mentoring session, during a prior or following mentoring session or after sessions have concluded; iterations are independent of mentoring sessions and, during a mentoring session, the mentor can see all iterations.

12

OK, given the non-reversible nature of session ending, PLEASE DON’T TIME THEM OUT LIKE THAT. It is bad.

Post a nag-message into the session at one month, 8mo, and let’s say 360 days, the final one mentioning that the session will be closed in 5 more days. Close it after a year of student idle time.

Then I’ll probably be back in 13mo complaining that that’s a bit too quick, I’ve had students come back after that long … but at that point I’ll actually be arguing with the wind :)

13

The student is nagged and emailed multiple times over the 30 days. The timeout was added relatively recently after months (years?) of back and forth on the topic. The timeout does not prevent either party from continuing the session nor does it prevent them from starting a new session.

14

I have now experienced this twice: if a particular mentoring tuple [ track, exercise, student, mentor ] has been open, discussed, and then closed – either by timeout or by explicit close by the student – then the student cannot start a new session. If they use the ‘external mentoring request’ feature to send the mentor a new request; the mentor follows that; they arrive back in the old, already-closed session.

Now, it is true that the ‘closed’ session isn’t 100% dead. Both parties can comment, and if the student figures out how, they can still upload new iterations. But the comments section always has a floating ’ You’ve finished your discussion with [student]’ fake-comment at the bottom. And students have trouble figuring out how to upload new iterations in this state (I don’t know what the UI problem is at their end, only there definitely is one because multiple students have failed at it, though some have also succeeded).

15

I forget whether this related question has been tested, but I think it has, with similar failure: what happens if [ track, exercise, student, mentor ] has been open and then closed; then the student raises a new public mentoring request, and the same mentor accepts it? I think I’ve been around that loop once and found that it also results in an ‘undead’ mentoring session. Will update if I get a concrete result.

1 Like
16

I can actually update this now, with concrete test results.

  1. if a particular [ track, exercise, student, mentor ] tuple has been opened and then closed, and the student raises a private mentoring request, this does not create a new session. The mentor, trying to accept the new request, ends up back at the old closed session.

  2. if a particular [ track, exercise, student, mentor ] tuple has been opened and then closed, and the student raises a public mentoring request, and the same mentor clicks to accept it, this does create a new session.

I’d like #1 to be fixed, as I’ve had sessions closed for various reasons where both parties came back and thought it should be still open, or re-opened. I’d prefer there to be a way to just re-open an existing session. The current situation is, you can keep commenting, and the student can upload new iterations, but (a) it is harder (in some way that I’m not clear on) for students to upload new iterations and (b) notifications are messed up.

In the very specific case of a mentor following either a private or public request that corresponds to the same tuple as a closed session – I’d like the mentor to have a choice to either re-open the old, or create a new session. Sometimes I’ve wanted to start a new session just because there were too many comments & iterations in the old session. Other times I’ve wanted to continue and not lose the immediacy of old context.

17

I’m really unsure about this. I’ve never heard it before and I don’t understand why a student can’t do it. Could you provide details please. Do they get some sort of error message etc?

Submitting iterations has nothing to do with mentoring. There’s no linkage between the two at all, so I’m very unsure as to why a student would be able to submit an iteration in one state but not the other. But are identical in terms of either running exercism submit on their command line or clicking Submit in the editor. So again, I’d appreciate some more details here pls.

18

Regarding trouble uploading new iterations, it’s hard for me to give details because I’m getting it second hand from one student or another, usually in a context where they are confused and can’t describe anything in a useful manner.

Regarding starting a new session after an old one [ track, exercise, student, mentor ] has already been closed – this is trivial to reproduce. Take any closed mentoring session. Have the student find and operate the ‘private mentoring request’ UI and ask for the same mentor. Student receives a URL, communicates it to the mentor [ e.g. in the comments of the closed session, but could be email or whatever ]. Mentor follows that link, reaches an intermediary page asking whether to accept the request. Mentor clicks yes. Mentor is now at the original, still closed [ track, exercise, student, mentor ] session; a new session is not created.

19

OK - thanks. I’ll ask Erik to take a look when he’s back from holiday (~10 days from now)

20

Sure. Well, they just need to do exactly the same thing that they did to upload their first iteration - there’s literally no difference :slight_smile: