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

Team Members

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

Video walk through

5 min video explaination

[video can be found here]

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.

selectMentor()

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.

addMentor()

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

removeMentor()

The responsibility of this function will be to take care of removing the mentor to an assignment through updates to the database if the team size has fallen below 50% of the max if one was assign.

notifyTeam()

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.

The instructor view will also need to have visibility of what mentors the teams have. Below is a mock rendering of the new information that will appear on the /teams/list?type=Course&id= expertiza page. The role column will be added.

Manual Testing instruction

1. Login as instructor6, using 'password' as password and find the Rock on Assignment
2. Check the paticipants for this assignment, make sure there are some students attempting this assignment.
   • You can add your own students to the assignment if you want.
3. Impersonate the student account you found.If there is no team, create one by inviting other student to your team, or create a team using the admin control.
4. By toggling the Auto assign mentors when team hits > 50% capacity? in the assignment configuration page you will be able to:
   • Enable the functionarities and logics that our team implemented.
   • Disable the functionarities and logics that our team implemented to allow an admin to assign mentor manully.

Two Observations (Trigger Enabled)

1. Add team members to any team under the Rock on Assignment using any following way:
   • Invitate/Accept the team invitation using impersonated student accounts.
   • Add student to team by using the admin control.
2. Observe that when the member size passing the capacity (3 for this Rock on assignment), a mentor called Student6801 will be added to the assignment team.
3. Remove the mentor and the added students of the assignment team using the admin control.
4. Observe that when the member size below the capacity (e.g. the second team member added), a mentor will not be added to the assignment team.
5. You should also be able to see that mentor is showing on the team list.

Two Observations (Trigger Disabled)

1. By doing similar step as we mentioned above, you should not see any of the following:
   • A mentor is added to the team after the team size changed.
   • A mentor is displaying on the team list unless this mentor account: Student6801 is manually added or invited.

Test Plan

Based on the the workflow diagram we propose, we should be including a minimum of 5 tests: 1 for addMentor, 1 for removeMentor, 1 for selectMentor, and 2 more to exercise the paths through our workflow diagram.

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