Change Details

**"As a mentor, I want to choose how many mentees are assigned to me so that I can make sure I'm only receiving as many questions as I can handle."** On some large wikis, mentors receive more questions than they have time to answer. While increasing the size of the mentor pool is one solution, another is to distribute mentees more intelligently. Some mentors want to spend a lot of mentoring and some only want to spend a small amount of time. We could allow them to indicate their desired volume, and then assign more or fewer mentees to them. Some open questions: * With what granularity should we allow mentors to sign up? It could be like "high, medium, low". * Where should the indication happen? Should it be where they list their username and greeting? Or should it be part of {T280307}? * Maybe an even more sophisticated version of this would allow mentors to indicate //exactly// how many mentees they want to receive per week, and then if more newcomers show up than the mentors have signed up for, those extra don't receive mentors (because of insufficient capacity).

**"As a mentor, I want to choose how many mentees are assigned to me so that I can make sure I'm only receiving as many questions as I can handle."** On some large wikis, mentors receive more questions than they have time to answer. While increasing the size of the mentor pool is one solution, another is to distribute mentees more intelligently. Some mentors want to spend a lot of mentoring and some only want to spend a small amount of time. We could allow them to indicate their desired volume, and then assign more or fewer mentees to them. ==== Open questions * With what granularity should we allow mentors to sign up? It could be like "high, medium, low". * Where should the indication happen? Should it be where they list their username and greeting? Or should it be part of {T280307}? * Maybe an even more sophisticated version of this would allow mentors to indicate //exactly// how many mentees they want to receive per week, and then if more newcomers show up than the mentors have signed up for, those extra don't receive mentors (because of insufficient capacity). * Should we tell wikis what's their mentorship capacity vs. number of newcomers? ==== Scoping ===== Using weights As @Tgr already correctly noted, the easiest thing to do here is to use high/low/medium as weights. So, if UserA is enrolled with factor of "high", UserB is enrolled with factor of "medium" and userC with a factor of "low", the assigning system could see the pool of mentors as: * UserA * UserA * UserA * UserA * UserB * UserB * UserC UserC would have the lowest chance to be assigned (1/7), because they have the lowest factor. UserA, on the other hand, would have the highest chance: 4/7 (over 57%). However, this will only be true if most people sign up with factor of "medium". For example, consider following list of mentors: UserA (low), UserB (low), UserC (low). With this list and factors, the pool of mentors will be (using same weights as above): * UserA * UserB * UserC Each of the users will have an equal chance of being picked up as a mentor. ==== Different weights An alternative solution here would be to still use weights, but interpret them differently. It could be a percentage of the ordinary mentor traffic. For instance, if a mentor would set their percentage to 80%, the system will ignore 20% of mentees that would be otherwise assigned to the mentor (and instead won't offer any mentorship to those users). For mentors wishing to //increase// their percentage, we can simply duplicate their name in the pool. ==== Number of questions asked Since questions go through our interface, we can in theory measure number of questions asked in the last week, and if this number exceeds a given threshold, stop asssigning the mentor temporarily. The threshold can be configurable by the mentor themselves. The good thing is that this system will be perfectly understandable: mentors will likely be able to estimate what the workload for answering 2 questions vs 5 questions vs 10 questions is. The bad thing is that it is considerably more difficult to implement than the weighted solutions. As before, we can "boost" the number of newcomers assigned to the task by duplicating their name in the pool.

**"As a mentor, I want to choose how many mentees are assigned to me so that I can make sure I'm only receiving as many questions as I can handle."** On some large wikis, mentors receive more questions than they have time to answer. While increasing the size of the mentor pool is one solution, another is to distribute mentees more intelligently. Some mentors want to spend a lot of mentoring and some only want to spend a small amount of time. We could allow them to indicate their desired volume, and then assign more or fewer mentees to them. Some o==== Open questions: * With what granularity should we allow mentors to sign up? It could be like "high, medium, low". * Where should the indication happen? Should it be where they list their username and greeting? Or should it be part of {T280307}? * Maybe an even more sophisticated version of this would allow mentors to indicate //exactly// how many mentees they want to receive per week, and then if more newcomers show up than the mentors have signed up for, those extra don't receive mentors (because of insufficient capacity). * Should we tell wikis what's their mentorship capacity vs. number of newcomers? ==== Scoping ===== Using weights As @Tgr already correctly noted, the easiest thing to do here is to use high/low/medium as weights. So, if UserA is enrolled with factor of "high", UserB is enrolled with factor of "medium" and userC with a factor of "low", the assigning system could see the pool of mentors as: * UserA * UserA * UserA * UserA * UserB * UserB * UserC UserC would have the lowest chance to be assigned (1/7), because they have the lowest factor. UserA, on the other hand, would have the highest chance: 4/7 (over 57%). However, this will only be true if most people sign up with factor of "medium". For example, consider following list of mentors: UserA (low), UserB (low), UserC (low). With this list and factors, the pool of mentors will be (using same weights as above): * UserA * UserB * UserC Each of the users will have an equal chance of being picked up as a mentor. ==== Different weights An alternative solution here would be to still use weights, but interpret them differently. It could be a percentage of the ordinary mentor traffic. For instance, if a mentor would set their percentage to 80%, the system will ignore 20% of mentees that would be otherwise assigned to the mentor (and instead won't offer any mentorship to those users). For mentors wishing to //increase// their percentage, we can simply duplicate their name in the pool. ==== Number of questions asked Since questions go through our interface, we can in theory measure number of questions asked in the last week, and if this number exceeds a given threshold, stop asssigning the mentor temporarily. The threshold can be configurable by the mentor themselves. The good thing is that this system will be perfectly understandable: mentors will likely be able to estimate what the workload for answering 2 questions vs 5 questions vs 10 questions is. The bad thing is that it is considerably more difficult to implement than the weighted solutions. As before, we can "boost" the number of newcomers assigned to the task by duplicating their name in the pool.