ScholarX is a set of exclusive mentoring programs that are open for Sri Lankan students to participate in and get a premium mentorship experience conducted by industrial experts. It connects experts, who are willing to support upcoming generations with their expertise, and high potential undergraduates.
Until now the internal process of a ScholarX program commenced as follows. When a new ScholarX program is announced, the SEF team connects with the industrial experts directly and invites them to take part in the program as a mentor. The list of mentors who accept the request gets published on the SEF website. The undergraduates who are interested can apply, by filling out a google form, for multiple mentors from the listed pool but only get picked up by one or get rejected. After this registration and approval phase of mentees, the SEF team establishes the connection between mentors and selected mentees and starts the mentoring period. Usually, it has a predefined period of time of 3 months or 6 months.
The task which was assigned to the SEF-dev team was to develop a web-based application to automate this mentor and mentee registration process without the direct interference of the SEF team, i.e. after the implementation of the platform SEF team would only manage the program. For an example they would not contact the mentors directly, any user would get access to login to the platform and apply to become a mentor of a certain program, the team would only check the details/profiles of the applied mentors and approve or reject them as suits.
Any normal user should have access to create an account and login to the system, see active programs and depending on the current state of the program, apply for them as a mentor or apply to become a mentee of a mentor in a particular program. The SEF team should have access to manage these user actions, create, delete, and change the state of the program. Thus the web app should consist of two ends, namely the admin end, which provides the functions of managing programs and users, the user end, which is the end that’ll be exposed to the public to come in and get registered. The admin should have the ability to check the details of the users applied to become mentors of certain programs and approve or reject them. A user who got approved as a mentor should be able to see the mentees applied for him/her and approve or reject them.
This looks good! But I have 1 question. If we let mentors pick students, what about students who have applied for multiple mentors? Are we letting mentors pick fast as possible? or are we letting the mentees their choices and let them confirm their mentor? or is there a better solution? What we initially did was, we picked the top X number of students depending on the number of slots(factored in the speciality of mentors as well) we have (factored in the speciality of mentors as well) and then allocated them to mentors.
This is a concurrency problem, so I can think of two solutions for the time being.
Three-step process: 1. Share the student's application with the student's number 1 choice 2. If there are students without a mentor AND mentors without students: Share the application of the student with their second choice mentor, given that the mentors have slots. 3. Repeat step 2 for choice number three for the same conditions. 4. If there are still students without mentors and mentors without students, we can share those applications with the mentors without students.
Old method: We export the DB to a Google Sheet and do the previous filtering method where we personally do the pairing and send the mentors the final list.
This is very helpful @akshika47!
Another thing we can do is using some first come first serve approach. But in long run, it might not be a good idea.
However, we need to come up with a minimalist workaround to solve it.
Yeah. It can be done in the current version. But someone might lose his/her chance to be selected to their mostly preferred mentor because of this scenario.
What if we add another program state for mentees to accept their mentor? But it will take time
For this year’s program, we should not do a FIFO model. Cos that is not how we planned the program. But after launching the program we can have a FIFO model which is independent of the SX general program. In the worst-case scenario, we can follow the old method(option number two)
It’s not suitable to use the FIFO model because of the problems previously discussed on this thread
To solve this, we can introduce a program state for mentees to confirm their mentor. The new state will be added after the MENTEE_SELECTION state. So in this state, mentee can see the list of mentors who have approved his/her mentee request (if the mentee is approved by more than 1 mentor). And the mentee can select and confirm one mentor. For this, a page to display approved mentors have to be added to the UI.
or we can let the mentees to add a priority for their mentors when applying. So the concurrency problem can be fixed with the mentees preference. But this approach will take more time to add the relevant logics to the APIs. And a database change will also be needed.
