CSC/ECE 517 Fall 2023 - E2351. Finish mentor management for assignments without topics
This wiki page is for the description of changes made under E2351 OSS assignment for Fall 2023, CSC/ECE 517.
Team Members
- Kyle Pichon
- Helen Solomon
- Erik Lopez-Godinez (Phase 1)
- Basaveswara Mukesh Suryadevara (Final Phase)
Mentor
- Dr. Ed Gehringer
Problem Statement
The previous team, Project E2115, implemented the mentor_management.rb file which completed tasks such as auto assigning a mentor if the assignment chose to have that capability when the team is >50% full and also emailing the chosen mentor. It also implemented the methods of the mentor_management.rb in other files so that when the team surpassed 50% through inviting team members that a mentor was automatically assigned. The previous team implemented a lot for the new mentor duty that was planned to be added but they did not make a way to assign mentors, not through the UI or import so the changes they made could not be properly implemented. That is why our team was tasked with creating those changes in the UI and import so that participants could be made into mentors. Once we were able to have their changes be made there were some other things that needed to be changed.
- Their algorithm was not properly balancing the mentor in terms of the amount of teams they would mentor.
- We also noticed that when mass creating teams automatically it would not auto-assign mentors.
- We also added changes to the users team members table so that the mentor is identifiable since perhaps in the future their would be a specific review for the mentor which would not be the same for if reviewing another student.
- We also added a new view for the mentor since the Your Team view would only show the first team and mentors would be on multiple so we would need to display all their teams.
Design Document (Final Phase)
For the second half of this project, a refactoring of the first half is needed. There are 4 key points that will be addressed during this refactoring to clean up the code related to the automatic mentor management system for assignments that have it enabled.
1) Discard changes related to import functionality. This will be handled by a different project and entangling mentor management into it would add unneeded complexity to that future project when standard import then swapping a user to be a mentor from the UI would suffice for now.
2) Make sure that for every scenario in which a team user is created and added to a team, that a single method call is used.
3) Change the duty field of participants to be a boolean flag more in line with the can_review, can_submit, etc. flags that are used for other permissions. This was initially avoided because it will require a database migration but after reviewing how this choice complicated the code, this solution has been deemed more appropriate. It will be called can_mentor and all current checks in the code for :duty == 'mentor' will be exchanged for :can_mentor to replicate functionality.
4) Create a subclass of AssignmentTeam called MentoredTeam that will have overridden methods that loop-in the MentorManagement workflows where appropriate.
Beyond this general improvements of the code such as redoing comments to be much more detailed and fixing some method names to better represent what they actually do.
User Credentials
For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
- Instructor login: username -> instructor6, password -> password
Expertiza Background
Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. It allows students to review each other’s work and improve their work upon this feedback.
Description of the current project
First Demo -- https://youtu.be/WqBjv5Sluxg
Second Demo (Final Phase) -- https://youtu.be/wsTzlgR3oWs
VCL Instance -- http://152.7.178.198:8080
E2351 is an Expertiza based OSS project that handles the relationship between mentors, teams, and assignments. The ability to assign mentors with topics is implemented but lacked the ability to manage mentors for assignments without topics. Some refactoring within the assignment logic from the remnants of Project E2115 allowed us to accomplish some of our objectives.
Objectives
- Enable the UI to be able to assign mentors role/duty to participant
- Configure the import process to read an additional role/duty column
- Fix the balancing of mentors using the auto assign functionality from the previous team
- Fix the bug stopping mentors to be assigned when using the Automatically Create Teams function
- Alter the participants table the student sees so that the mentor is identifiable in their team members table
- Adding a new view for the mentor to view all the teams they are currently mentoring for the assignment
Files modified in phase 1 and the UI Changes
Enable the UI to be able to assign mentors role/duty to participant
1. app/controller/particpants_controller.rb (Update to take into account duty)
2. app/helpers/participants_helper.rb (Update to take into account duty)
3. app/models/assignment.rb (Update to take into account duty)
4. app/models/participant.rb (Update to take into account duty)
5. app/views/participants/_participant.html.erb (Drop down UI)(Updated the table to diplay current duty so a mentor is easily identifiable in the table)
6. app/views/shared_scripts/_user_list.html.erb (Shows participants duty header for the column)
7. app/views/shared_scripts/_add_individual.html.erb (Updated the singular import of a user to be able to import them as mentor)
Configure the import process to read an additional role/duty column
8. app/controllers/import_file_controller.rb (Added new param for the duty/role)
9. app/models/assignment_participant.rb (Updated the amount of expected items since duty is added and how a AssignmentParticipant is created)
10. app/views/import_file/_participant.html.erb (Updated table to account for duty)
11. app/views/participants/_links.html.erb (Updated expected fields to expect the new duty column)
Fix the balancing of mentors using the auto assign functionality from the previous team
12. app/models/mentor_management.rb (Balancing Algo)
Fix the bug stopping mentors to be assigned when using the Automatically Create Teams function
13. app/controllers/teams_users_controller.rb (Fixed auto team creation with auto_mentor)
14. app/models/invitation.rb (Fixed auto team creation with auto_mentor)
15. app/models/team.rb (Fixed auto team creation with auto_mentor)
16. app/models/teams_user.rb (Fixed auto team creation with auto_mentor)
Alter the participants table the student sees so that the mentor is identifiable in their team members table
17. app/views/student_teams/view.html.erb (Updated students team members table to identify the mentor)
Adding a new view for the mentor to view all the teams they are currently mentoring for the assignment
18. app/controllers/student_teams_controller.rb (Updated so that the new mentor view can be accessed)
19. config/routes.rb (Updated the route for student_teams for the new mentor view)
20. app/views/student_task/view.html.erb (Updated the student task view so that a mentor has new All Teams link so that the mentor can view all the teams they are mentoring)
21. NEW app/views/student_teams/mentor.html.erb (Added a new view for a mentor to view all their teams)
Changes made
1.
Permission definitions are altered to include 'can_mentor' within Participant Controller to indicate duty of participant.
2.
Permission setting is altered to include 'can_mentor' within Participant Controller to indicate duty.
3.
Making sure to account for duty of participant when being added to an assignment.
4.
Adding an additional authorization that is acquired from permissions set for participant.
Changes 1-4 were done to update the creation of participants to account for the duty field that was added by the previous mentor management group to enable filtering for mentors. The filtering requires that when a participant has the duty field filled with a string matching "mentor" but this functionality was not present. These changes fix this oversight.
5. (Drop down UI)(Updated the table to diplay current duty so a mentor is easily identifiable in the table)
- a)
(1) app/views/participants/_participant.html.erb
Add the drop-down option for mentor and define set of permissions for role.
- a)
- b)
(2) app/views/participants/_participant.html.erb
Update to take into account duty
- b)
- c)
(3) app/views/participants/_participant.html.erb
Adding duty column to participants.
- c)
6.
Shows participants duty header for the column
7.
Updated the singular import of a user to be able to import them as mentor
Changes 5-7 were the general UI fixes needed to show the mentor in the participants list allow for a participant to be individually added by user id already as a mentor, and allow for any participants permissions be changed to mentor from the already present dropdown. Visuals highlighting these changes are visible in the above section.
8.
Added new param for the duty/role
9.
Updated table to account for duty
10.
Updated expected fields to expect the new duty column
11.
Updated the amount of expected items since duty is added and how a AssignmentParticipant is created
Changes 8-11 are focused around the mass import functionality and adapting it to work with auto mentor assignment. The preview view after importing file needed an additional column to show the duty field of the participants, and the importing of files without headers needed an additional expected parameter to be added to also account for duty.
12.
Adjusting the balancing algorithm.
Change 12 is fixing the balancing algorithm so each mentor will have almost the same number of teams as all other mentors on the assignment. The previous implementation was giving a single mentor to every group. An incorrect query was being done, and fixing this was the only issue needed to be resolved for full functionality.
13.
Fixed auto team creation with auto_mentor.
14.
Fixed auto team creation with auto_mentor.
15.
Fixed auto team creation with auto_mentor.
16.
Fixed auto team creation with auto_mentor.
Changes 13-16 are about propagating the auto_assign_mentor functionality to the areas highlighted by the previous group that they were supposed to target. #16 shows a method added teams_user that loops in the mentor management check immediately after adding a user to a team (used in 2 places currently, method was created for easier expansion). The areas that were targeted were users accepting an invitation to add someone to their team and the loop for adding users to mass created teams.
17.
Updated students team members table to identify the mentor.
18.
Updated the student task view so that a mentor has new All Teams link so that the mentor can view all the teams they are mentoring.
19.
Updated so that the new mentor view can be accessed.
20.
Updated the route for student_teams for the new mentor view.
21.
- a)
NEW FILE app/views/student_teams/mentor.html.erb
Added a new view for a mentor to view all their teams.
- a)
- b)
NEW FILE app/views/student_teams/mentor.html.erb
Added a new view for a mentor to view all their teams.
- b)
Changes 17-21 are related to the views for students and mentors to view their teams. #17 is a change to the student viewing their team, making it so the mentor is easily determined from the list of team members. #18 is a small text change to indicate to mentors that when clicking what was previously the 'view team' button, it will now show all teams they are on (but themselves and other mentors are not listed; just the students are listed). Changes 19-21 are related to this new 'All Teams' link, a link to a new webpage that shows all teams a mentor is on. This needed the new html file, a new method added to the controller so that when it returns the default rails behavior of rendering a page with a matching file name to the method name (the new file made), and a route to handle to this request.
Final Phase Changes
The following files had their references to 'duty' changed to be the new boolean 'can_mentor'
1. app/controller/particpants_controller.rb
2. app/helpers/participants_helper.rb
3. app/models/assignment.rb
4. app/models/participant.rb
5. app/controllers/import_file_controller.rb
6. app/models/assignment_participant.rb
7. app/models/team.rb
8. app/models/mentor_management.rb
An example from mentor_management.rb
The following files had any reference of 'add_member_mentor_check' reverted back to 'add_member', the method was also removed entirely (shown in image below)
1. app/controllers/teams_users_controller.rb
2. app/models/invitation.rb
3. app/models/team.rb
4. app/models/teams_user.rb
Alongside the above reversion, a new subclass of AssignmentTeam called MentoredTeam was created which has its 'add_member' method overridden with the previous implementation of 'add_member_mentor_check'
app/models/mentored_team.rb
To allow for this new subclass to be created and function correctly, some modifications had to be made to the Teams Controller. The session[:team_type] object was being used for multiple purposes which did now scale easily for subclasses of either CourseTeam or AssignmentTeam to be integrated easily. As a work around, the session[:create_type] was introduced to remove some responsibility from session[:team_type] and facilitate the creation process for subclass of the prespecified Assignment and Course Teams.
Testing
To test this project, we tested the development mode of our forked Expertiza branch against different scenarios. Given a test skeleton by teaching staff, we were able to ensure that the site was able to assign mentors automatically to a team given that the assignment allows the functionality and the teams have more than 50% the team capacity. Our tests were also able to validate input like checking for cases where no mentors are assigned to an assignment and whether it returns the mentor with the lowest team count to allow balanced responsibilities.
System Testing
The steps below were followed to test the UI of the application:
1. Login as instructor with credentials at top of wiki page
2. Go to Manage Assignments
3. Click Add Participants to a particular assignment and the list of participants for the assignment should be shown
4. If the role of any partipants needs to be changed, use the dropdown to the very right of the student
5. If participants outside of the current list needs to be added to the assignment, the user has the option of importing through a file or using the single import option via the search bar (both can be found at the top of the Assignment Participant List view). This can also be used as a way to change roles of a participant being added to an assignment.
6. Once participants are in place, instructor can create teams by navigating back to the Manage Assignments page and clicking Create Teams.
7. Instructor is now presented the option of Create Teams, Import Teams, etc. By clicking Create Teams, they can create a team of n students and assuming n is greater than 50% of the max team size, a mentor will be designated for each team in a way that responsibilities are balanced across all mentors.
A single team can also be created by first setting a team and individually adding members to the team. Mentor should added once members have reached 50% capacity.
8. To ensure teams are assigned to participants, instructor can impersonate the mentor and student view by going to the Manage tab and navigating to Impersonate User. Entering the participant ID will take you to their view. Clicking on the particular assignment will take you to a page that lets you view links 'Your Team' (for students) and 'All Teams' (for mentors). These pages will let you view the teams the user is assigned to along with showing who the mentor is (from student view).
Unit Testing
spec/models/mentor_management_spec.rb
Tested the model class MentorManagement.rb
Using the test skeleton provided by teaching staff, we were able to test the mentor_management.rb class with 23 test scenarios. Various scenarios were tested including:
- Automatically assigning a mentor once half-capacity has been reached
- Retrieving mentors for an assignment
- Ordering mentors by number of teams they mentor
- Mentor is email notified when assigned a team
- Error checking
Future improvements
Future improvements of this feature would be to move away from the current implementation of checking mentors which is reliant on a single string field attached to each participant and to base it upon an attached duty object. The duty object already exists, but was not the path taken by E2115. We finished and fixed their implementation, but changing this may be desirable.
The other way to improve this feature would be to allow it to be functional for assignments without topics. This may be a difficult extension depending on how participants, topics, and teams are linked, but that is yet to be determined.