CSC/ECE 517 Spring 2021 - E2115. Mentor management for assignments without topics: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
Line 45: Line 45:
=== Test Plan ===
=== Test Plan ===
Based on the the workflow diagram we propose, we should be including a minimum of 5 tests: 1 for <code>assignMentor</code>, 1 for <code>chooseMentor</code>, and 3 more to exercise the 3 paths through our workflow diagram.
Based on the the workflow diagram we propose, we should be including a minimum of 5 tests: 1 for <code>assignMentor</code>, 1 for <code>chooseMentor</code>, and 3 more to exercise the 3 paths through our workflow diagram.
# A team will have a mentor after <code>assignMentor</code> is called
# The mentor with lowest number of team assigned will be return after <code>chooseMentor</code> is called
# The <code>chooseMentor</code> except not to receive any message if a team already has a mentor.
#
#

Revision as of 00:01, 29 March 2021

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

Logic Design

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()

notifyParties()

UI Design

Test Plan

Based on the the workflow diagram we propose, we should be including a minimum of 5 tests: 1 for assignMentor, 1 for chooseMentor, and 3 more to exercise the 3 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.