Mentoring Continuation Request

[mikedamay]

Mentoring Continuation Request

Summary

Proposal to promote a lengthier interaction between a mentor and learner (aka Sticky Mentoring) by allowing a learner to request a specific mentor.

Objectives:

Improve mentoring quality

Improve mentoring experience

Housekeeping:

For the rationale relating Sticky Mentoring to the above objectives see this and, in particular the reservations raised by @F3PiX here and my response

I hope that the proposal will make a contribution to the third objective, "Intentionally Growing Exercism" as outlined in the Strategy Document.

For background to proposals to improve mentor-learner relationship see https://github.com/exercism/exercism/issues/4658

Proposal:

This issue introduces the idea of a Mentoring Continuation Request (MCR) whereby a learner can request that their solution to the next exercise be mentored by the same mentor as that of the current exercise. If the mentor accepts the request then, subject to a timeout, only the requested mentor will see the learner’s solution to the specified exercise.

The MCR can only be made for one exercise at a time. If a learner favours a single mentor for all their solutions they will have to make a request during each exercise.

For example, a mentor may start by mentoring twofer from which time the learner can make the request that the same person mentors leap (up next on the C# track). The request will not affect gigasecond (third in the track). To have gigasecond mentored by their preferred mentor they will have to make a similar request during the mentoring of leap in respect of gigasecond.

The reason for adopting an approach where the learner has to make an individual request in respect of each exercise rather than the much simpler (to understand and implement) approach of assigning a learner to a mentor for the duration is to avoid mentors and learners feeling under any sort of obligation to continue the interaction.

Proposed UI and Workflow:

TODO – it won’t be simple

Mentoring Continuation Request Life Cycle State Diagram

TODO – it tames the complexity

[jeffdparker]

Three comments: from the student's point of view, what happens when (s)he doesn't renew the relationship for a problem, and wants to reconnect with the mentor? Is that possible?

My major concern remains: a student winds up with a roundheeled mentor who misses major mistakes or is ignorant of some key library or language construct.

I understand the student's point of view when the relationship breaks down. What if we could offer the student the same choice we offer mentors: the chance to break off the discussion, and return the submission to the general queue?

[mikedamay]

I understand the student's point of view when the relationship breaks down. What if we could offer the student the same choice we offer mentors: the chance to break off the discussion, and return the submission to the general queue?

Good idea - let's include that. Either party can withdraw at any time.

Is that sufficient to address the issue of the round-wheeled mentor?

[bkhl]

Is that sufficient to address the issue of the round-wheeled mentor?

Only if the student realizes the mentor is lacking. I think it's a very good thing about Exercism as it is, that you get bounced around between different mentors and will get exposed to different perspectives in each exercise. So, I think think sounds like a complicated system that will potentially do more harm than good.

However, when mentoring I do think it would be nice to be able to see a trail of previous interactions you've had with the student, so that if they repeat mistakes they did earlier and that sort of thing, you know you might have to take it up again with a different tack, or whatever.

[mikedamay]

I do think it would be nice to be able to see a trail of previous interactions

This is a good idea.

[mikedamay]

@bkhl

I understand the objection that a problem with the idea of extended mentoring is that learners will get restricted input (possibly even poor quality) from Exercise because they are interacting with a single mentor.

In mitigation I would suggest that learners are likely to recognise they are not getting the best advice and can limit the interaction as they will have access to many inputs other than Exercism. Also I foresee this proposal being introduced after mentor-mentor interactions have been extended which may include some formal or informal quality assurance.

In addition I believe that extended mentoring has the following benefits: • Responsiveness: My intuition is that if there is mutual commitment then speed and thoroughness of response will be improved.

• Effective Communication: By spending a longer time with a learner, a mentor can internalise much about them that will inform reviews: primary natural language, primary development language and frameworks, is the learner familiar with general software engineering principles and best practice.

• Concentration of Effort: as I have a certain amount of effort to provide, it is better that it is focused on the exact needs of the learner. If a learner is not using a particular construct (say LINQ in C#) I would like to be aware of whether they have not learned LINQ or don’t how it can be applied to this exercise before I comment.

However my main reason for introducing the proposal has far more to do with making the mentoring experience more satisfying and thereby sustaining the site and enabling it to scale. I suspect it will require analysis from people with access to site wide data to decide whether the albeit mitigated problems with the proposal are outweighed by the potential gain. It may also be that increased mentor-mentor interaction (over which there is less debate) is sufficient to improve the mentoring experience sufficiently to address my concern.

[iHiD]

@mikedamay Thank you for this. I like the idea conceptually, see lots of issues with it, but think they're probably all overcomeable if implemented correctly. I think it also shifts the direction of Exercism in some ways, which will mean other bits need to change to even things out. There's a huge amount here, so I want to take time let my thoughts on it percolate, and to think it through properly before diving into the discussion. I'm very interested in hearing other people's thoughts

[simmol]

@mikedamay What if the stick to mentor thing does not limit your solution to a single mentor but just notify him. So he can comment together with other mentors.

This way you can provide contextual help. And some other mentor can also help to improve both the student and mentor knowledge.

I saw some other mentor commenting on some of my exercises (may be @iHiD can tell me if that is a bug or by design) and i don't see why a solution should be limited to a single mentor in

[mikedamay]

@iHiD

I think it also shifts the direction of Exercism in some ways

Perhaps, it's this. I like, many developers, have spent my career doing project-shaped work. I take a set of requirements at one point and deliver a release at some future point. It’s done and complete. I can have a retrospective. In contrast, reviewing exercises is pipeline-shaped. As soon as you finish some review for a learner, the so-and-so goes and submits another exercise. Sometimes it’s more like a firehose. I think that is what makes me slightly uncomfortable with the process. I think some people scratch the project itch with track maintenance or site maintenance or even by taking on tracks as learners. I’m not sure that’s scalable. Perhaps a benefit of sticky mentoring is that it makes for a slightly more project-shaped work flow.