As we are successfully done with the pilot program. We started gathering feedback from the mentors, mentees and from the scholarX team as well. After having multiple discussions with the feedback we started getting ready for the ScholarX 2022. We got some good requirements from ScholarX team.
We had discussions about whether we are going to use the architecture or not can come to the conclusion that we are going to use the same architecture without redesigning the whole thing again.
We will be changing the flow and there will be new states. One of the main things that going to change is that we are going to have this hybrid mentor selecting method where admins first select mentees for the mentors and the mentor does the selecting from them.
This thread will be updated with the other documents in the upcoming weeks. Here are the meeting notes if you are interested.
As we discussed this Monday (2021/10/25) ScholarX Squad standup call I was assigned to identify the flow and design the flow diagram of the ScholarX February Edition. To initiate this task I had a call with @jaye and finalize the flow diagram as accordingly.
Those flow diagrams will be also visible on the figmaJam board.
Also to reflect the decisions of the application status, we assigned some values for those decisions. Hereby I will add a table including those status values, stage according to the status code, and also the person who will replace the status code.
Status code
Meaning
By whom this status code will replace
Pending
Initial state of the application. The application (i.e. Mentee) is not yet reviewed.
Default
Assigned
Metee assigned to a mentor by admin
Admin/ Mentor
Pool
Mentee is reviewed by an admin, but not assigned to a mentor
Admin
Discarded
Mentee has been discarded by admin due to incompleteness or the application isn’t suitable for further review
Admin
Rejected
Mentee rejected by the mentor
Mentor
Approved
Mentee approved for by the mentor
Mentor
Failed_From_WildCard
Mentee rejected from the wild card round
Admin
We added comments on the figmaJam board for Those stages with the status code and also the assigned mentor on the current stage.
Please leave your suggestions here as well as your comments to improve this flow diagram.
Thank you.
Also thanks @Pasindu_Rupasinghe for posting a detailed update on the flow. @Gravewalker what you said was true; we were able to find many little scenarios that didn’t come to our minds on the initial discussion. We came up with some extra fancy status codes; we can rename them later, both Pasindu and I was terrible at naming them. As Pasindu has stated, the intention of introducing new status is to reflect the decisions taken by each role. ex: If the status is POOL that means the application is reviewed by an admin, but not assigned to a mentor because they think there are no mentor fits for the application at that moment. Go check out the figmaJam and let us know your thoughts.
Me and @kumuditha_udayanga were working on the wireframes of the ScholarX February Edition. 2021-10-28T18:30:00Z we had a discussion with @anjisvj and created the initial wireframes for the new program states. I used components created by Heshan in version 1.0.
We had a discussion to decide whether we need a separate UI to assign mentees in a mentor specific way (select a mentor->add mentees to the remaining slots). If we use that way, when the admin clicks a mentor it will load a UI very similar to the ‘Manage mentees’ view. In that UI, all the mentees will be shown.
So we decided to use the existing wireframe with a small update. (A sidebar to show mentor slot count)
Can we use enums for the data required for filtering? (category, field of expertise). Or is it possible to do it within the frontend itself as plain text?
I went through this document again by comparing the existing endpoints. As I found, we need 2 new admin endpoints and 1 minor change in a non-admin endpoint.
New endpoints:
Set assigned mentor of a mentee
Change the state of a mentee
Minor changes:
Update the “Get my mentee applications of a program” endpoint to get only 1 mentee application
Other than that, we’ll have to update the DTOs since we are introducing some new attributes for mentees and mentors.
When a mentor is applying for the program, we need to ask for the details needed for the filtering and mentor profile. Up to now, these are the things we are going to ask from the mentor:
Category
Asking to select 1 category from the given categories (Life Sciences, Computer Science, Physical Science, Engineering, Other etc.)
This can be used for filtering
Area(s) of Expertise
Like subcategories (Microbiology, Neuroscience etc.)
I think it is not practical to provide pre-defined options, because there can be hundreds of fields.
So this can’t be used for filtering
Getting their answer as plain text
Institution
University or the place that they work at
Same as the previous one
Getting their answer as plain text
Position
Could be phD, SE etc
Getting their answer as plain text
Bio
Small description about them
We can skip this if this is not needed since we are getting the LinkedIn profile
No. of Mentee Slots
Number of mentees they can mentor
Projects(optional)
Some details about their projects
Getting their answer as plain text
According to the above details, only the category can be used to filter the mentors. And other fields will be shown on the mentor profile. Is it ok for the February edition, or do you have any other suggestions? @EngTeam@jaye@akshika47@Dharana_J
As Pasindu has stated, the intention of introducing new status is to reflect the decisions taken by each role. ex: If the status is 
