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.
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.
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…
– 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…
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.
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.
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 :)
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.
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).
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.
I can actually update this now, with concrete test results.
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.
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.
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.
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.
I think the ones who can’t do new iterations are using the web site only, no command line. (Only a guess integrated from various memories…)
When a student is using the web site, I believe there are two different user interfaces / ‘places on the site’, one where they are ‘working on exercise X’ and another where they are ‘looking at the mentoring session on exercise X’. Both of these have ‘edit or submit a new iteration’ type buttons; but – I think – these buttons disappear from the mentoring session when it is ‘closed’. And then they may not realize they can get to the same action elsewhere, in the ‘working on exercise X’ section.
=====
I recognize that it is problematic, in a practical sense, that I am doing this without having done much of anything from the student side. It makes me helpless regarding student UI issues. I will eventually remedy this by actually ‘doing’ some of a track … but not today…
@iHiD I ran into this today. A student closed out session f613f1923cbd4330b284f9b95760e82d but wanted to continue the discussion. They sent me a private mentor request, external_requests/26658f0d727846718c83e6334aaeeaeb. When I click “Accept invitation” it forwards me to the prior, closed session, f613f1923cbd4330b284f9b95760e82d. I would expect it to open a new session.
