CSC/ECE 517 Spring 2021 - E2115. Mentor management for assignments without topics

Team Members

• Yi Qiu
• Ryan Smith
• Jose Molina Melendez
• Bahati Wanza

Problem Statement

Currently, Expertiza has no way to associate mentors with teams. For assignments with topics, like the OSS project, mentors are associated with topics, and then whichever team is assigned to the topic inherits the mentor for that topic However, for assignments without topics (like Program 2), there is no good way to “automatically” assign mentors to projects. The instructor needs to watch teams being formed, and every time a new team is formed, a new mentor needs to be assigned, outside of Expertiza. This leads to a lot of work for the instructor, as well as sometimes long delays before a team is assigned a mentor.

The Plan

For assignments without topics, mentors should be assigned to teams. Assume that things happen in the following order:

• An assignment without topics is created that requires teams of size of up to k.
• Students sign up for teams.
• When a team reaches a target size of greater than 50% of the maximum teammate capacity, then:
  • A mentor will be assigned to this team and notified via email.
  • Participants in an assignment will be identified as mentors via their participant permissions (see the E1963 documentation). This adds a fourth, “mentor” permission to the existing three permissions (“submit”, “review”, and “take quiz”). Anyone with “mentor” permission for an assignment is eligible to be automatically assigned to mentor a team when a new team is formed.

What needs to be done

Develop a trigger that:

• Is activated when any team has been formed that has k members, where k is greater than 50% of the maximum team capacity
  • ex: max members = 4, trigger activated when the team size reaches 3
• Assign a mentor to the team
  • Mentors should be evenly assigned to teams, so a good strategy is to assign the mentor who has the fewest teams to mentor so far.
• Notify the mentor via email that they are now assigned to a specific team, and provide the email addresses of the team members.
• Possibly notify the team members that they have been assigned the mentor with contact information (further discussion here).

Preconditions

The mentor assignment feature has a few preconditions and assumptions which have been outlined below.

1. An instructor has already added an assignment without topics.
2. “mentor” permission exist
3. There are users in said assignment with mentor permissions.
4. A mentor has yet to be assigned to said assignment.
5. Mentor assignment is done only once, does not take into consideration drop offs.

Workflow Diagram

The main workflow of the mentor management for assignments without topics is outline below.

Logic Design

The following main logic components are described below. Each block of logic is to be independent from one another, in order to avoid DRY and de-couple code responsibility.

chooseMentor()

In order to assign a mentor to a group, we must first choose a mentor wisely in the system. The requirements document suggests "Mentors should be evenly assigned to teams, so a good strategy is to assign the mentor who has the fewest teams to mentor so far." This can be implemented using a min-heap-based priority queue, where a mentor's priority is the count of the number of teams to which they're assigned.

assignMentor()

The responsibility of this function will be to take care of actually assigning the mentor to an assignment through updates to the database.

notifyParties()

This is going to be a simple function that takes care of sending an email to a) the mentor, and b) the project teammates to:

1. Notify the team they have been assigned a mentor and pass along their contact information
2. Pass along the contact information for the team members to the mentor

UI Design

A simplistic UI design approach is to be implemented. Below is a mock rendering of the new information that will appear on the student_teams/view?student_id= expertiza page. The value will be only present if the mentor has been automatically assigned.

Test Plan

Based on the the workflow diagram we propose, we should be including a minimum of 4 tests: 1 for assignMentor, 1 for chooseMentor, and 2 more to exercise the paths through our workflow diagram.

1. A team will have a mentor after assignMentor is called
2. The mentor with lowest number of team assigned will be return after chooseMentor is called
3. The chooseMentor except not to receive any message if a team already has a mentor.
4. The chooseMentor except not to receive any message if a team has size < 50% of the maximum size.