V3: [Roadmap] Mentor pairing

[tehsphinx]

This is feedback on the v3 roadmap (#690).

---

The student will be given the option to add this mentor to their "favourites". If the mentor also adds the student to their "favourites" then the student next submits, the mentor will be notified about the new solution.

This sounds like more work for a mentor: having to vote on each student. Why not have a system instead where the student requests a permanent mentor instead and a mentor can agree or not?

When a mentor views the lists of solutions to mentor, they will be able to filter by their favourite students.

Is that only students that also favoured the mentor, or all students the mentor favoured (no matter the students decision)?

[iHiD]

Is that only students that also favoured the mentor, or all students the mentor favoured (no matter the students decision)?

The student and mentor shouldn't know if the other favoured the other, so it would just be some indication of [not-mentored-before, mentored-before, mentored-before-and-favourited]. They'll be two independent systems, but if both sides are positive, then there is an extra benefit (in the notification).

Why not have a system instead where the student requests a permanent mentor instead and a mentor can agree or not?

A couple of reasons.

Firstly, receiving feedback from multiple mentors is something we think is a helpful principle we want to enforce. If a student and mentor choose to "pair up" they could create a team to do this, but I don't think it's something we want to promote.

The main reason though is that logistics don't work very well for a few sub-reasons:
1) Most students want a timely response. The fact that a student is pushing their solution to only one mentor means that the student will almost certainly have to wait longer than if they push to a general bank of mentors, but mentors are notified.
2) It adds loads more pressure to mentors. You know that students are waiting for you, and even if we time-out after a few days, it makes it much harder for the significant proportion of mentors who spend a focused few hours once a week doing a batch of mentorings.
3) We don't want students to know whether mentors have also favourited them. That adds too much risk for conflict/frustration.

This sounds like more work for a mentor: having to vote on each student.

I don't think it need be. If the mentor can choose a default of "favourite everyone" or "favourite no-one" and then just have a simple "favourite"/"unfavourite" button inline during a conversation, it's a simple one button click if they're enjoying/not-enjoying chatting to someone. (The default would be "favourite no-one"). As long as this is done nicely in the UI, I don't think it will be really an issue, and probably less of an issue that getting hundreds of "Favourite responses" that you have to reply to.

[tehsphinx]

This additional explanation on how the system is intended to work makes me like it 😃

[iHiD]

Great! :)

I've updated https://github.com/exercism/v3/issues/690 with what I wrote above. If you (@tehsphinx) are happy with that and feel it represents what we've discussed here accurately, please close this. Or otherwise let me know how I can make it clearer :)

[tehsphinx]

LGTM