ScholarX: February Edition

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.


Hi all,

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.

Flow diagram design -

This will be the link to the figmaJam board of this flow diagram. Link

When identifying the assigned mentees to the mentor stage I divided it into three sub-main flows,

  1. Admin - Mentee Filteration
  2. Mentee approval Flow (by Mentors)
  3. Wild card round (by Admins)

  1. Admin - Mentee Filteration

  1. Mentee approval Flow (by Mentors)

  1. Wild card round (by Admins)

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.


Thanks, @anjisvj for initiating the thread!

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. :grin: 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.

@Pasindu_Rupasinghe, I would highly recommend you convert it into a blog.

“In order for connection to happen, we have to allow ourselves to be seen—really seen.”
—Brené Brown

Excerpt From
Show Your Work!: 10 Ways to Share Your Creativity and Get Discovered
Kleon, Austin


Thank you! @jaye

Also thanks for the suggestion! :grin:

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.



These are the updated wireframes.

Admin Dashboard: (Outdated)

Mentor’s workflow:

Mentee’s workflow:

Note: Homepage and the User Login Flow are similar to what we had in version 1.

Updated Admin Dashboard (ScholarX: February Edition - #8 by piumal1999):


The main API endpoints can be found here,

There could be some endpoints that I’ve missed and some I’ve left out because it’s already implemented.

Need to go through these and have a discussion.

1 Like


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)

I updated the existing ERD with some of the new attributes.

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:

  1. Set assigned mentor of a mentee
  2. Change the state of a mentee

Minor changes:

  1. 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.

1 Like

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:

  1. 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
  2. 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
  3. Institution
    • University or the place that they work at
    • Same as the previous one
    • Getting their answer as plain text
  4. Position
    • Could be phD, SE etc
    • Getting their answer as plain text
  5. Bio
    • Small description about them
    • We can skip this if this is not needed since we are getting the LinkedIn profile
  6. No. of Mentee Slots
    • Number of mentees they can mentor
  7. 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

1 Like

These are the fields we are going to add to the mentee profile. We ask these things from the users when they are applying to be a mentee.

  1. Primary Mentor
    • Choose from a drop-down list
  2. University
    • Plain text input
  3. Course/Major
    • Plain text input
  4. Year of Study
    • Plain text input
  5. Intent for a mentor
    • Small description
    • Plain text input
  6. Reasoning for the choice
    • Small description
    • Plain text input

Let me know if anything is missing.
cc: @jaye @anjisvj @Gravewalker @cmdrGuyson

1 Like

@anjisvj @piumal1999 Have you defined the scope and a deadline for the current sprint? It seems there are only 2 issues in the current sprint.

Development Sprint #1: Scholarx February Edition

From: 2021-12-04T18:30:00Z to 2021-12-11T18:30:00Z



cc: @jaye @Gravewalker


Development Sprint #2: Scholarx February Edition

From: 2021-12-11T18:30:00Z to 2021-12-17T18:30:00Z