CSC/ECE 517 E2024 Mentor management for assignments without topics

CSC/ECE 517 E2024 Mentor management for assignments without topics

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.

Project Goal

Develop a trigger that:

1. 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
2. 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.
3. Notify the mentor via email that they are now assigned to a specific team, and provide the email addresses of the team members.
4. Possibly notify the team members that they have been assigned the mentor with contact information.

Previous Work

Design Pattern

Since the trigger they implemented would need multiple handlers and each of the responses in different actions, they decided to use Chain of Responsibility as the design pattern. Chain of Responsibility is a behavioural design pattern that lets you pass requests along a chain of handlers. Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain. The reason to take this approach is we have a certain question which needs to be answered, based on the answer the flow moves. It follows a sequence which follows this behaviour pattern well.

Work Flow Diagram

Improvement on the Previous Work

Change in Work Flow Diagram

Refactor Code to follow good coding practices
Example:

1. Rename method names more meaningfully and intuitive like, from able_to_review to can_review.
2. Reduce the number of conditional statements checking for mentor.
3. Rename variable names to reduce confusion like changing lowest_team_no to lowest_number_of_teams.

Files to be Modified

Models:

• app/models/assignment_team.rb
• app/models/assignment_participants.rb
• app/models/team.rb
• app/models/team_users.rb

Views:

• app/views/student_task/view
• app/views/student_teams/view
• app/views/shared_scripts/_add_individual
• app/views/participants/_participant

Correct Previous Design

1. Remove mentors from being included in a team's number of members count.
2. Change the conditional statement that checks if a mentor has to be added to the team. (The strength of the team has to be greater than 50% of the team size).

Code placed in the wrong locations to be moved to the desired locations.
Example:

1. The email code has to be moved to the email module.
2. Code written in team file has to be moved to the assignment team file.

Remove Duplicate Functions
Example:
Though there is a method "team" to list the members of a team, a new method has been created, which is to be removed.

Testing

1. Some existing test cases have been modified, which has to be reverted.
   
2. RSpec tests for the email functionality will be added.
   
3. Run and pass the existing RSpec Tests.
   
4. Develop New RSpec Tests for the new code additions (additional features).
   
5. Test the UI for the deployed project.
   

Functionalities to be added

• The mentor should be able to check submissions of his team.
  

This will be an add on feature to this functionality which would make it more intuitive. The type of user will be used as a way to approach this. This was earlier implemented to an extent but there was difficulty accessing the content of another user. This needs to be investigated more.

• A new rubric must be created for the mentor who is also included in the review process.
  

A need is felt that mentor should be assessed a different rubric than the rest of the team, this can be achieved by modifying the rubric form based on the type of user and make only the corresponding details visible to them.

• Accommodate changes in team members/assigned topics after a mentor has been assigned.
  

This is planned to be addressed as per the new flow diagram, where a check will be performed to see what type of a team it is, new or modified one.

Reference

Previous Work