Expertiza_Wiki - User contributions [en]

File:Assignment team mentor v2.png

2020-11-18T04:52:57Z

Srcapezz:

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-11-18T04:52:15Z

Srcapezz: /* Files Modified/Created */

==Project Overview==
=== Background ===
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. Keeping this in mind our code is set to work under the following conditions:

*'''Assignment teams created for an assignment without topics'''
*'''Mentors (''Instructors and TAs'') are only assigned to assignment teams if they have been added to an assignment as participants'''

We've created the following [https://youtu.be/RQJinX6gcrA video] to demonstrate the added functionality. As well as the following [https://youtu.be/nAS0WxzFAsA video] which demonstrates what happens when teams are created when no mentors have been added as participants to an assignment.

=== Objectives ===
1. Assign a TA or instructor as a mentor for a team created for an assignment without topics 
2. Notify mentor and individuals of a team via Email when a mentor has been assigned 

=== Previous Work ===
We learned from previous implementations and looked to avoid the following pitfalls when implementing our solution:

*Code was merged from the previous team, but not refactored, so a lot of unused code remained.
*Should have followed a better naming convention for methods
*Some redundant codes in the views could be DRYed out.
*Commented code should be removed.
*Some complex logic is added but not explained in the comments.
*Code should be placed in most relevant classes. (E.g. Do not put email code in the Team class).
*Documentation doesn't accurately represent implementation.
*Lacked sufficient detail for Test section.

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

=== Program Design ===
Our implementation begins when an assignment team is created. If the assignment is associated with a topic, the created team will not be assigned a mentor. If the assignment does not have a topic, a hash of potential mentors is retrieved. This hash is created from the TAs and instructors added to the assignment as participants. The keys of the hash correspond to the mentor's participant id while their values are the number of times the mentor has been assigned to mentor teams. The mentor with the lowest number of assigned teams will be the next mentor assigned to a newly created team. Once the team is assigned a mentor, an email is sent out to the mentor and students in the team to notify them of their mentor assignment.
 
'''First Design: '''
 
[[File:Program_Design.png]]
 
 
'''Final Design: '''
 
[[File:Final_Program_Design.png]]
 

We created the following assignment_teams_mentors table with the following connections to existing tables. The new table created is responsible for storing all the mentors assigned to the various teams created. In order to do so, the assignment_team_mentors table will reference the participants and teams tables.
 
[[File:Schema_Modifications_UML_2.png|500px]]

We will also modify the participants table to add an additional Boolean column, '''can_mentor'''. This column will help determine what TAs and instructors can mentor for a specified assignment.

 
Currently instructors see the corresponding view when looking at teams associated with an assignment:
 
[[File:Instructor_view_before.png|1000px]]

Our team is proposing to add an additional "Mentors" column in the instructor view:
 
[[File:Instructor_view_after.png|1000px]]

Currently students see the corresponding view when looking at their team for an assignment: 
[[File:Student_view_before.png|1000px]]

 
Our team is proposing to add an additional "Mentors" section in the student view:
 
[[File:Student_view_after.png|1000px]]

=== Files Modified/Created ===
These are the files we have modified/created throughout our project and a brief excerpt about what was done:

'''Database'''
*Schema.rb
**Created assignment_team_mentors table which references the participants table and teams tables thru foreign keys created with the assignment_team_mentors_id column and assignment_team_id column. The assignment_team_mentors table is responsible for storing all the mentors assigned to the various assignment teams created
**Created a can_mentor column for the participants table in order to be able to know who was a mentor and who was a student

'''Models'''
*assignment_team_mentor.rb
**responsible for ensuring mentor with the least number of teams mentored, gets assigned to the next team created.
**added mailer functionality for notifying the mentor
[[File:assignment_team_mentor_v2.png]]

*assignment_team.rb
**established a has_one: active record relation with AssignmentTeamMentor model. This ensures a team only has one team mentor.
[[File:Assignment_team_rb.png]]

*participant.rb
**established a has_many: active record relation with AssignmentTeamMentor model. This provides the flexibility of a potential mentor added as a participant to an assignment, to mentor multiple teams created for an assignment.
**added a function to set the new can_mentor column for a participant
**added a function to get a list of all participants who can be mentors for a specified assignment based on the can_mentor column
[[File:participant_get_can_mentor.png]]
[[File:participant_get_mentors.png]]

'''Controllers'''
*teams_controller.rb
**Calls on AssignmentTeamMentor to assign mentor for instructor created teams.
**added functionality to send email to mentor when assigned to a team.
*student_teams_controllers.rb
**Calls on AssignmentTeamMentor to assign mentor for student created teams.
*teams_user_controller.rb
**added code to send the email when a user is added to a team to the mentor.
*participants_controller.rb
**updates the can_mentor column of a participant when they are added to an assignment

'''Views'''
*views/tree_display/_page_footer.html.erb
**displays mentor column header.
*views/tree_display/_row_header.html.erb
**displays either mentor assigned or "No mentor assigned" for team level. For team participant level, blank cell is displayed.

*views/student_teams/view.html.erb
**responsible for displaying to a student the mentor assigned to their team for an assignment.

*views/mailer/notify_member.html.erb
**responsible for managing the template of the mail sent to the mentor
'''Mailers'''
*app/mailers/mailer.rb
**responsible for managing the mailer functionally for notifying the member

'''RSPEC'''

=== Testing Plan ===

==== ''Edge Cases'' ====
The following are scenarios our team has thought about:

Edge Case 1: How will we handle the "Has topic?" check box being changed when editing the assignment in the instructor view. This button is how we decide if we need to assign mentors to a team.
Option A: Always run our algorithm for each assignment made and only show which mentors are assigned if the "Has topic?" is not checked
Option B: Add the functionality to add and remove mentors for all assignments, not just assignments without topics then add and remove mentors when an assignment is edited.
 
[[File:Instructor_hasTopics_checkbox.png|500px]]

 
Edge Case 2: No mentors exist
Option A: Don't assign mentors
Option B: Prevent creation of teams

==== ''RSpec Test'' ====
RSpec test to check:
* Validation of the models
* Functionality of controllers

==== ''UI Test'' ====
As an instructor we were able to confirm the following UI changes after mentors were assigned to teams: 
[[File:Instructor_view.png|1000px]]
 
As a student we were able to confirm the following UI changes when a mentor has been assigned to their team: 
[[File:Student_view.png|1000px]]

This is what the mentor should see: 
[[File:Email to mentor.png]]

=== Possible Future Enhancements ===

#Providing ability to manually select the mentor for a team created.
#Refactor email functionality code.

==References==
[https://github.com/GitHubSanti/expertiza/tree/beta_project4 Github Repository] 
[https://github.com/expertiza/expertiza/pull/1826 Pull Request] 
[https://youtu.be/RQJinX6gcrA assigning of team mentor to newly created team video] 
[https://youtu.be/nAS0WxzFAsA team creation without mentor participants video] 
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

==Team==
Santiago Sepulveda 
Skieler Capezza 
Liam Donovan 
Javier Sanchez 
'''Mentor:''' Yulin Zhang

File:Assignment team mentor.png

2020-11-18T04:51:41Z

Srcapezz: Srcapezz uploaded a new version of File:Assignment team mentor.png

File:Assignment team mentor.png

2020-11-18T04:51:20Z

Srcapezz: Srcapezz uploaded a new version of File:Assignment team mentor.png

File:Assignment team mentor.png

2020-11-18T04:50:41Z

Srcapezz: Srcapezz uploaded a new version of File:Assignment team mentor.png

File:Assignment team mentor.png

2020-11-18T04:48:40Z

Srcapezz: Srcapezz uploaded a new version of File:Assignment team mentor.png

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-11-17T23:42:23Z

Srcapezz: /* Files Modified/Created */

==Project Overview==
=== Background ===
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. Keeping this in mind our code is set to work under the following conditions:

*'''Assignment teams created for an assignment without topics'''
*'''Mentors (''Instructors and TAs'') are only assigned to assignment teams if they have been added to an assignment as participants'''

We've created the following [https://youtu.be/RQJinX6gcrA video] to demonstrate the added functionality. As well as the following [https://youtu.be/nAS0WxzFAsA video] which demonstrates what happens when teams are created when no mentors have been added as participants to an assignment.

=== Objectives ===
1. Assign a TA or instructor as a mentor for a team created for an assignment without topics 
2. Notify mentor and individuals of a team via Email when a mentor has been assigned 

=== Previous Work ===
We learned from previous implementations and looked to avoid the following pitfalls when implementing our solution:

*Code was merged from the previous team, but not refactored, so a lot of unused code remained.
*Should have followed a better naming convention for methods
*Some redundant codes in the views could be DRYed out.
*Commented code should be removed.
*Some complex logic is added but not explained in the comments.
*Code should be placed in most relevant classes. (E.g. Do not put email code in the Team class).
*Documentation doesn't accurately represent implementation.
*Lacked sufficient detail for Test section.

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

=== Program Design ===
Our implementation begins when an assignment team is created. If the assignment is associated with a topic, the created team will not be assigned a mentor. If the assignment does not have a topic, a hash of potential mentors is retrieved. This hash is created from the TAs and instructors added to the assignment as participants. The keys of the hash correspond to the mentor's participant id while their values are the number of times the mentor has been assigned to mentor teams. The mentor with the lowest number of assigned teams will be the next mentor assigned to a newly created team. Once the team is assigned a mentor, an email is sent out to the mentor and students in the team to notify them of their mentor assignment.
 
[[File:Program_Design.png]]
 

We created the following assignment_teams_mentors table with the following connections to existing tables. The new table created is responsible for storing all the mentors assigned to the various teams created. In order to do so, the assignment_team_mentors table will reference the participants and teams tables.
 
[[File:Schema_Modifications_UML_2.png|500px]]

We will also modify the participants table to add an additional Boolean column, '''can_mentor'''. This column will help determine what TAs and instructors can mentor for a specified assignment.

 
Currently instructors see the corresponding view when looking at teams associated with an assignment:
 
[[File:Instructor_view_before.png|1000px]]

Our team is proposing to add an additional "Mentors" column in the instructor view:
 
[[File:Instructor_view_after.png|1000px]]

Currently students see the corresponding view when looking at their team for an assignment: 
[[File:Student_view_before.png|1000px]]

 
Our team is proposing to add an additional "Mentors" section in the student view:
 
[[File:Student_view_after.png|1000px]]

=== Files Modified/Created ===
These are the files we have modified/created throughout our project and a brief excerpt about what was done:

'''Database'''
*Schema.rb
**Created assignment_team_mentors table which references the participants table and teams tables thru foreign keys created with the assignment_team_mentors_id column and assignment_team_id column. The assignment_team_mentors table is responsible for storing all the mentors assigned to the various assignment teams created
**Created a can_mentor column for the participants table in order to be able to know who was a mentor and who was a student

'''Models'''
*assignment_team_mentor.rb
**responsible for ensuring mentor with the least number of teams mentored, gets assigned to the next team created.
**added mailer functionality for notifying the mentor
[[File:assignment_team_mentor.png]]

*assignment_team.rb
**established a has_one: active record relation with AssignmentTeamMentor model. This ensures a team only has one team mentor.
*participant.rb
**established a has_many: active record relation with AssignmentTeamMentor model. This provides the flexibility of a potential mentor added as a participant to an assignment, to mentor multiple teams created for an assignment.
**added a function to set the new can_mentor column for a participant
**added a function to get a list of all participants who can be mentors for a specified assignment based on the can_mentor column
[[File:participant_get_can_mentor.png]]
[[File:participant_get_mentors.png]]

'''Controllers'''
*teams_controller.rb
**Calls on AssignmentTeamMentor to assign mentor for instructor created teams.
**added functionality to send email to mentor when assigned to a team.
*student_teams_controllers.rb
**Calls on AssignmentTeamMentor to assign mentor for student created teams.
*teams_user_controller.rb
**added code to send the email when a user is added to a team to the mentor.
*participants_controller.rb
**updates the can_mentor column of a participant when they are added to an assignment

'''Views'''
*views/tree_display/_page_footer.html.erb
**displays mentor column header.
*views/tree_display/_row_header.html.erb
**displays either mentor assigned or "No mentor assigned" for team level. For team participant level, blank cell is displayed.

*views/student_teams/view.html.erb
**responsible for displaying to a student the mentor assigned to their team for an assignment.

*views/mailer/notify_member.html.erb
**responsible for managing the template of the mail sent to the mentor
'''Mailers'''
*app/mailers/mailer.rb
**responsible for managing the mailer functionally for notifying the member

'''RSPEC'''

=== Testing Plan ===

==== ''Edge Cases'' ====
The following are scenarios our team has thought about:

Edge Case 1: How will we handle the "Has topic?" check box being changed when editing the assignment in the instructor view. This button is how we decide if we need to assign mentors to a team.
Option A: Always run our algorithm for each assignment made and only show which mentors are assigned if the "Has topic?" is not checked
Option B: Add the functionality to add and remove mentors for all assignments, not just assignments without topics then add and remove mentors when an assignment is edited.
 
[[File:Instructor_hasTopics_checkbox.png|500px]]

 
Edge Case 2: No mentors exist
Option A: Don't assign mentors
Option B: Prevent creation of teams

==== ''RSpec Test'' ====
RSpec test to check:
* Validation of the models
* Functionality of controllers

==== ''UI Test'' ====
In the UI test we are going to verify that:
As an instructor should be able to see, the following: 
[[File:Instructor_view_after.png|1000px]]
 
A student should be able to see the following after viewing their team for an assignment: 
[[File:Student_view_after.png|1000px]]

This is what the mentor should see: 
[[File:Email to mentor.png]]

=== Potential Future Enhancements ===

#Implementing manual mentor assignment capability for instructors assign mentors to a team.
#Refactor email functionality code.

==References==
[https://github.com/expertiza/expertiza/pull/1826 Github Repository] 
[https://github.com/expertiza/expertiza/pull/1826 Pull Request] 
[https://youtu.be/RQJinX6gcrA mentor assignment video] 
[https://youtu.be/nAS0WxzFAsA team creation without mentor participants video] 
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

==Team==
Santiago Sepulveda 
Skieler Capezza 
Liam Donovan 
Javier Sanchez 
'''Mentor:''' Yulin Zhang

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-11-17T23:42:11Z

Srcapezz: /* Files Modified/Created */

==Project Overview==
=== Background ===
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. Keeping this in mind our code is set to work under the following conditions:

*'''Assignment teams created for an assignment without topics'''
*'''Mentors (''Instructors and TAs'') are only assigned to assignment teams if they have been added to an assignment as participants'''

We've created the following [https://youtu.be/RQJinX6gcrA video] to demonstrate the added functionality. As well as the following [https://youtu.be/nAS0WxzFAsA video] which demonstrates what happens when teams are created when no mentors have been added as participants to an assignment.

=== Objectives ===
1. Assign a TA or instructor as a mentor for a team created for an assignment without topics 
2. Notify mentor and individuals of a team via Email when a mentor has been assigned 

=== Previous Work ===
We learned from previous implementations and looked to avoid the following pitfalls when implementing our solution:

*Code was merged from the previous team, but not refactored, so a lot of unused code remained.
*Should have followed a better naming convention for methods
*Some redundant codes in the views could be DRYed out.
*Commented code should be removed.
*Some complex logic is added but not explained in the comments.
*Code should be placed in most relevant classes. (E.g. Do not put email code in the Team class).
*Documentation doesn't accurately represent implementation.
*Lacked sufficient detail for Test section.

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

=== Program Design ===
Our implementation begins when an assignment team is created. If the assignment is associated with a topic, the created team will not be assigned a mentor. If the assignment does not have a topic, a hash of potential mentors is retrieved. This hash is created from the TAs and instructors added to the assignment as participants. The keys of the hash correspond to the mentor's participant id while their values are the number of times the mentor has been assigned to mentor teams. The mentor with the lowest number of assigned teams will be the next mentor assigned to a newly created team. Once the team is assigned a mentor, an email is sent out to the mentor and students in the team to notify them of their mentor assignment.
 
[[File:Program_Design.png]]
 

We created the following assignment_teams_mentors table with the following connections to existing tables. The new table created is responsible for storing all the mentors assigned to the various teams created. In order to do so, the assignment_team_mentors table will reference the participants and teams tables.
 
[[File:Schema_Modifications_UML_2.png|500px]]

We will also modify the participants table to add an additional Boolean column, '''can_mentor'''. This column will help determine what TAs and instructors can mentor for a specified assignment.

 
Currently instructors see the corresponding view when looking at teams associated with an assignment:
 
[[File:Instructor_view_before.png|1000px]]

Our team is proposing to add an additional "Mentors" column in the instructor view:
 
[[File:Instructor_view_after.png|1000px]]

Currently students see the corresponding view when looking at their team for an assignment: 
[[File:Student_view_before.png|1000px]]

 
Our team is proposing to add an additional "Mentors" section in the student view:
 
[[File:Student_view_after.png|1000px]]

=== Files Modified/Created ===
These are the files we have modified/created throughout our project and a brief excerpt about what was done:

'''Database'''
*Schema.rb
**Created assignment_team_mentors table which references the participants table and teams tables thru foreign keys created with the assignment_team_mentors_id column and assignment_team_id column. The assignment_team_mentors table is responsible for storing all the mentors assigned to the various assignment teams created
**Created a can_mentor column for the participants table in order to be able to know who was a mentor and who was a student

'''Models'''
*assignment_team_mentor.rb
**responsible for ensuring mentor with the least number of teams mentored, gets assigned to the next team created.
**added mailer functionality for notifying the mentor
[[File:assignment_team_mentor.png|750px]]

*assignment_team.rb
**established a has_one: active record relation with AssignmentTeamMentor model. This ensures a team only has one team mentor.
*participant.rb
**established a has_many: active record relation with AssignmentTeamMentor model. This provides the flexibility of a potential mentor added as a participant to an assignment, to mentor multiple teams created for an assignment.
**added a function to set the new can_mentor column for a participant
**added a function to get a list of all participants who can be mentors for a specified assignment based on the can_mentor column
[[File:participant_get_can_mentor.png]]
[[File:participant_get_mentors.png]]

'''Controllers'''
*teams_controller.rb
**Calls on AssignmentTeamMentor to assign mentor for instructor created teams.
**added functionality to send email to mentor when assigned to a team.
*student_teams_controllers.rb
**Calls on AssignmentTeamMentor to assign mentor for student created teams.
*teams_user_controller.rb
**added code to send the email when a user is added to a team to the mentor.
*participants_controller.rb
**updates the can_mentor column of a participant when they are added to an assignment

'''Views'''
*views/tree_display/_page_footer.html.erb
**displays mentor column header.
*views/tree_display/_row_header.html.erb
**displays either mentor assigned or "No mentor assigned" for team level. For team participant level, blank cell is displayed.

*views/student_teams/view.html.erb
**responsible for displaying to a student the mentor assigned to their team for an assignment.

*views/mailer/notify_member.html.erb
**responsible for managing the template of the mail sent to the mentor
'''Mailers'''
*app/mailers/mailer.rb
**responsible for managing the mailer functionally for notifying the member

'''RSPEC'''

=== Testing Plan ===

==== ''Edge Cases'' ====
The following are scenarios our team has thought about:

Edge Case 1: How will we handle the "Has topic?" check box being changed when editing the assignment in the instructor view. This button is how we decide if we need to assign mentors to a team.
Option A: Always run our algorithm for each assignment made and only show which mentors are assigned if the "Has topic?" is not checked
Option B: Add the functionality to add and remove mentors for all assignments, not just assignments without topics then add and remove mentors when an assignment is edited.
 
[[File:Instructor_hasTopics_checkbox.png|500px]]

 
Edge Case 2: No mentors exist
Option A: Don't assign mentors
Option B: Prevent creation of teams

==== ''RSpec Test'' ====
RSpec test to check:
* Validation of the models
* Functionality of controllers

==== ''UI Test'' ====
In the UI test we are going to verify that:
As an instructor should be able to see, the following: 
[[File:Instructor_view_after.png|1000px]]
 
A student should be able to see the following after viewing their team for an assignment: 
[[File:Student_view_after.png|1000px]]

This is what the mentor should see: 
[[File:Email to mentor.png]]

=== Potential Future Enhancements ===

#Implementing manual mentor assignment capability for instructors assign mentors to a team.
#Refactor email functionality code.

==References==
[https://github.com/expertiza/expertiza/pull/1826 Github Repository] 
[https://github.com/expertiza/expertiza/pull/1826 Pull Request] 
[https://youtu.be/RQJinX6gcrA mentor assignment video] 
[https://youtu.be/nAS0WxzFAsA team creation without mentor participants video] 
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

==Team==
Santiago Sepulveda 
Skieler Capezza 
Liam Donovan 
Javier Sanchez 
'''Mentor:''' Yulin Zhang

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-11-17T23:42:00Z

Srcapezz: /* Files Modified/Created */

==Project Overview==
=== Background ===
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. Keeping this in mind our code is set to work under the following conditions:

*'''Assignment teams created for an assignment without topics'''
*'''Mentors (''Instructors and TAs'') are only assigned to assignment teams if they have been added to an assignment as participants'''

We've created the following [https://youtu.be/RQJinX6gcrA video] to demonstrate the added functionality. As well as the following [https://youtu.be/nAS0WxzFAsA video] which demonstrates what happens when teams are created when no mentors have been added as participants to an assignment.

=== Objectives ===
1. Assign a TA or instructor as a mentor for a team created for an assignment without topics 
2. Notify mentor and individuals of a team via Email when a mentor has been assigned 

=== Previous Work ===
We learned from previous implementations and looked to avoid the following pitfalls when implementing our solution:

*Code was merged from the previous team, but not refactored, so a lot of unused code remained.
*Should have followed a better naming convention for methods
*Some redundant codes in the views could be DRYed out.
*Commented code should be removed.
*Some complex logic is added but not explained in the comments.
*Code should be placed in most relevant classes. (E.g. Do not put email code in the Team class).
*Documentation doesn't accurately represent implementation.
*Lacked sufficient detail for Test section.

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

=== Program Design ===
Our implementation begins when an assignment team is created. If the assignment is associated with a topic, the created team will not be assigned a mentor. If the assignment does not have a topic, a hash of potential mentors is retrieved. This hash is created from the TAs and instructors added to the assignment as participants. The keys of the hash correspond to the mentor's participant id while their values are the number of times the mentor has been assigned to mentor teams. The mentor with the lowest number of assigned teams will be the next mentor assigned to a newly created team. Once the team is assigned a mentor, an email is sent out to the mentor and students in the team to notify them of their mentor assignment.
 
[[File:Program_Design.png]]
 

We created the following assignment_teams_mentors table with the following connections to existing tables. The new table created is responsible for storing all the mentors assigned to the various teams created. In order to do so, the assignment_team_mentors table will reference the participants and teams tables.
 
[[File:Schema_Modifications_UML_2.png|500px]]

We will also modify the participants table to add an additional Boolean column, '''can_mentor'''. This column will help determine what TAs and instructors can mentor for a specified assignment.

 
Currently instructors see the corresponding view when looking at teams associated with an assignment:
 
[[File:Instructor_view_before.png|1000px]]

Our team is proposing to add an additional "Mentors" column in the instructor view:
 
[[File:Instructor_view_after.png|1000px]]

Currently students see the corresponding view when looking at their team for an assignment: 
[[File:Student_view_before.png|1000px]]

 
Our team is proposing to add an additional "Mentors" section in the student view:
 
[[File:Student_view_after.png|1000px]]

=== Files Modified/Created ===
These are the files we have modified/created throughout our project and a brief excerpt about what was done:

'''Database'''
*Schema.rb
**Created assignment_team_mentors table which references the participants table and teams tables thru foreign keys created with the assignment_team_mentors_id column and assignment_team_id column. The assignment_team_mentors table is responsible for storing all the mentors assigned to the various assignment teams created
**Created a can_mentor column for the participants table in order to be able to know who was a mentor and who was a student

'''Models'''
*assignment_team_mentor.rb
**responsible for ensuring mentor with the least number of teams mentored, gets assigned to the next team created.
**added mailer functionality for notifying the mentor
[[File:assignment_team_mentor.png|500px]]

*assignment_team.rb
**established a has_one: active record relation with AssignmentTeamMentor model. This ensures a team only has one team mentor.
*participant.rb
**established a has_many: active record relation with AssignmentTeamMentor model. This provides the flexibility of a potential mentor added as a participant to an assignment, to mentor multiple teams created for an assignment.
**added a function to set the new can_mentor column for a participant
**added a function to get a list of all participants who can be mentors for a specified assignment based on the can_mentor column
[[File:participant_get_can_mentor.png]]
[[File:participant_get_mentors.png]]

'''Controllers'''
*teams_controller.rb
**Calls on AssignmentTeamMentor to assign mentor for instructor created teams.
**added functionality to send email to mentor when assigned to a team.
*student_teams_controllers.rb
**Calls on AssignmentTeamMentor to assign mentor for student created teams.
*teams_user_controller.rb
**added code to send the email when a user is added to a team to the mentor.
*participants_controller.rb
**updates the can_mentor column of a participant when they are added to an assignment

'''Views'''
*views/tree_display/_page_footer.html.erb
**displays mentor column header.
*views/tree_display/_row_header.html.erb
**displays either mentor assigned or "No mentor assigned" for team level. For team participant level, blank cell is displayed.

*views/student_teams/view.html.erb
**responsible for displaying to a student the mentor assigned to their team for an assignment.

*views/mailer/notify_member.html.erb
**responsible for managing the template of the mail sent to the mentor
'''Mailers'''
*app/mailers/mailer.rb
**responsible for managing the mailer functionally for notifying the member

'''RSPEC'''

=== Testing Plan ===

==== ''Edge Cases'' ====
The following are scenarios our team has thought about:

Edge Case 1: How will we handle the "Has topic?" check box being changed when editing the assignment in the instructor view. This button is how we decide if we need to assign mentors to a team.
Option A: Always run our algorithm for each assignment made and only show which mentors are assigned if the "Has topic?" is not checked
Option B: Add the functionality to add and remove mentors for all assignments, not just assignments without topics then add and remove mentors when an assignment is edited.
 
[[File:Instructor_hasTopics_checkbox.png|500px]]

 
Edge Case 2: No mentors exist
Option A: Don't assign mentors
Option B: Prevent creation of teams

==== ''RSpec Test'' ====
RSpec test to check:
* Validation of the models
* Functionality of controllers

==== ''UI Test'' ====
In the UI test we are going to verify that:
As an instructor should be able to see, the following: 
[[File:Instructor_view_after.png|1000px]]
 
A student should be able to see the following after viewing their team for an assignment: 
[[File:Student_view_after.png|1000px]]

This is what the mentor should see: 
[[File:Email to mentor.png]]

=== Potential Future Enhancements ===

#Implementing manual mentor assignment capability for instructors assign mentors to a team.
#Refactor email functionality code.

==References==
[https://github.com/expertiza/expertiza/pull/1826 Github Repository] 
[https://github.com/expertiza/expertiza/pull/1826 Pull Request] 
[https://youtu.be/RQJinX6gcrA mentor assignment video] 
[https://youtu.be/nAS0WxzFAsA team creation without mentor participants video] 
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

==Team==
Santiago Sepulveda 
Skieler Capezza 
Liam Donovan 
Javier Sanchez 
'''Mentor:''' Yulin Zhang

File:Assignment team mentor.png

2020-11-17T23:41:34Z

Srcapezz:

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-11-17T23:41:07Z

Srcapezz: /* Files Modified/Created */

==Project Overview==
=== Background ===
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. Keeping this in mind our code is set to work under the following conditions:

*'''Assignment teams created for an assignment without topics'''
*'''Mentors (''Instructors and TAs'') are only assigned to assignment teams if they have been added to an assignment as participants'''

We've created the following [https://youtu.be/RQJinX6gcrA video] to demonstrate the added functionality. As well as the following [https://youtu.be/nAS0WxzFAsA video] which demonstrates what happens when teams are created when no mentors have been added as participants to an assignment.

=== Objectives ===
1. Assign a TA or instructor as a mentor for a team created for an assignment without topics 
2. Notify mentor and individuals of a team via Email when a mentor has been assigned 

=== Previous Work ===
We learned from previous implementations and looked to avoid the following pitfalls when implementing our solution:

*Code was merged from the previous team, but not refactored, so a lot of unused code remained.
*Should have followed a better naming convention for methods
*Some redundant codes in the views could be DRYed out.
*Commented code should be removed.
*Some complex logic is added but not explained in the comments.
*Code should be placed in most relevant classes. (E.g. Do not put email code in the Team class).
*Documentation doesn't accurately represent implementation.
*Lacked sufficient detail for Test section.

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

=== Program Design ===
Our implementation begins when an assignment team is created. If the assignment is associated with a topic, the created team will not be assigned a mentor. If the assignment does not have a topic, a hash of potential mentors is retrieved. This hash is created from the TAs and instructors added to the assignment as participants. The keys of the hash correspond to the mentor's participant id while their values are the number of times the mentor has been assigned to mentor teams. The mentor with the lowest number of assigned teams will be the next mentor assigned to a newly created team. Once the team is assigned a mentor, an email is sent out to the mentor and students in the team to notify them of their mentor assignment.
 
[[File:Program_Design.png]]
 

We created the following assignment_teams_mentors table with the following connections to existing tables. The new table created is responsible for storing all the mentors assigned to the various teams created. In order to do so, the assignment_team_mentors table will reference the participants and teams tables.
 
[[File:Schema_Modifications_UML_2.png|500px]]

We will also modify the participants table to add an additional Boolean column, '''can_mentor'''. This column will help determine what TAs and instructors can mentor for a specified assignment.

 
Currently instructors see the corresponding view when looking at teams associated with an assignment:
 
[[File:Instructor_view_before.png|1000px]]

Our team is proposing to add an additional "Mentors" column in the instructor view:
 
[[File:Instructor_view_after.png|1000px]]

Currently students see the corresponding view when looking at their team for an assignment: 
[[File:Student_view_before.png|1000px]]

 
Our team is proposing to add an additional "Mentors" section in the student view:
 
[[File:Student_view_after.png|1000px]]

=== Files Modified/Created ===
These are the files we have modified/created throughout our project and a brief excerpt about what was done:

'''Database'''
*Schema.rb
**Created assignment_team_mentors table which references the participants table and teams tables thru foreign keys created with the assignment_team_mentors_id column and assignment_team_id column. The assignment_team_mentors table is responsible for storing all the mentors assigned to the various assignment teams created
**Created a can_mentor column for the participants table in order to be able to know who was a mentor and who was a student

'''Models'''
*assignment_team_mentor.rb
**responsible for ensuring mentor with the least number of teams mentored, gets assigned to the next team created.
**added mailer functionality for notifying the mentor
[[File:assignment_team_mentor.png]]

*assignment_team.rb
**established a has_one: active record relation with AssignmentTeamMentor model. This ensures a team only has one team mentor.
*participant.rb
**established a has_many: active record relation with AssignmentTeamMentor model. This provides the flexibility of a potential mentor added as a participant to an assignment, to mentor multiple teams created for an assignment.
**added a function to set the new can_mentor column for a participant
**added a function to get a list of all participants who can be mentors for a specified assignment based on the can_mentor column
[[File:participant_get_can_mentor.png]]
[[File:participant_get_mentors.png]]

'''Controllers'''
*teams_controller.rb
**Calls on AssignmentTeamMentor to assign mentor for instructor created teams.
**added functionality to send email to mentor when assigned to a team.
*student_teams_controllers.rb
**Calls on AssignmentTeamMentor to assign mentor for student created teams.
*teams_user_controller.rb
**added code to send the email when a user is added to a team to the mentor.
*participants_controller.rb
**updates the can_mentor column of a participant when they are added to an assignment

'''Views'''
*views/tree_display/_page_footer.html.erb
**displays mentor column header.
*views/tree_display/_row_header.html.erb
**displays either mentor assigned or "No mentor assigned" for team level. For team participant level, blank cell is displayed.

*views/student_teams/view.html.erb
**responsible for displaying to a student the mentor assigned to their team for an assignment.

*views/mailer/notify_member.html.erb
**responsible for managing the template of the mail sent to the mentor
'''Mailers'''
*app/mailers/mailer.rb
**responsible for managing the mailer functionally for notifying the member

'''RSPEC'''

=== Testing Plan ===

==== ''Edge Cases'' ====
The following are scenarios our team has thought about:

Edge Case 1: How will we handle the "Has topic?" check box being changed when editing the assignment in the instructor view. This button is how we decide if we need to assign mentors to a team.
Option A: Always run our algorithm for each assignment made and only show which mentors are assigned if the "Has topic?" is not checked
Option B: Add the functionality to add and remove mentors for all assignments, not just assignments without topics then add and remove mentors when an assignment is edited.
 
[[File:Instructor_hasTopics_checkbox.png|500px]]

 
Edge Case 2: No mentors exist
Option A: Don't assign mentors
Option B: Prevent creation of teams

==== ''RSpec Test'' ====
RSpec test to check:
* Validation of the models
* Functionality of controllers

==== ''UI Test'' ====
In the UI test we are going to verify that:
As an instructor should be able to see, the following: 
[[File:Instructor_view_after.png|1000px]]
 
A student should be able to see the following after viewing their team for an assignment: 
[[File:Student_view_after.png|1000px]]

This is what the mentor should see: 
[[File:Email to mentor.png]]

=== Potential Future Enhancements ===

1. Implementing manual mentor assignment capability for instructors assign mentors to a team.
2. Refactor email functionality code

==References==
[https://github.com/expertiza/expertiza/pull/1826 Github Repository] 
[https://github.com/expertiza/expertiza/pull/1826 Pull Request] 
[https://youtu.be/RQJinX6gcrA mentor assignment video] 
[https://youtu.be/nAS0WxzFAsA team creation without mentor participants video] 
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

==Team==
Santiago Sepulveda 
Skieler Capezza 
Liam Donovan 
Javier Sanchez 
'''Mentor:''' Yulin Zhang

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-11-17T23:39:06Z

Srcapezz: /* Files Modified/Created */

==Project Overview==
=== Background ===
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. Keeping this in mind our code is set to work under the following conditions:

*'''Assignment teams created for an assignment without topics'''
*'''Mentors (''Instructors and TAs'') are only assigned to assignment teams if they have been added to an assignment as participants'''

We've created the following [https://youtu.be/RQJinX6gcrA video] to demonstrate the added functionality. As well as the following [https://youtu.be/nAS0WxzFAsA video] which demonstrates what happens when teams are created when no mentors have been added as participants to an assignment.

=== Objectives ===
1. Assign a TA or instructor as a mentor for a team created for an assignment without topics 
2. Notify mentor and individuals of a team via Email when a mentor has been assigned 

=== Previous Work ===
We learned from previous implementations and looked to avoid the following pitfalls when implementing our solution:

*Code was merged from the previous team, but not refactored, so a lot of unused code remained.
*Should have followed a better naming convention for methods
*Some redundant codes in the views could be DRYed out.
*Commented code should be removed.
*Some complex logic is added but not explained in the comments.
*Code should be placed in most relevant classes. (E.g. Do not put email code in the Team class).
*Documentation doesn't accurately represent implementation.
*Lacked sufficient detail for Test section.

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

=== Program Design ===
Our implementation begins when an assignment team is created. If the assignment is associated with a topic, the created team will not be assigned a mentor. If the assignment does not have a topic, a hash of potential mentors is retrieved. This hash is created from the TAs and instructors added to the assignment as participants. The keys of the hash correspond to the mentor's participant id while their values are the number of times the mentor has been assigned to mentor teams. The mentor with the lowest number of assigned teams will be the next mentor assigned to a newly created team. Once the team is assigned a mentor, an email is sent out to the mentor and students in the team to notify them of their mentor assignment.
 
[[File:Program_Design.png]]
 

We created the following assignment_teams_mentors table with the following connections to existing tables. The new table created is responsible for storing all the mentors assigned to the various teams created. In order to do so, the assignment_team_mentors table will reference the participants and teams tables.
 
[[File:Schema_Modifications_UML_2.png|500px]]

We will also modify the participants table to add an additional Boolean column, '''can_mentor'''. This column will help determine what TAs and instructors can mentor for a specified assignment.

 
Currently instructors see the corresponding view when looking at teams associated with an assignment:
 
[[File:Instructor_view_before.png|1000px]]

Our team is proposing to add an additional "Mentors" column in the instructor view:
 
[[File:Instructor_view_after.png|1000px]]

Currently students see the corresponding view when looking at their team for an assignment: 
[[File:Student_view_before.png|1000px]]

 
Our team is proposing to add an additional "Mentors" section in the student view:
 
[[File:Student_view_after.png|1000px]]

=== Files Modified/Created ===
These are the files we have modified/created throughout our project and a brief excerpt about what was done:

'''Database'''
*Schema.rb
**Created assignment_team_mentors table which references the participants table and teams tables thru foreign keys created with the assignment_team_mentors_id column and assignment_team_id column. The assignment_team_mentors table is responsible for storing all the mentors assigned to the various assignment teams created
**Created a can_mentor column for the participants table in order to be able to know who was a mentor and who was a student

'''Models'''
*assignment_team_mentor.rb
**responsible for ensuring mentor with the least number of teams mentored, gets assigned to the next team created.
**added mailer functionality for notifying the mentor
*assignment_team.rb
**established a has_one: active record relation with AssignmentTeamMentor model. This ensures a team only has one team mentor.
*participant.rb
**established a has_many: active record relation with AssignmentTeamMentor model. This provides the flexibility of a potential mentor added as a participant to an assignment, to mentor multiple teams created for an assignment.
**added a function to set the new can_mentor column for a participant
**added a function to get a list of all participants who can be mentors for a specified assignment based on the can_mentor column
[[File:participant_get_can_mentor.png]]
[[File:participant_get_mentors.png]]

'''Controllers'''
*teams_controller.rb
**Calls on AssignmentTeamMentor to assign mentor for instructor created teams.
**added functionality to send email to mentor when assigned to a team.
*student_teams_controllers.rb
**Calls on AssignmentTeamMentor to assign mentor for student created teams.
*teams_user_controller.rb
**added code to send the email when a user is added to a team to the mentor.
*participants_controller.rb
**updates the can_mentor column of a participant when they are added to an assignment

'''Views'''
*views/tree_display/_page_footer.html.erb
**displays mentor column header.
*views/tree_display/_row_header.html.erb
**displays either mentor assigned or "No mentor assigned" for team level. For team participant level, blank cell is displayed.

*views/student_teams/view.html.erb
**responsible for displaying to a student the mentor assigned to their team for an assignment.

*views/mailer/notify_member.html.erb
**responsible for managing the template of the mail sent to the mentor
'''Mailers'''
*app/mailers/mailer.rb
**responsible for managing the mailer functionally for notifying the member

'''RSPEC'''

=== Testing Plan ===

==== ''Edge Cases'' ====
The following are scenarios our team has thought about:

Edge Case 1: How will we handle the "Has topic?" check box being changed when editing the assignment in the instructor view. This button is how we decide if we need to assign mentors to a team.
Option A: Always run our algorithm for each assignment made and only show which mentors are assigned if the "Has topic?" is not checked
Option B: Add the functionality to add and remove mentors for all assignments, not just assignments without topics then add and remove mentors when an assignment is edited.
 
[[File:Instructor_hasTopics_checkbox.png|500px]]

 
Edge Case 2: No mentors exist
Option A: Don't assign mentors
Option B: Prevent creation of teams

==== ''RSpec Test'' ====
RSpec test to check:
* Validation of the models
* Functionality of controllers

==== ''UI Test'' ====
In the UI test we are going to verify that:
As an instructor should be able to see, the following: 
[[File:Instructor_view_after.png|1000px]]
 
A student should be able to see the following after viewing their team for an assignment: 
[[File:Student_view_after.png|1000px]]

This is what the mentor should see: 
[[File:Email to mentor.png]]

=== Potential Future Enhancements ===

1. Implementing manual mentor assignment capability for instructors assign mentors to a team.
2. Refactor email functionality code

==References==
[https://github.com/expertiza/expertiza/pull/1826 Github Repository] 
[https://github.com/expertiza/expertiza/pull/1826 Pull Request] 
[https://youtu.be/RQJinX6gcrA mentor assignment video] 
[https://youtu.be/nAS0WxzFAsA team creation without mentor participants video] 
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

==Team==
Santiago Sepulveda 
Skieler Capezza 
Liam Donovan 
Javier Sanchez 
'''Mentor:''' Yulin Zhang

File:Participant get mentors.png

2020-11-17T23:38:40Z

Srcapezz:

File:Participant get can mentor.png

2020-11-17T23:38:22Z

Srcapezz:

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-11-17T23:37:58Z

Srcapezz: /* Files Modified/Created */

==Project Overview==
=== Background ===
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. Keeping this in mind our code is set to work under the following conditions:

*'''Assignment teams created for an assignment without topics'''
*'''Mentors (''Instructors and TAs'') are only assigned to assignment teams if they have been added to an assignment as participants'''

We've created the following [https://youtu.be/RQJinX6gcrA video] to demonstrate the added functionality. As well as the following [https://youtu.be/nAS0WxzFAsA video] which demonstrates what happens when teams are created when no mentors have been added as participants to an assignment.

=== Objectives ===
1. Assign a TA or instructor as a mentor for a team created for an assignment without topics 
2. Notify mentor and individuals of a team via Email when a mentor has been assigned 

=== Previous Work ===
We learned from previous implementations and looked to avoid the following pitfalls when implementing our solution:

*Code was merged from the previous team, but not refactored, so a lot of unused code remained.
*Should have followed a better naming convention for methods
*Some redundant codes in the views could be DRYed out.
*Commented code should be removed.
*Some complex logic is added but not explained in the comments.
*Code should be placed in most relevant classes. (E.g. Do not put email code in the Team class).
*Documentation doesn't accurately represent implementation.
*Lacked sufficient detail for Test section.

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

=== Program Design ===
Our implementation begins when an assignment team is created. If the assignment is associated with a topic, the created team will not be assigned a mentor. If the assignment does not have a topic, a hash of potential mentors is retrieved. This hash is created from the TAs and instructors added to the assignment as participants. The keys of the hash correspond to the mentor's participant id while their values are the number of times the mentor has been assigned to mentor teams. The mentor with the lowest number of assigned teams will be the next mentor assigned to a newly created team. Once the team is assigned a mentor, an email is sent out to the mentor and students in the team to notify them of their mentor assignment.
 
[[File:Program_Design.png]]
 

We created the following assignment_teams_mentors table with the following connections to existing tables. The new table created is responsible for storing all the mentors assigned to the various teams created. In order to do so, the assignment_team_mentors table will reference the participants and teams tables.
 
[[File:Schema_Modifications_UML_2.png|500px]]

We will also modify the participants table to add an additional Boolean column, '''can_mentor'''. This column will help determine what TAs and instructors can mentor for a specified assignment.

 
Currently instructors see the corresponding view when looking at teams associated with an assignment:
 
[[File:Instructor_view_before.png|1000px]]

Our team is proposing to add an additional "Mentors" column in the instructor view:
 
[[File:Instructor_view_after.png|1000px]]

Currently students see the corresponding view when looking at their team for an assignment: 
[[File:Student_view_before.png|1000px]]

 
Our team is proposing to add an additional "Mentors" section in the student view:
 
[[File:Student_view_after.png|1000px]]

=== Files Modified/Created ===
These are the files we have modified/created throughout our project and a brief excerpt about what was done:

'''Database'''
*Schema.rb
**Created assignment_team_mentors table which references the participants table and teams tables thru foreign keys created with the assignment_team_mentors_id column and assignment_team_id column. The assignment_team_mentors table is responsible for storing all the mentors assigned to the various assignment teams created
**Created a can_mentor column for the participants table in order to be able to know who was a mentor and who was a student

'''Models'''
*assignment_team_mentor.rb
**responsible for ensuring mentor with the least number of teams mentored, gets assigned to the next team created.
**added mailer functionality for notifying the mentor
*assignment_team.rb
**established a has_one: active record relation with AssignmentTeamMentor model. This ensures a team only has one team mentor.
*participant.rb
**established a has_many: active record relation with AssignmentTeamMentor model. This provides the flexibility of a potential mentor added as a participant to an assignment, to mentor multiple teams created for an assignment.
**added a function to set the new can_mentor column for a participant
**added a function to get a list of all participants who can be mentors for a specified assignment based on the can_mentor column
[[File:participant_get_can_mentor.png|1000px]]
[[File:participant_get_mentors.png|1000px]]

'''Controllers'''
*teams_controller.rb
**Calls on AssignmentTeamMentor to assign mentor for instructor created teams.
**added functionality to send email to mentor when assigned to a team.
*student_teams_controllers.rb
**Calls on AssignmentTeamMentor to assign mentor for student created teams.
*teams_user_controller.rb
**added code to send the email when a user is added to a team to the mentor.
*participants_controller.rb
**updates the can_mentor column of a participant when they are added to an assignment

'''Views'''
*views/tree_display/_page_footer.html.erb
**displays mentor column header.
*views/tree_display/_row_header.html.erb
**displays either mentor assigned or "No mentor assigned" for team level. For team participant level, blank cell is displayed.

*views/student_teams/view.html.erb
**responsible for displaying to a student the mentor assigned to their team for an assignment.

*views/mailer/notify_member.html.erb
**responsible for managing the template of the mail sent to the mentor
'''Mailers'''
*app/mailers/mailer.rb
**responsible for managing the mailer functionally for notifying the member

'''RSPEC'''

=== Testing Plan ===

==== ''Edge Cases'' ====
The following are scenarios our team has thought about:

Edge Case 1: How will we handle the "Has topic?" check box being changed when editing the assignment in the instructor view. This button is how we decide if we need to assign mentors to a team.
Option A: Always run our algorithm for each assignment made and only show which mentors are assigned if the "Has topic?" is not checked
Option B: Add the functionality to add and remove mentors for all assignments, not just assignments without topics then add and remove mentors when an assignment is edited.
 
[[File:Instructor_hasTopics_checkbox.png|500px]]

 
Edge Case 2: No mentors exist
Option A: Don't assign mentors
Option B: Prevent creation of teams

==== ''RSpec Test'' ====
RSpec test to check:
* Validation of the models
* Functionality of controllers

==== ''UI Test'' ====
In the UI test we are going to verify that:
As an instructor should be able to see, the following: 
[[File:Instructor_view_after.png|1000px]]
 
A student should be able to see the following after viewing their team for an assignment: 
[[File:Student_view_after.png|1000px]]

This is what the mentor should see: 
[[File:Email to mentor.png]]

=== Potential Future Enhancements ===

1. Implementing manual mentor assignment capability for instructors assign mentors to a team.
2. Refactor email functionality code

==References==
[https://github.com/expertiza/expertiza/pull/1826 Github Repository] 
[https://github.com/expertiza/expertiza/pull/1826 Pull Request] 
[https://youtu.be/RQJinX6gcrA mentor assignment video] 
[https://youtu.be/nAS0WxzFAsA team creation without mentor participants video] 
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

==Team==
Santiago Sepulveda 
Skieler Capezza 
Liam Donovan 
Javier Sanchez 
'''Mentor:''' Yulin Zhang

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-11-17T23:35:08Z

Srcapezz: /* Files Modified/Created */

==Project Overview==
=== Background ===
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. Keeping this in mind our code is set to work under the following conditions:

*'''Assignment teams created for an assignment without topics'''
*'''Mentors (''Instructors and TAs'') are only assigned to assignment teams if they have been added to an assignment as participants'''

We've created the following [https://youtu.be/RQJinX6gcrA video] to demonstrate the added functionality. As well as the following [https://youtu.be/nAS0WxzFAsA video] which demonstrates what happens when teams are created when no mentors have been added as participants to an assignment.

=== Objectives ===
1. Assign a TA or instructor as a mentor for a team created for an assignment without topics 
2. Notify mentor and individuals of a team via Email when a mentor has been assigned 

=== Previous Work ===
We learned from previous implementations and looked to avoid the following pitfalls when implementing our solution:

*Code was merged from the previous team, but not refactored, so a lot of unused code remained.
*Should have followed a better naming convention for methods
*Some redundant codes in the views could be DRYed out.
*Commented code should be removed.
*Some complex logic is added but not explained in the comments.
*Code should be placed in most relevant classes. (E.g. Do not put email code in the Team class).
*Documentation doesn't accurately represent implementation.
*Lacked sufficient detail for Test section.

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

=== Program Design ===
Our implementation begins when an assignment team is created. If the assignment is associated with a topic, the created team will not be assigned a mentor. If the assignment does not have a topic, a hash of potential mentors is retrieved. This hash is created from the TAs and instructors added to the assignment as participants. The keys of the hash correspond to the mentor's participant id while their values are the number of times the mentor has been assigned to mentor teams. The mentor with the lowest number of assigned teams will be the next mentor assigned to a newly created team. Once the team is assigned a mentor, an email is sent out to the mentor and students in the team to notify them of their mentor assignment.
 
[[File:Program_Design.png]]
 

We created the following assignment_teams_mentors table with the following connections to existing tables. The new table created is responsible for storing all the mentors assigned to the various teams created. In order to do so, the assignment_team_mentors table will reference the participants and teams tables.
 
[[File:Schema_Modifications_UML_2.png|500px]]

We will also modify the participants table to add an additional Boolean column, '''can_mentor'''. This column will help determine what TAs and instructors can mentor for a specified assignment.

 
Currently instructors see the corresponding view when looking at teams associated with an assignment:
 
[[File:Instructor_view_before.png|1000px]]

Our team is proposing to add an additional "Mentors" column in the instructor view:
 
[[File:Instructor_view_after.png|1000px]]

Currently students see the corresponding view when looking at their team for an assignment: 
[[File:Student_view_before.png|1000px]]

 
Our team is proposing to add an additional "Mentors" section in the student view:
 
[[File:Student_view_after.png|1000px]]

=== Files Modified/Created ===
These are the files we have modified/created throughout our project and a brief excerpt about what was done:

'''Database'''
*Schema.rb
**Created assignment_team_mentors table which references the participants table and teams tables thru foreign keys created with the assignment_team_mentors_id column and assignment_team_id column. The assignment_team_mentors table is responsible for storing all the mentors assigned to the various assignment teams created
**Created a can_mentor column for the participants table in order to be able to know who was a mentor and who was a student

'''Models'''
*assignment_team_mentor.rb
**responsible for ensuring mentor with the least number of teams mentored, gets assigned to the next team created.
**added mailer functionality for notifying the mentor
*assignment_team.rb
**established a has_one: active record relation with AssignmentTeamMentor model. This ensures a team only has one team mentor.
*participant.rb
**established a has_many: active record relation with AssignmentTeamMentor model. This provides the flexibility of a potential mentor added as a participant to an assignment, to mentor multiple teams created for an assignment.
**added a function to set the new can_mentor column for a participant
[[File:participant_get_can_mentor.png|1000px]]
**added a function to get a list of all participants who can be mentors for a specified assignment based on the can_mentor column
[[File:participant_get_mentors.png|1000px]]

'''Controllers'''
*teams_controller.rb
**Calls on AssignmentTeamMentor to assign mentor for instructor created teams.
**added functionality to send email to mentor when assigned to a team.
*student_teams_controllers.rb
**Calls on AssignmentTeamMentor to assign mentor for student created teams.
*teams_user_controller.rb
**added code to send the email when a user is added to a team to the mentor.
*participants_controller.rb
**updates the can_mentor column of a participant when they are added to an assignment

'''Views'''
*views/tree_display/_page_footer.html.erb
**displays mentor column header.
*views/tree_display/_row_header.html.erb
**displays either mentor assigned or "No mentor assigned" for team level. For team participant level, blank cell is displayed.

*views/student_teams/view.html.erb
**responsible for displaying to a student the mentor assigned to their team for an assignment.

*views/mailer/notify_member.html.erb
**responsible for managing the template of the mail sent to the mentor
'''Mailers'''
*app/mailers/mailer.rb
**responsible for managing the mailer functionally for notifying the member

'''RSPEC'''

=== Testing Plan ===

==== ''Edge Cases'' ====
The following are scenarios our team has thought about:

Edge Case 1: How will we handle the "Has topic?" check box being changed when editing the assignment in the instructor view. This button is how we decide if we need to assign mentors to a team.
Option A: Always run our algorithm for each assignment made and only show which mentors are assigned if the "Has topic?" is not checked
Option B: Add the functionality to add and remove mentors for all assignments, not just assignments without topics then add and remove mentors when an assignment is edited.
 
[[File:Instructor_hasTopics_checkbox.png|500px]]

 
Edge Case 2: No mentors exist
Option A: Don't assign mentors
Option B: Prevent creation of teams

==== ''RSpec Test'' ====
RSpec test to check:
* Validation of the models
* Functionality of controllers

==== ''UI Test'' ====
In the UI test we are going to verify that:
As an instructor should be able to see, the following: 
[[File:Instructor_view_after.png|1000px]]
 
A student should be able to see the following after viewing their team for an assignment: 
[[File:Student_view_after.png|1000px]]

This is what the mentor should see: 
[[File:Email to mentor.png]]

=== Potential Future Enhancements ===

1. Implementing manual mentor assignment capability for instructors assign mentors to a team.
2. Refactor email functionality code

==References==
[https://github.com/expertiza/expertiza/pull/1826 Github Repository] 
[https://github.com/expertiza/expertiza/pull/1826 Pull Request] 
[https://youtu.be/RQJinX6gcrA mentor assignment video] 
[https://youtu.be/nAS0WxzFAsA team creation without mentor participants video] 
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

==Team==
Santiago Sepulveda 
Skieler Capezza 
Liam Donovan 
Javier Sanchez 
'''Mentor:''' Yulin Zhang

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-11-17T22:42:33Z

Srcapezz: /* Files Modified/Created */

==Project Overview==
=== Background ===
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. Keeping this in mind our code is set to work under the following conditions:

*'''Assignment teams created for an assignment without topics'''
*'''Mentors (''Instructors and TAs'') are only assigned to assignment teams if they have been added to an assignment as participants'''

We've created the following [https://youtu.be/RQJinX6gcrA video] to demonstrate the added functionality. As well as the following [https://youtu.be/nAS0WxzFAsA video] which demonstrates what happens when teams are created when no mentors have been added as participants to an assignment.

=== Objectives ===
1. Assign a TA or instructor as a mentor for a team created for an assignment without topics 
2. Notify mentor and individuals of a team via Email when a mentor has been assigned 

=== Previous Work ===
We learned from previous implementations and looked to avoid the following pitfalls when implementing our solution:

*Code was merged from the previous team, but not refactored, so a lot of unused code remained.
*Should have followed a better naming convention for methods
*Some redundant codes in the views could be DRYed out.
*Commented code should be removed.
*Some complex logic is added but not explained in the comments.
*Code should be placed in most relevant classes. (E.g. Do not put email code in the Team class).
*Documentation doesn't accurately represent implementation.
*Lacked sufficient detail for Test section.

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

=== Program Design ===
Our implementation begins when an assignment team is created. If the assignment is associated with a topic, the created team will not be assigned a mentor. If the assignment does not have a topic, a hash of potential mentors is retrieved. This hash is created from the TAs and instructors added to the assignment as participants. The keys of the hash correspond to the mentor's participant id while their values are the number of times the mentor has been assigned to mentor teams. The mentor with the lowest number of assigned teams will be the next mentor assigned to a newly created team. Once the team is assigned a mentor, an email is sent out to the mentor and students in the team to notify them of their mentor assignment.
 
[[File:Program_Design.png]]
 

We created the following assignment_teams_mentors table with the following connections to existing tables. The new table created is responsible for storing all the mentors assigned to the various teams created. In order to do so, the assignment_team_mentors table will reference the participants and teams tables.
 
[[File:Schema_Modifications_UML_2.png|500px]]

We will also modify the participants table to add an additional Boolean column, '''can_mentor'''. This column will help determine what TAs and instructors can mentor for a specified assignment.

 
Currently instructors see the corresponding view when looking at teams associated with an assignment:
 
[[File:Instructor_view_before.png|1000px]]

Our team is proposing to add an additional "Mentors" column in the instructor view:
 
[[File:Instructor_view_after.png|1000px]]

Currently students see the corresponding view when looking at their team for an assignment: 
[[File:Student_view_before.png|1000px]]

 
Our team is proposing to add an additional "Mentors" section in the student view:
 
[[File:Student_view_after.png|1000px]]

=== Files Modified/Created ===
These are the files we have modified/created throughout our project and a brief excerpt about what was done:

'''Database'''
*Schema.rb
**Created assignment_team_mentors table which references the participants table and teams tables thru foreign keys created with the assignment_team_mentors_id column and assignment_team_id column. The assignment_team_mentors table is responsible for storing all the mentors assigned to the various assignment teams created
**Created a can_mentor column for the participants table in order to be able to know who was a mentor and who was a student

'''Models'''
*assignment_team_mentor.rb
**responsible for ensuring mentor with the least number of teams mentored, gets assigned to the next team created.
**added mailer functionality for notifying the mentor
*assignment_team.rb
**established a has_one: active record relation with AssignmentTeamMentor model. This ensures a team only has one team mentor.
*participant.rb
**established a has_many: active record relation with AssignmentTeamMentor model. This provides the flexibility of a potential mentor added as a participant to an assignment, to mentor multiple teams created for an assignment.
*participant.rb
**added a function to set the new can_mentor column for a participant
**added a function to get a list of all participants who can be mentors for a specified assignment based on the can_mentor column

'''Controllers'''
*teams_controller.rb
**Calls on AssignmentTeamMentor to assign mentor for instructor created teams.
**added functionality to send email to mentor when assigned to a team.
*student_teams_controllers.rb
**Calls on AssignmentTeamMentor to assign mentor for student created teams.
*teams_user_controller.rb
**added code to send the email when a user is added to a team to the mentor.
*participants_controller.rb
**updates the can_mentor column of a participant when they are added to an assignment

'''Views'''
*views/tree_display/_page_footer.html.erb
**displays mentor column header.
*views/tree_display/_row_header.html.erb
**displays either mentor assigned or "No mentor assigned" for team level. For team participant level, blank cell is displayed.

*views/student_teams/view.html.erb
**responsible for displaying to a student the mentor assigned to their team for an assignment.

*views/mailer/notify_member.html.erb
**responsible for managing the template of the mail sent to the mentor
'''Mailers'''
*app/mailers/mailer.rb
**responsible for managing the mailer functionally for notifying the member

'''RSPEC'''

=== Testing Plan ===

==== ''Edge Cases'' ====
The following are scenarios our team has thought about:

Edge Case 1: How will we handle the "Has topic?" check box being changed when editing the assignment in the instructor view. This button is how we decide if we need to assign mentors to a team.
Option A: Always run our algorithm for each assignment made and only show which mentors are assigned if the "Has topic?" is not checked
Option B: Add the functionality to add and remove mentors for all assignments, not just assignments without topics then add and remove mentors when an assignment is edited.
 
[[File:Instructor_hasTopics_checkbox.png|500px]]

 
Edge Case 2: No mentors exist
Option A: Don't assign mentors
Option B: Prevent creation of teams

==== ''RSpec Test'' ====
RSpec test to check:
* Validation of the models
* Functionality of controllers

==== ''UI Test'' ====
In the UI test we are going to verify that:
As an instructor should be able to see, the following: 
[[File:Instructor_view_after.png|1000px]]
 
A student should be able to see the following after viewing their team for an assignment: 
[[File:Student_view_after.png|1000px]]

This is what the mentor should see: 
[[File:Email to mentor.png]]

=== Potential Future Enhancements ===

1. Implementing manual mentor assignment capability for instructors assign mentors to a team.
2. Refactor email functionality code

==References==
[https://github.com/expertiza/expertiza/pull/1826 Github Repository] 
[https://github.com/expertiza/expertiza/pull/1826 Pull Request] 
[https://youtu.be/RQJinX6gcrA mentor assignment video] 
[https://youtu.be/nAS0WxzFAsA team creation without mentor participants video] 
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

==Team==
Santiago Sepulveda 
Skieler Capezza 
Liam Donovan 
Javier Sanchez 
'''Mentor:''' Yulin Zhang

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-10-29T01:55:42Z

Srcapezz: /* UI Test */

==Project Overview==
=== ''Background'' ===
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.

=== ''Objectives'' ===
1. Assign a TA or instructor as a mentor for a team created for an assignment without topics 
2. Notify mentor and individuals of a team via Email when a mentor has been assigned 

=== ''Previous Work'' ===
We learned from previous implementations and looked to avoid the following pitfalls when implementing our solution:

*Code was merged from the previous team, but not refactored, so a lot of unused code remained.
*Should have followed a better naming convention for methods
*Some redundant codes in the views could be DRYed out.
*Commented code should be removed.
*Some complex logic is added but not explained in the comments.
*Code should be placed in most relevant classes. (E.g. Do not put email code in the Team class).
*Documentation doesn't accurately represent implementation.
*Lacked sufficient detail for Test section.

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

=== ''Program Design'' ===
We are proposing the following design with our implementation.
 
[[File:Program_Design.png]]

 
Our implementation begins when the team is created. Once a team is created, it prompts a question asking if the assignment that the team is being created before has a topic. If the assignment is associated with a topic, teams are not given a mentor. If the assignment does not have a topic, a list of mentors is queried. The list contains mentors and details the amount of teams each of the mentors is assigned to. A mentor is then selected for the least amount of teams assigned. Once the team is assigned a mentor, an email is sent out to the mentor and students in the team to notify them of their mentor assignment
 

We plan to create the following teams_mentors table with the following connections to existing tables:
 
[[File:Schema_Modifications.png|500px]]
The new table created will be responsible for storing all the mentors assigned to the various teams created. In order to do so, the teams_mentors table will reference the users, assignments, and teams tables.

 
Currently instructors see the corresponding view when looking at teams associated with an assignment:
 
[[File:Instructor_view_before.png|1000px]]

Our team is proposing to add an additional "Mentors" column in the instructor view:
 
[[File:Instructor_view_after.png|1000px]]

Currently students see the corresponding view when looking at their team for an assignment: 
[[File:Student_view_before.png|1000px]]

 
Our team is proposing to add an additional "Mentors" section in the student view:
 
[[File:Student_view_after.png|1000px]]

=== ''Files Modified/Created'' ===
These are the files we plan to modify/create throughout our project. More to come to this section as we continue with development...

'''Database'''
*Schema.rb
**create teams_mentors table and have references to users, assignments, and teams tables.
**Keeps track of all mentors assigned to all teams.

'''Models'''
*team_mentor.rb
**responsible for ensuring mentor with the least number of teams mentored, gets assigned to the next team created.

'''Controllers'''
*teams_controller.rb
**responsible for interacting with team_mentor.rb model and ensuring the correct data is fed to model as a new team is created.

'''Views'''
*views/teams
**responsible for displaying mentors assigned to teams for an instructor creating teams.
*views/student_teams/view.html.erb
**responsible for displaying to a student the mentor assigned to their team for an assignment.

'''Mailers'''
*app/mailers/mailer.rb

=== ''Testing Plan'' ===

==== ''Edge Cases'' ====
The following are scenarios our team has thought about:

Edge Case 1: How will we handle the "Has topic?" check box being changed when editing the assignment in the instructor view. This button is how we decide if we need to assign mentors to a team.
Option A: Always run our algorithm for each assignment made and only show which mentors are assigned if the "Has topic?" is not checked
Option B: Add the functionality to add and remove mentors for all assignments, not just assignments without topics then add and remove mentors when an assignment is edited.
 
[[File:Instructor_hasTopics_checkbox.png|500px]]

 
Edge Case 2: No mentors exist
Option A: Don't assign mentors
Option B: Prevent creation of teams

==== ''RSpec Test'' ====
RSpec test to check:
* Validation of the models
* Functionality of controllers

==== ''UI Test'' ====
In the UI test we are going to verify that:
As an instructor should be able to see, the following: 
[[File:Instructor_view_after.png|1000px]]
 
A student should be able to see the following after viewing their team for an assignment: 
[[File:Student_view_after.png|1000px]]

This is what the mentor should see: 
[[File:WImage103.jpg]]

=== Future Implementation ===

1. Implementing manual mentor assignment capability for instructors assign mentors to a team.

==References==
Github Repository: 
Pull Request: 
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

==Team==
Santiago Sepulveda 
Skieler Capezza 
Liam Donovan 
Javier Sanchez 
'''Mentor:''' Yulin Zhang

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-10-29T01:21:07Z

Srcapezz: /* Objectives */

==Project Overview==
=== ''Background'' ===
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.

=== ''Objectives'' ===
1. Assign a TA or instructor as a mentor for a team created for an assignment without topics 
2. Notify mentor and individuals of a team via Email when a mentor has been assigned 

=== ''Previous Work'' ===
We learned from previous implementations and looked to avoid the following pitfalls when implementing our solution:

*Code was merged from the previous team, but not refactored, so a lot of unused code remained.
*Should have followed a better naming convention for methods
*Some redundant codes in the views could be DRYed out.
*Commented code should be removed.
*Some complex logic is added but not explained in the comments.
*Code should be placed in most relevant classes. (E.g. Do not put email code in the Team class).
*Documentation doesn't accurately represent implementation.
*Lacked sufficient detail for Test section.

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

=== ''Program Design'' ===
We are proposing the following design with our implementation.
 
[[File:Program_Design.png]]

 
Our implementation begins when the team is created. Once a team is created, it prompts a question asking if the assignment that the team is being created before has a topic. If the assignment is associated with a topic, teams are not given a mentor. If the assignment does not have a topic, a list of mentors is queried. The list contains mentors and details the amount of teams each of the mentors is assigned to. A mentor is then selected for the least amount of teams assigned. Once the team is assigned a mentor, an email is sent out to the mentor and students in the team to notify them of their mentor assignment
 

 
Currently instructors see the corresponding view when looking at teams associated with an assignment:
 
[[File:Instructor_view_before.png|1000px]]

Our team is proposing to add an additional "Mentors" column in the instructor view:
 
[[File:Instructor_view_after.png|1000px]]

Currently students see the corresponding view when looking at their team for an assignment: 
[[File:Student_view_before.png|1000px]]

 
Our team is proposing to add an additional "Mentors" section in the student view:
 
[[File:Student_view_after.png|1000px]]

=== ''Files Modified/Created'' ===
These are the files we plan to modify/create throughout our project. More to come to this section as we continue with development...

'''Database'''
*Schema.rb
**create teams_mentors table and have references to users, assignments, and teams tables.
**Keeps track of all mentors assigned to all teams.

'''Models'''
*team_mentor.rb
**responsible for ensuring mentor with the least number of teams mentored, gets assigned to the next team created.

'''Controllers'''
*teams_controller.rb
**responsible for interacting with team_mentor.rb model and ensuring the correct data is fed to model as a new team is created.

'''Views'''
*views/teams
**responsible for displaying mentors assigned to teams for an instructor creating teams.
*views/student_teams/view.html.erb
**responsible for displaying to a student the mentor assigned to their team for an assignment.

=== ''Testing Plan'' ===

==== ''Edge Cases'' ====
The following are scenarios our team has thought about:

Edge Case 1: How will we handle the "Has topic?" check box being changed when editing the assignment in the instructor view. This button is how we decide if we need to assign mentors to a team.
Option A: Always run our algorithm for each assignment made and only show which mentors are assigned if the "Has topic?" is not checked
Option B: Add the functionality to add and remove mentors for all assignments, not just assignments without topics then add and remove mentors when an assignment is edited.
 
[[File:Instructor_hasTopics_checkbox.png|500px]]

 
Edge Case 2: No mentors exist
Option A: Don't assign mentors
Option B: Prevent creation of teams

==== ''RSpec Test'' ====
RSpec test to check:
* Validation of the models
* Functionality of controllers

==== ''UI Test'' ====
In the UI test we are going to verify that:
As an instructor should be able to see, the following: 
[[File:Instructor_view_after.png|1000px]]
 
A student should be able to see the following after viewing their team for an assignment: 
[[File:Student_view_after.png|1000px]]

=== Future Implementation ===

1. Implementing manual mentor assignment capability for instructors assign mentors to a team.

==References==
Github Repository: 
Pull Request: 
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

==Team==
Santiago Sepulveda 
Skieler Capezza 
Liam Donovan 
Javier Sanchez 
'''Mentor:''' Yulin Zhang

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-10-29T01:20:46Z

Srcapezz: /* Objectives */

==Project Overview==
=== ''Background'' ===
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.

=== ''Objectives'' ===
1. Assign a TA or instructor as a mentor for a team created for an assignment without topics 
2. Notify mentor and individuals of a team when a mentor has been assigned 

=== ''Previous Work'' ===
We learned from previous implementations and looked to avoid the following pitfalls when implementing our solution:

*Code was merged from the previous team, but not refactored, so a lot of unused code remained.
*Should have followed a better naming convention for methods
*Some redundant codes in the views could be DRYed out.
*Commented code should be removed.
*Some complex logic is added but not explained in the comments.
*Code should be placed in most relevant classes. (E.g. Do not put email code in the Team class).
*Documentation doesn't accurately represent implementation.
*Lacked sufficient detail for Test section.

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

=== ''Program Design'' ===
We are proposing the following design with our implementation.
 
[[File:Program_Design.png]]

 
Our implementation begins when the team is created. Once a team is created, it prompts a question asking if the assignment that the team is being created before has a topic. If the assignment is associated with a topic, teams are not given a mentor. If the assignment does not have a topic, a list of mentors is queried. The list contains mentors and details the amount of teams each of the mentors is assigned to. A mentor is then selected for the least amount of teams assigned. Once the team is assigned a mentor, an email is sent out to the mentor and students in the team to notify them of their mentor assignment
 

 
Currently instructors see the corresponding view when looking at teams associated with an assignment:
 
[[File:Instructor_view_before.png|1000px]]

Our team is proposing to add an additional "Mentors" column in the instructor view:
 
[[File:Instructor_view_after.png|1000px]]

Currently students see the corresponding view when looking at their team for an assignment: 
[[File:Student_view_before.png|1000px]]

 
Our team is proposing to add an additional "Mentors" section in the student view:
 
[[File:Student_view_after.png|1000px]]

=== ''Files Modified/Created'' ===
These are the files we plan to modify/create throughout our project. More to come to this section as we continue with development...

'''Database'''
*Schema.rb
**create teams_mentors table and have references to users, assignments, and teams tables.
**Keeps track of all mentors assigned to all teams.

'''Models'''
*team_mentor.rb
**responsible for ensuring mentor with the least number of teams mentored, gets assigned to the next team created.

'''Controllers'''
*teams_controller.rb
**responsible for interacting with team_mentor.rb model and ensuring the correct data is fed to model as a new team is created.

'''Views'''
*views/teams
**responsible for displaying mentors assigned to teams for an instructor creating teams.
*views/student_teams/view.html.erb
**responsible for displaying to a student the mentor assigned to their team for an assignment.

=== ''Testing Plan'' ===

==== ''Edge Cases'' ====
The following are scenarios our team has thought about:

Edge Case 1: How will we handle the "Has topic?" check box being changed when editing the assignment in the instructor view. This button is how we decide if we need to assign mentors to a team.
Option A: Always run our algorithm for each assignment made and only show which mentors are assigned if the "Has topic?" is not checked
Option B: Add the functionality to add and remove mentors for all assignments, not just assignments without topics then add and remove mentors when an assignment is edited.
 
[[File:Instructor_hasTopics_checkbox.png|500px]]

 
Edge Case 2: No mentors exist
Option A: Don't assign mentors
Option B: Prevent creation of teams

==== ''RSpec Test'' ====
RSpec test to check:
* Validation of the models
* Functionality of controllers

==== ''UI Test'' ====
In the UI test we are going to verify that:
As an instructor should be able to see, the following: 
[[File:Instructor_view_after.png|1000px]]
 
A student should be able to see the following after viewing their team for an assignment: 
[[File:Student_view_after.png|1000px]]

=== Future Implementation ===

1. Implementing manual mentor assignment capability for instructors assign mentors to a team.

==References==
Github Repository: 
Pull Request: 
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

==Team==
Santiago Sepulveda 
Skieler Capezza 
Liam Donovan 
Javier Sanchez 
'''Mentor:''' Yulin Zhang

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-10-29T01:20:30Z

Srcapezz: /* Objectives */

==Project Overview==
=== ''Background'' ===
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.

=== ''Objectives'' ===
1. Assign a TA or instructor as a mentor for a team created for an assignment without topics
2. Notify mentor and individuals of a team when a mentor has been assigned

=== ''Previous Work'' ===
We learned from previous implementations and looked to avoid the following pitfalls when implementing our solution:

*Code was merged from the previous team, but not refactored, so a lot of unused code remained.
*Should have followed a better naming convention for methods
*Some redundant codes in the views could be DRYed out.
*Commented code should be removed.
*Some complex logic is added but not explained in the comments.
*Code should be placed in most relevant classes. (E.g. Do not put email code in the Team class).
*Documentation doesn't accurately represent implementation.
*Lacked sufficient detail for Test section.

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

=== ''Program Design'' ===
We are proposing the following design with our implementation.
 
[[File:Program_Design.png]]

 
Our implementation begins when the team is created. Once a team is created, it prompts a question asking if the assignment that the team is being created before has a topic. If the assignment is associated with a topic, teams are not given a mentor. If the assignment does not have a topic, a list of mentors is queried. The list contains mentors and details the amount of teams each of the mentors is assigned to. A mentor is then selected for the least amount of teams assigned. Once the team is assigned a mentor, an email is sent out to the mentor and students in the team to notify them of their mentor assignment
 

 
Currently instructors see the corresponding view when looking at teams associated with an assignment:
 
[[File:Instructor_view_before.png|1000px]]

Our team is proposing to add an additional "Mentors" column in the instructor view:
 
[[File:Instructor_view_after.png|1000px]]

Currently students see the corresponding view when looking at their team for an assignment: 
[[File:Student_view_before.png|1000px]]

 
Our team is proposing to add an additional "Mentors" section in the student view:
 
[[File:Student_view_after.png|1000px]]

=== ''Files Modified/Created'' ===
These are the files we plan to modify/create throughout our project. More to come to this section as we continue with development...

'''Database'''
*Schema.rb
**create teams_mentors table and have references to users, assignments, and teams tables.
**Keeps track of all mentors assigned to all teams.

'''Models'''
*team_mentor.rb
**responsible for ensuring mentor with the least number of teams mentored, gets assigned to the next team created.

'''Controllers'''
*teams_controller.rb
**responsible for interacting with team_mentor.rb model and ensuring the correct data is fed to model as a new team is created.

'''Views'''
*views/teams
**responsible for displaying mentors assigned to teams for an instructor creating teams.
*views/student_teams/view.html.erb
**responsible for displaying to a student the mentor assigned to their team for an assignment.

=== ''Testing Plan'' ===

==== ''Edge Cases'' ====
The following are scenarios our team has thought about:

Edge Case 1: How will we handle the "Has topic?" check box being changed when editing the assignment in the instructor view. This button is how we decide if we need to assign mentors to a team.
Option A: Always run our algorithm for each assignment made and only show which mentors are assigned if the "Has topic?" is not checked
Option B: Add the functionality to add and remove mentors for all assignments, not just assignments without topics then add and remove mentors when an assignment is edited.
 
[[File:Instructor_hasTopics_checkbox.png|500px]]

 
Edge Case 2: No mentors exist
Option A: Don't assign mentors
Option B: Prevent creation of teams

==== ''RSpec Test'' ====
RSpec test to check:
* Validation of the models
* Functionality of controllers

==== ''UI Test'' ====
In the UI test we are going to verify that:
As an instructor should be able to see, the following: 
[[File:Instructor_view_after.png|1000px]]
 
A student should be able to see the following after viewing their team for an assignment: 
[[File:Student_view_after.png|1000px]]

=== Future Implementation ===

1. Implementing manual mentor assignment capability for instructors assign mentors to a team.

==References==
Github Repository: 
Pull Request: 
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

==Team==
Santiago Sepulveda 
Skieler Capezza 
Liam Donovan 
Javier Sanchez 
'''Mentor:''' Yulin Zhang

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-10-29T00:14:41Z

Srcapezz: /* UI Test */

==Project Overview==
=== ''Background'' ===
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.

=== ''Objectives'' ===
Implement code that will allow a mentor to be directly associated with a team. Notify mentor when they have been assigned to a team via email.

=== ''Previous Work'' ===
We learned from previous implementations and looked to avoid the following pitfalls when implementing our solution:

*Code was merged from the previous team, but not refactored, so a lot of unused code remained.
*Should have followed a better naming convention for methods
*Some redundant codes in the views could be DRYed out.
*Commented code should be removed.
*Some complex logic is added but not explained in the comments.
*Code should be placed in most relevant classes. (E.g. Do not put email code in the Team class).
*Documentation doesn't accurately represent implementation.
*Lacked sufficient detail for Test section.

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

=== ''Program Design'' ===
We are proposing the following design with our implementation.
 
[[File:Program_Design.jpg]]

 
Our implementation begins when the team is created. Once a team is created, it prompts a question asking if the assignment that the team is being created before has a topic. If the assignment is associated with a topic, teams are not given a mentor. If the assignment does not have a topic, a list of mentors is queried. The list contains mentors and details the amount of teams each of the mentors is assigned to. A mentor is then selected for the least amount of teams assigned.
 

 
Currently instructors see the corresponding view when looking at teams associated with an assignment:
 
[[File:Instructor_view_before.png|1000px]]

Our team is proposing to add an additional "Mentors" column in the instructor view:
 
[[File:Instructor_view_after.png|1000px]]

Currently students see the corresponding view when looking at their team for an assignment: 
[[File:Student_view_before.png|1000px]]

 
Our team is proposing to add an additional "Mentors" section in the student view:
 
[[File:Student_view_after.png|1000px]]

=== ''Files Modified'' ===
List all the files we changed when implementing our project

'''Models'''
*assignment.rb
*assignment_team.rb
*assignment_form.rb
*User.rb

'''Controllers'''
*assignments_controller.rb
*teams_controller.rb

'''Views'''
TBD

=== ''Testing Plan'' ===

==== ''Edge Cases'' ====
The following are scenarios our team has thought about:

Edge Case 1: How will we handle the "Has topic?" check box being changed when editing the assignment in the instructor view. This button is how we decide if we need to assign mentors to a team.
Option A: Always run our algorithm for each assignment made and only show which mentors are assigned if the "Has topic?" is not checked
Option B: Add the functionality to add and remove mentors for all assignments, not just assignments without topics then add and remove mentors when an assignment is edited.
 
[[File:Instructor_hasTopics_checkbox.png|500px]]

 
Edge Case 2: No mentors exist
Option A: Don't assign mentors
Option B: Prevent creation of teams

==== ''RSpec Test'' ====
RSpec test to check:
* Validation of the models
* Functionality of controllers

==== ''UI Test'' ====
In the UI test we are going to verify that:
As an instructor should be able to see, the following: 
[[File:Instructor_view_after.png|1000px]]
 
A student should be able to see the following after viewing their team for an assignment: 
[[File:Student_view_after.png|1000px]]

=== Future Implementation ===

1. Implementing manual mentor assignment capability for instructors assign mentors to a team.

==References==
Github Repository: 
Pull Request: 
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

==Team==
Santiago Sepulveda 
Skieler Capezza 
Liam Donovan 
Javier Sanchez 
'''Mentor:''' Yulin Zhang

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-10-29T00:13:58Z

Srcapezz: /* UI Test */

==Project Overview==
=== ''Background'' ===
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.

=== ''Objectives'' ===
Implement code that will allow a mentor to be directly associated with a team. Notify mentor when they have been assigned to a team via email.

=== ''Previous Work'' ===
We learned from previous implementations and looked to avoid the following pitfalls when implementing our solution:

*Code was merged from the previous team, but not refactored, so a lot of unused code remained.
*Should have followed a better naming convention for methods
*Some redundant codes in the views could be DRYed out.
*Commented code should be removed.
*Some complex logic is added but not explained in the comments.
*Code should be placed in most relevant classes. (E.g. Do not put email code in the Team class).
*Documentation doesn't accurately represent implementation.
*Lacked sufficient detail for Test section.

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

=== ''Program Design'' ===
We are proposing the following design with our implementation.
 
[[File:Program_Design.jpg]]

 
Our implementation begins when the team is created. Once a team is created, it prompts a question asking if the assignment that the team is being created before has a topic. If the assignment is associated with a topic, teams are not given a mentor. If the assignment does not have a topic, a list of mentors is queried. The list contains mentors and details the amount of teams each of the mentors is assigned to. A mentor is then selected for the least amount of teams assigned.
 

 
Currently instructors see the corresponding view when looking at teams associated with an assignment:
 
[[File:Instructor_view_before.png|1000px]]

Our team is proposing to add an additional "Mentors" column in the instructor view:
 
[[File:Instructor_view_after.png|1000px]]

Currently students see the corresponding view when looking at their team for an assignment: 
[[File:Student_view_before.png|1000px]]

 
Our team is proposing to add an additional "Mentors" section in the student view:
 
[[File:Student_view_after.png|1000px]]

=== ''Files Modified'' ===
List all the files we changed when implementing our project

'''Models'''
*assignment.rb
*assignment_team.rb
*assignment_form.rb
*User.rb

'''Controllers'''
*assignments_controller.rb
*teams_controller.rb

'''Views'''
TBD

=== ''Testing Plan'' ===

==== ''Edge Cases'' ====
The following are scenarios our team has thought about:

Edge Case 1: How will we handle the "Has topic?" check box being changed when editing the assignment in the instructor view. This button is how we decide if we need to assign mentors to a team.
Option A: Always run our algorithm for each assignment made and only show which mentors are assigned if the "Has topic?" is not checked
Option B: Add the functionality to add and remove mentors for all assignments, not just assignments without topics then add and remove mentors when an assignment is edited.
 
[[File:Instructor_hasTopics_checkbox.png|500px]]

 
Edge Case 2: No mentors exist
Option A: Don't assign mentors
Option B: Prevent creation of teams

==== ''RSpec Test'' ====
RSpec test to check:
* Validation of the models
* Functionality of controllers

==== ''UI Test'' ====
In the UI test we are going to verify that:
As an instructor should be able to see, the following: 
[[File:Instructor_view_after.png|1000px]]
 
A student should be able to see: 
[[File:Student_view_after.png|1000px]]

=== Future Implementation ===

1. Implementing manual mentor assignment capability for instructors assign mentors to a team.

==References==
Github Repository: 
Pull Request: 
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

==Team==
Santiago Sepulveda 
Skieler Capezza 
Liam Donovan 
Javier Sanchez 
'''Mentor:''' Yulin Zhang

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-10-29T00:13:32Z

Srcapezz: /* Program Design */

==Project Overview==
=== ''Background'' ===
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.

=== ''Objectives'' ===
Implement code that will allow a mentor to be directly associated with a team. Notify mentor when they have been assigned to a team via email.

=== ''Previous Work'' ===
We learned from previous implementations and looked to avoid the following pitfalls when implementing our solution:

*Code was merged from the previous team, but not refactored, so a lot of unused code remained.
*Should have followed a better naming convention for methods
*Some redundant codes in the views could be DRYed out.
*Commented code should be removed.
*Some complex logic is added but not explained in the comments.
*Code should be placed in most relevant classes. (E.g. Do not put email code in the Team class).
*Documentation doesn't accurately represent implementation.
*Lacked sufficient detail for Test section.

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

=== ''Program Design'' ===
We are proposing the following design with our implementation.
 
[[File:Program_Design.jpg]]

 
Our implementation begins when the team is created. Once a team is created, it prompts a question asking if the assignment that the team is being created before has a topic. If the assignment is associated with a topic, teams are not given a mentor. If the assignment does not have a topic, a list of mentors is queried. The list contains mentors and details the amount of teams each of the mentors is assigned to. A mentor is then selected for the least amount of teams assigned.
 

 
Currently instructors see the corresponding view when looking at teams associated with an assignment:
 
[[File:Instructor_view_before.png|1000px]]

Our team is proposing to add an additional "Mentors" column in the instructor view:
 
[[File:Instructor_view_after.png|1000px]]

Currently students see the corresponding view when looking at their team for an assignment: 
[[File:Student_view_before.png|1000px]]

 
Our team is proposing to add an additional "Mentors" section in the student view:
 
[[File:Student_view_after.png|1000px]]

=== ''Files Modified'' ===
List all the files we changed when implementing our project

'''Models'''
*assignment.rb
*assignment_team.rb
*assignment_form.rb
*User.rb

'''Controllers'''
*assignments_controller.rb
*teams_controller.rb

'''Views'''
TBD

=== ''Testing Plan'' ===

==== ''Edge Cases'' ====
The following are scenarios our team has thought about:

Edge Case 1: How will we handle the "Has topic?" check box being changed when editing the assignment in the instructor view. This button is how we decide if we need to assign mentors to a team.
Option A: Always run our algorithm for each assignment made and only show which mentors are assigned if the "Has topic?" is not checked
Option B: Add the functionality to add and remove mentors for all assignments, not just assignments without topics then add and remove mentors when an assignment is edited.
 
[[File:Instructor_hasTopics_checkbox.png|500px]]

 
Edge Case 2: No mentors exist
Option A: Don't assign mentors
Option B: Prevent creation of teams

==== ''RSpec Test'' ====
RSpec test to check:
* Validation of the models
* Functionality of controllers

==== ''UI Test'' ====
In the UI test we are going to verify that:
As an instructor should be able to see, the following: 
[[File:Instructor_view_after.png|1000px]]
 
A student should be able to see: 
[[File:Student_view_before.png|1000px]]

=== Future Implementation ===

1. Implementing manual mentor assignment capability for instructors assign mentors to a team.

==References==
Github Repository: 
Pull Request: 
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

==Team==
Santiago Sepulveda 
Skieler Capezza 
Liam Donovan 
Javier Sanchez 
'''Mentor:''' Yulin Zhang

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-10-29T00:06:33Z

Srcapezz: /* Edge Cases */

==Project Overview==
=== ''Background'' ===
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.

=== ''Objectives'' ===
Implement code that will allow a mentor to be directly associated with a team. Notify mentor when they have been assigned to a team via email.

=== ''Previous Work'' ===
We learned from previous implementations and looked to avoid the following pitfalls when implementing our solution:

*Code was merged from the previous team, but not refactored, so a lot of unused code remained.
*Should have followed a better naming convention for methods
*Some redundant codes in the views could be DRYed out.
*Commented code should be removed.
*Some complex logic is added but not explained in the comments.
*Code should be placed in most relevant classes. (E.g. Do not put email code in the Team class).
*Documentation doesn't accurately represent implementation.
*Lacked sufficient detail for Test section.

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

=== ''Program Design'' ===
We are proposing the following design with our implementation.
 
[[File:Program_Design.jpg]]

 
Our implementation begins when the team is created. Once a team is created, it prompts a question asking if the assignment that the team is being created before has a topic. If the assignment is associated with a topic, teams are not given a mentor. If the assignment does not have a topic, a list of mentors is queried. The list contains mentors and details the amount of teams each of the mentors is assigned to. A mentor is then selected for the least amount of teams assigned.
 

 
Currently instructors would see the corresponding view when looking at teams associated with an assignment:
 
[[File:Instructor_view_before.png|1000px]]

Our team is proposing to add an additional "Mentors" column in the instructor view:
 
[[File:Instructor_view_after.png|1000px]]

 
Our team is proposing to add an additional "Mentors" section in the student view:
 
[[File:Student_view_after.png|1000px]]

=== ''Files Modified'' ===
List all the files we changed when implementing our project

'''Models'''
*assignment.rb
*assignment_team.rb
*assignment_form.rb
*User.rb

'''Controllers'''
*assignments_controller.rb
*teams_controller.rb

'''Views'''
TBD

=== ''Testing Plan'' ===

==== ''Edge Cases'' ====
The following are scenarios our team has thought about:

Edge Case 1: How will we handle the "Has topic?" check box being changed when editing the assignment in the instructor view. This button is how we decide if we need to assign mentors to a team.
Option A: Always run our algorithm for each assignment made and only show which mentors are assigned if the "Has topic?" is not checked
Option B: Add the functionality to add and remove mentors for all assignments, not just assignments without topics then add and remove mentors when an assignment is edited.
 
[[File:Instructor_hasTopics_checkbox.png|500px]]

 
Edge Case 2: No mentors exist
Option A: Don't assign mentors
Option B: Prevent creation of teams

==== ''RSpec Test'' ====
RSpec test to check:
* Validation of the models
* Functionality of controllers

==== ''UI Test'' ====
In the UI test we are going to verify that:

1. Instructor/Admin verifies the selection of has topics button 
2. Student create team and invite others 
3. Assign mentor and send emails, when the team is created 

=== Future Implementation ===

1. Implementing manual mentor assignment capability for instructors assign mentors to a team.

==References==
Github Repository: 
Pull Request: 
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

==Team==
Santiago Sepulveda 
Skieler Capezza 
Liam Donovan 
Javier Sanchez 
'''Mentor:''' Yulin Zhang

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-10-29T00:06:07Z

Srcapezz: /* Edge Cases */

==Project Overview==
=== ''Background'' ===
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.

=== ''Objectives'' ===
Implement code that will allow a mentor to be directly associated with a team. Notify mentor when they have been assigned to a team via email.

=== ''Previous Work'' ===
We learned from previous implementations and looked to avoid the following pitfalls when implementing our solution:

*Code was merged from the previous team, but not refactored, so a lot of unused code remained.
*Should have followed a better naming convention for methods
*Some redundant codes in the views could be DRYed out.
*Commented code should be removed.
*Some complex logic is added but not explained in the comments.
*Code should be placed in most relevant classes. (E.g. Do not put email code in the Team class).
*Documentation doesn't accurately represent implementation.
*Lacked sufficient detail for Test section.

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

=== ''Program Design'' ===
We are proposing the following design with our implementation.
 
[[File:Program_Design.jpg]]

 
Our implementation begins when the team is created. Once a team is created, it prompts a question asking if the assignment that the team is being created before has a topic. If the assignment is associated with a topic, teams are not given a mentor. If the assignment does not have a topic, a list of mentors is queried. The list contains mentors and details the amount of teams each of the mentors is assigned to. A mentor is then selected for the least amount of teams assigned.
 

 
Currently instructors would see the corresponding view when looking at teams associated with an assignment:
 
[[File:Instructor_view_before.png|1000px]]

Our team is proposing to add an additional "Mentors" column in the instructor view:
 
[[File:Instructor_view_after.png|1000px]]

 
Our team is proposing to add an additional "Mentors" section in the student view:
 
[[File:Student_view_after.png|1000px]]

=== ''Files Modified'' ===
List all the files we changed when implementing our project

'''Models'''
*assignment.rb
*assignment_team.rb
*assignment_form.rb
*User.rb

'''Controllers'''
*assignments_controller.rb
*teams_controller.rb

'''Views'''
TBD

=== ''Testing Plan'' ===

==== ''Edge Cases'' ====
The following are scenarios our team has thought about:

Edge Case 1: How will we handle the "Has topic?" check box being changed when editing the assignment in the instructor view. This button is how we decide if we need to assign mentors to a team.
Option A: Always run our algorithm for each assignment made and only show which mentors are assigned if the "Has topic?" is not checked
Option B: Add the functionality to add and remove mentors for all assignments, not just assignments without topics then add and remove mentors when an assignment is edited.

[[File:Instructor_hasTopics_checkbox.png|500px]]

Edge Case 2: No mentors exist
Option A: Don't assign mentors
Option B: Prevent creation of teams

==== ''RSpec Test'' ====
The Rspec test are to be added...

==== ''UI Test'' ====
In the UI test we are going to verify that:

1. Instructor/Admin verifies the selection of has topics button 
2. Student create team and invite others 
3. Assign mentor and send emails, when the team is created 

=== Future Implementation ===

1. Implementing manual mentor assignment capability for instructors assign mentors to a team.

==References==
Github Repository: 
Pull Request: 
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

==Team==
Santiago Sepulveda 
Skieler Capezza 
Liam Donovan 
Javier Sanchez 
'''Mentor:''' Yulin Zhang

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-10-29T00:05:39Z

Srcapezz: /* Edge Cases */

==Project Overview==
=== ''Background'' ===
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.

=== ''Objectives'' ===
Implement code that will allow a mentor to be directly associated with a team. Notify mentor when they have been assigned to a team via email.

=== ''Previous Work'' ===
We learned from previous implementations and looked to avoid the following pitfalls when implementing our solution:

*Code was merged from the previous team, but not refactored, so a lot of unused code remained.
*Should have followed a better naming convention for methods
*Some redundant codes in the views could be DRYed out.
*Commented code should be removed.
*Some complex logic is added but not explained in the comments.
*Code should be placed in most relevant classes. (E.g. Do not put email code in the Team class).
*Documentation doesn't accurately represent implementation.
*Lacked sufficient detail for Test section.

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

=== ''Program Design'' ===
We are proposing the following design with our implementation.
 
[[File:Program_Design.jpg]]

 
Our implementation begins when the team is created. Once a team is created, it prompts a question asking if the assignment that the team is being created before has a topic. If the assignment is associated with a topic, teams are not given a mentor. If the assignment does not have a topic, a list of mentors is queried. The list contains mentors and details the amount of teams each of the mentors is assigned to. A mentor is then selected for the least amount of teams assigned.
 

 
Currently instructors would see the corresponding view when looking at teams associated with an assignment:
 
[[File:Instructor_view_before.png|1000px]]

Our team is proposing to add an additional "Mentors" column in the instructor view:
 
[[File:Instructor_view_after.png|1000px]]

 
Our team is proposing to add an additional "Mentors" section in the student view:
 
[[File:Student_view_after.png|1000px]]

=== ''Files Modified'' ===
List all the files we changed when implementing our project

'''Models'''
*assignment.rb
*assignment_team.rb
*assignment_form.rb
*User.rb

'''Controllers'''
*assignments_controller.rb
*teams_controller.rb

'''Views'''
TBD

=== ''Testing Plan'' ===

==== ''Edge Cases'' ====
The following are scenarios our team has thought about:

1. How will we handle the "Has topic?" check box being changed when editing the assignment in the instructor view. This button is how we decide if we need to assign mentors to a team.
Option A: Always run our algorithm for each assignment made and only show which mentors are assigned if the "Has topic?" is not checked
Option B: Add the functionality to add and remove mentors for all assignments, not just assignments without topics then add and remove mentors when an assignment is edited.

[[File:Instructor_hasTopics_checkbox.png|500px]]

2. No mentors exist
Option A: Don't assign mentors
Option B: Prevent creation of teams

==== ''RSpec Test'' ====
The Rspec test are to be added...

==== ''UI Test'' ====
In the UI test we are going to verify that:

1. Instructor/Admin verifies the selection of has topics button 
2. Student create team and invite others 
3. Assign mentor and send emails, when the team is created 

=== Future Implementation ===

1. Implementing manual mentor assignment capability for instructors assign mentors to a team.

==References==
Github Repository: 
Pull Request: 
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

==Team==
Santiago Sepulveda 
Skieler Capezza 
Liam Donovan 
Javier Sanchez 
'''Mentor:''' Yulin Zhang

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-10-29T00:04:46Z

Srcapezz: /* Edge Cases */

==Project Overview==
=== ''Background'' ===
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.

=== ''Objectives'' ===
Implement code that will allow a mentor to be directly associated with a team. Notify mentor when they have been assigned to a team via email.

=== ''Previous Work'' ===
We learned from previous implementations and looked to avoid the following pitfalls when implementing our solution:

*Code was merged from the previous team, but not refactored, so a lot of unused code remained.
*Should have followed a better naming convention for methods
*Some redundant codes in the views could be DRYed out.
*Commented code should be removed.
*Some complex logic is added but not explained in the comments.
*Code should be placed in most relevant classes. (E.g. Do not put email code in the Team class).
*Documentation doesn't accurately represent implementation.
*Lacked sufficient detail for Test section.

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

=== ''Program Design'' ===
We are proposing the following design with our implementation.
 
[[File:Program_Design.jpg]]

 
Our implementation begins when the team is created. Once a team is created, it prompts a question asking if the assignment that the team is being created before has a topic. If the assignment is associated with a topic, teams are not given a mentor. If the assignment does not have a topic, a list of mentors is queried. The list contains mentors and details the amount of teams each of the mentors is assigned to. A mentor is then selected for the least amount of teams assigned.
 

 
Currently instructors would see the corresponding view when looking at teams associated with an assignment:
 
[[File:Instructor_view_before.png|1000px]]

Our team is proposing to add an additional "Mentors" column in the instructor view:
 
[[File:Instructor_view_after.png|1000px]]

 
Our team is proposing to add an additional "Mentors" section in the student view:
 
[[File:Student_view_after.png|1000px]]

=== ''Files Modified'' ===
List all the files we changed when implementing our project

'''Models'''
*assignment.rb
*assignment_team.rb
*assignment_form.rb
*User.rb

'''Controllers'''
*assignments_controller.rb
*teams_controller.rb

'''Views'''
TBD

=== ''Testing Plan'' ===

==== ''Edge Cases'' ====
The following are scenarios our team has thought about:

1. How will we handle the "Has topic?" check box being changed when editing the assignment in the instructor view. This button is how we decide to run our code to assign mentors.
Option A: Always run our algorithm for each assignment made and only show which mentors are assigned if the "Has topic?" is not checked
Option B: Add the functionality to add and remove mentors for all assignments, not just assignments without topics then add and remove mentors when an assignment is edited.

[[File:Instructor_hasTopics_checkbox.png|500px]]

2. No mentors exist
Option A: Don't assign mentors
Option B: Prevent creation of teams

==== ''RSpec Test'' ====
The Rspec test are to be added...

==== ''UI Test'' ====
In the UI test we are going to verify that:

1. Instructor/Admin verifies the selection of has topics button 
2. Student create team and invite others 
3. Assign mentor and send emails, when the team is created 

=== Future Implementation ===

1. Implementing manual mentor assignment capability for instructors assign mentors to a team.

==References==
Github Repository: 
Pull Request: 
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

==Team==
Santiago Sepulveda 
Skieler Capezza 
Liam Donovan 
Javier Sanchez 
'''Mentor:''' Yulin Zhang

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-10-29T00:01:58Z

Srcapezz: /* Program Design */

==Project Overview==
=== ''Background'' ===
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.

=== ''Objectives'' ===
Implement code that will allow a mentor to be directly associated with a team. Notify mentor when they have been assigned to a team via email.

=== ''Previous Work'' ===
We learned from previous implementations and looked to avoid the following pitfalls when implementing our solution:

*Code was merged from the previous team, but not refactored, so a lot of unused code remained.
*Should have followed a better naming convention for methods
*Some redundant codes in the views could be DRYed out.
*Commented code should be removed.
*Some complex logic is added but not explained in the comments.
*Code should be placed in most relevant classes. (E.g. Do not put email code in the Team class).
*Documentation doesn't accurately represent implementation.
*Lacked sufficient detail for Test section.

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

=== ''Program Design'' ===
We are proposing the following design with our implementation.
 
[[File:Program_Design.jpg]]

 
Our implementation begins when the team is created. Once a team is created, it prompts a question asking if the assignment that the team is being created before has a topic. If the assignment is associated with a topic, teams are not given a mentor. If the assignment does not have a topic, a list of mentors is queried. The list contains mentors and details the amount of teams each of the mentors is assigned to. A mentor is then selected for the least amount of teams assigned.
 

 
Currently instructors would see the corresponding view when looking at teams associated with an assignment:
 
[[File:Instructor_view_before.png|1000px]]

Our team is proposing to add an additional "Mentors" column in the instructor view:
 
[[File:Instructor_view_after.png|1000px]]

 
Our team is proposing to add an additional "Mentors" section in the student view:
 
[[File:Student_view_after.png|1000px]]

=== ''Files Modified'' ===
List all the files we changed when implementing our project

'''Models'''
*assignment.rb
*assignment_team.rb
*assignment_form.rb
*User.rb

'''Controllers'''
*assignments_controller.rb
*teams_controller.rb

'''Views'''
TBD

=== ''Testing Plan'' ===

==== ''Edge Cases'' ====
The following are scenarios our team has thought about:

1. When an assignment is created with Has topic? checked or unchecked, how will we deal with it being edited back?
Option A: Always run our algorithm for each assignment made and only show which mentors are assigned if the "Has topic?" is not checked
Option B: Add the functionality to add and remove mentors for all assignments, not just assignments without topics then add and remove mentors when an assignment is edited.

[[File:Instructor_hasTopics_checkbox.png|1000px]]

2. No mentors exist
Option A: Don't assign mentors
Option B: Prevent creation of teams

==== ''RSpec Test'' ====
The Rspec test are to be added...

==== ''UI Test'' ====
In the UI test we are going to verify that:

1. Instructor/Admin verifies the selection of has topics button 
2. Student create team and invite others 
3. Assign mentor and send emails, when the team is created 

=== Future Implementation ===

1. Implementing manual mentor assignment capability for instructors assign mentors to a team.

==References==
Github Repository: 
Pull Request: 
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_E2024_Mentor_management_for_assignments_without_topics Previous Implementation's Wiki]

==Team==
Santiago Sepulveda 
Skieler Capezza 
Liam Donovan 
Javier Sanchez 
'''Mentor:''' Yulin Zhang

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-10-29T00:01:09Z

Srcapezz: /* Edge Cases */

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-10-28T23:59:13Z

Srcapezz: /* Program Design */

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-10-28T23:58:09Z

Srcapezz: /* Edge Cases */

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-10-28T23:57:50Z

Srcapezz: /* Edge Cases */

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-10-28T23:50:14Z

Srcapezz: /* Edge Cases */

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-10-28T23:49:51Z

Srcapezz: /* Edge Cases */

CSC/ECE 517 Fall 2020 - E2077. Mentor management for assignments without topics E2024

2020-10-28T23:48:57Z

Srcapezz: /* Edge Cases */

CSC/ECE 517 Fall 2020 - E2064. Refactor reputation web service controller.rb

2020-10-20T03:31:35Z

Srcapezz:

=='''Introduction'''==
==='''Introduction to Expertiza'''===
[http://expertiza.ncsu.edu/ Expertiza] is a peer review based system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types for assignments, including the URLs and wiki pages.
==='''About Reputation Web Service Controller'''===
Expertiza allows student work to be peer-reviewed, since peers can provide more feedback than the instructor can. However, if we want to assure that all students receive competent feedback, or even use peer-assigned grades, we need a way to judge which peer reviewers are most credible. The solution is the reputation system. Reputation systems have been deployed as web services, peer-review researchers will be able to use them to calculate scores on assignments, both past and present (past data can be used to tune the algorithms).
For this project, our team's job is to refactor the file: reputation_web_service_controller.rb. This file is the controller to calculate the reputation scores. A “reputation” measures how close a reviewer’s scores are to other reviewers’ scores. This controller implements the calculation of reputation scores.
----

=='''Issues to be fixed'''==

reputation_web_service_controller.rb is a fairly complex file. It contains a lot of methods that are long and hard to understand (for e.g. send_post_request). These methods need to be broken down into simpler and more specific methods that are easier to read/understand. Also, the few instances of code duplication that exist should be removed.

# There is a lot of unused/commented code, which should be removed.
# Figure out what the code is doing and write appropriate comments for it.
# Rename bad method names such as (db_query, json_generator). Method names should be verbs, and should say what the method does. Method names should not be so general that they could apply to many different methods..
# In the case of db_query, the name should say what it queries for. Also, this method not only queries, but calculates sums. Since each method should do only one thing, the code for calculating sums should be in another method. And there should be comments in the code!
#json_generator should be generate_json. There needs to be a method comment saying what the parameters are.
# In send_post_request, there are references to specific assignments, such as 724, 735, and 756. They were put in to gather data for a paper published in 2015. They are no longer relevant and should be removed. send_post_request is 91 lines long, far too long.
#There is a password for a private key in the code (and the code is open-sourced!) It should be in the db instead.
#Fix spelling of “dimention”
#client is a bad method name; why is stuff being copied from class variables to instance variables?

----

=='''Steps taken to resolve the issues'''==

----

=== Refactor db_query===

Renaming of bad method names such as (<code>db_query</code>). Method names should be verbs, and should say what the method does.
Method names should not be so general that they could apply to many different methods.
The other problem with the method was that it did not follow the good practice of having each method perform only one task.
This method got the review responses with a db query.
Also, it iterated over the review responses to perform a calculation of peer review grades.

We have split the method into two to have the review responses do only the get responses part.

[[File:snip7.png]]

 

=== The code for calculating sums should be in another method. ===
The result of this method is stored and we have created a new method <code>calculate_peer_review_grades</code> and moved the calculation part to it. 
We also added a comment to indicate the calculate weighted sum part.

 
[[File:snip8.png]]

 
And then, we have changed the call to the <code> get review responses</code> and the new method calculate peer review grades accordingly
 
[[File:snip3.png]]
 

Similarly, we have changed <code>db_query_with_quiz_scores</code> to <code>calculate_quiz_scores</code>

 
[[File:snip5.png]]
 

===''' Change name of json_generator'''===

json_generator method should be <code>generate_json</code>
Also,there needs to be a method comment saying what the parameters are.
We have added the method comments with parameter information as seen below.

[[File:snip4.png]]

===''' Refactor send_post_request'''===

“In (<code>send_post_request</code>), there are references to specific assignments, such as 724, 735, and 756.
They were put in to gather data for a paper published in 2015. They are no longer relevant and should be removed.
send_post_request is 91 lines long, far too long”

We observed that encryption of request being sent to evaluate Algorithm and decryption of response is written in (<code>send_post_request</code>) only that is why send post is 91 lines long.
We have created two separate methods
(<code>encrypt_request</code>)
(<code>decrypt_response</code>)

In the image below we can see that we have separated Encryption functionality from (<code>send_post_request</code>) to (<code>encrypt_request</code>)

[[File:encryption-separated.jpg]]

On the similar lines we have separated Decryption functionality from (<code>send_post_request</code>) to (<code>decrypt_response</code>)

[[File:decryption-separated.jpg]]

(<code>encrypt_request</code>) has been refactored as follows

[[File:encrypt_request.png]]

(<code>decrypt_response</code>) has been refactored as follows

[[File:decrypt_request.png]]

===''' Fixed spelling of dimention'''===

[[File:capture2.png]]

==='''Updating client method'''===

We changed the class variables in the code to instance variables because we realized that the send_post_request method and client method were the only methods using the class variables.
A client.html.erb file was used to call our controller to fill out a form for send_post_request which set values of class variables then immediately redirected control to the client method which set the instance variables to those class variables. The instance variables were then used in the rest of the client.html.erb file.

The process of setting class variables to instance variables with a function was redundant, so we removed simply set the instance variables within the send_post_request method and took them out of the client method.
The client method did have a few actions that it completed besides setting class variables which we have left in the method until we can find a solution to replacing them.

[[File:old-client-method.png|frame|none|alt=Alt text|Old client method]]

[[File:new-client-method-and-helpers-new.png|frame|none|alt=Alt text|Newest client method]]

The reason why we kept the client method's name is because the routes.rb file specifies the client method in the code and we haven't fully tracked down the impact of that yet.

== Testing ==
=== Test Plan ===
There was no existing tests available for the Reputation web service controller.
Since we are refactoring it, Our testing plan is to have an automated testing to ensure that the refactoring such as splitting a method into separate methods does not affect the existing implementation.
We also added steps for the manual testing to make sure the page loads as expected after the refactoring.
 
For the automated testing, We are using Rspec tests.
 
===RSpec===
We have tested the two new methods created during refactoring and also a renamed method.
The test coverage has increased a bit by 0.6% to 44%.
 

The tests we created can also be manually run with command 
<code>rspec spec/controllers/reputation_web_controller_spec.rb. </code>
 

[[File:snip13.png]]

===Manual UI Testing===
 
The steps to test our branch are below, but they are failing right now due to errors that are in other files of the beta branch.

To test our program you must login to the site here: http://152.7.98.78:8080/

Username: instructor6
Password: password

Then the page "Manage content" doesn't show up, go to Manage... -> Assignments

[[File:snip14.png]]

Then on the CSC 517, Fall 2017 Row, click on "Add Participants" in the actions column. This is also indicated by a blue shirted person.

[[File:snip15.png]]

Once in there, copy on of the student names (such as student7487) and then go to Manage... -> Impersonate User and enter their name (student7487) into the text field.

[[File:snip16.png]]

After impersonating them, you should be able to see their assignments. Click on any of their assignments such as "Program 1", then click on "Alternate View" to the right of "Your Scores".

[[File:snip17.png]]

[[File:snip18.png]]

 
----

=='''Modified Files'''==
<code>reputation_web_service_controller.rb</code>

=='''New Files'''==
<code>reputation_web_service_controller_spec.rb</code>

==Team Information==
'''Project Mentor:''' 
Saurabh Shingte

'''Project Members:''' 
Abhishek Gupta 
Skieler Capezza 
Ummu Kolusum Yasmin Ahamed Adam

=='''References'''==

*[https://github.com/srcapezza/expertiza/tree/beta Project Repo] 
*[https://github.com/expertiza/expertiza/pull/1790 Github Pull Request]
*[https://github.com/expertiza/expertiza Expertiza on GitHub]
*[http://expertiza.ncsu.edu/ The live Expertiza website]
*[http://research.csc.ncsu.edu/efg/expertiza Expertiza project Details]
*[https://www.youtube.com/channel/UCdKXzox7hrWjfOMML6FzTWg Expertiza YouTube Channel]

File:Snip18.png

2020-10-20T03:30:52Z

Srcapezz:

CSC/ECE 517 Fall 2020 - E2064. Refactor reputation web service controller.rb

2020-10-20T03:30:42Z

Srcapezz:

File:Snip17.png

2020-10-20T03:28:40Z

Srcapezz:

File:Snip16.png

2020-10-20T03:28:28Z

Srcapezz:

File:Snip15.png

2020-10-20T03:28:14Z

Srcapezz:

File:Snip14.png

2020-10-20T03:26:25Z

Srcapezz: Srcapezz uploaded a new version of File:Snip14.png

File:Snip14.png

2020-10-20T03:25:55Z

Srcapezz:

CSC/ECE 517 Fall 2020 - E2064. Refactor reputation web service controller.rb

2020-10-20T03:24:34Z

Srcapezz:

=='''Introduction'''==
==='''Introduction to Expertiza'''===
[http://expertiza.ncsu.edu/ Expertiza] is a peer review based system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types for assignments, including the URLs and wiki pages.
==='''About Reputation Web Service Controller'''===
Expertiza allows student work to be peer-reviewed, since peers can provide more feedback than the instructor can. However, if we want to assure that all students receive competent feedback, or even use peer-assigned grades, we need a way to judge which peer reviewers are most credible. The solution is the reputation system. Reputation systems have been deployed as web services, peer-review researchers will be able to use them to calculate scores on assignments, both past and present (past data can be used to tune the algorithms).
For this project, our team's job is to refactor the file: reputation_web_service_controller.rb. This file is the controller to calculate the reputation scores. A “reputation” measures how close a reviewer’s scores are to other reviewers’ scores. This controller implements the calculation of reputation scores.
----

=='''Issues to be fixed'''==

reputation_web_service_controller.rb is a fairly complex file. It contains a lot of methods that are long and hard to understand (for e.g. send_post_request). These methods need to be broken down into simpler and more specific methods that are easier to read/understand. Also, the few instances of code duplication that exist should be removed.

# There is a lot of unused/commented code, which should be removed.
# Figure out what the code is doing and write appropriate comments for it.
# Rename bad method names such as (db_query, json_generator). Method names should be verbs, and should say what the method does. Method names should not be so general that they could apply to many different methods..
# In the case of db_query, the name should say what it queries for. Also, this method not only queries, but calculates sums. Since each method should do only one thing, the code for calculating sums should be in another method. And there should be comments in the code!
#json_generator should be generate_json. There needs to be a method comment saying what the parameters are.
# In send_post_request, there are references to specific assignments, such as 724, 735, and 756. They were put in to gather data for a paper published in 2015. They are no longer relevant and should be removed. send_post_request is 91 lines long, far too long.
#There is a password for a private key in the code (and the code is open-sourced!) It should be in the db instead.
#Fix spelling of “dimention”
#client is a bad method name; why is stuff being copied from class variables to instance variables?

----

=='''Steps taken to resolve the issues'''==

----

=== Refactor db_query===

Renaming of bad method names such as (<code>db_query</code>). Method names should be verbs, and should say what the method does.
Method names should not be so general that they could apply to many different methods.
The other problem with the method was that it did not follow the good practice of having each method perform only one task.
This method got the review responses with a db query.
Also, it iterated over the review responses to perform a calculation of peer review grades.

We have split the method into two to have the review responses do only the get responses part.

[[File:snip7.png]]

 

=== The code for calculating sums should be in another method. ===
The result of this method is stored and we have created a new method <code>calculate_peer_review_grades</code> and moved the calculation part to it. 
We also added a comment to indicate the calculate weighted sum part.

 
[[File:snip8.png]]

 
And then, we have changed the call to the <code> get review responses</code> and the new method calculate peer review grades accordingly
 
[[File:snip3.png]]
 

Similarly, we have changed <code>db_query_with_quiz_scores</code> to <code>calculate_quiz_scores</code>

 
[[File:snip5.png]]
 

===''' Change name of json_generator'''===

json_generator method should be <code>generate_json</code>
Also,there needs to be a method comment saying what the parameters are.
We have added the method comments with parameter information as seen below.

[[File:snip4.png]]

===''' Refactor send_post_request'''===

“In (<code>send_post_request</code>), there are references to specific assignments, such as 724, 735, and 756.
They were put in to gather data for a paper published in 2015. They are no longer relevant and should be removed.
send_post_request is 91 lines long, far too long”

We observed that encryption of request being sent to evaluate Algorithm and decryption of response is written in (<code>send_post_request</code>) only that is why send post is 91 lines long.
We have created two separate methods
(<code>encrypt_request</code>)
(<code>decrypt_response</code>)

In the image below we can see that we have separated Encryption functionality from (<code>send_post_request</code>) to (<code>encrypt_request</code>)

[[File:encryption-separated.jpg]]

On the similar lines we have separated Decryption functionality from (<code>send_post_request</code>) to (<code>decrypt_response</code>)

[[File:decryption-separated.jpg]]

(<code>encrypt_request</code>) has been refactored as follows

[[File:encrypt_request.png]]

(<code>decrypt_response</code>) has been refactored as follows

[[File:decrypt_request.png]]

===''' Fixed spelling of dimention'''===

[[File:capture2.png]]

==='''Updating client method'''===

We changed the class variables in the code to instance variables because we realized that the send_post_request method and client method were the only methods using the class variables.
A client.html.erb file was used to call our controller to fill out a form for send_post_request which set values of class variables then immediately redirected control to the client method which set the instance variables to those class variables. The instance variables were then used in the rest of the client.html.erb file.

The process of setting class variables to instance variables with a function was redundant, so we removed simply set the instance variables within the send_post_request method and took them out of the client method.
The client method did have a few actions that it completed besides setting class variables which we have left in the method until we can find a solution to replacing them.

[[File:old-client-method.png|frame|none|alt=Alt text|Old client method]]

[[File:new-client-method-and-helpers-new.png|frame|none|alt=Alt text|Newest client method]]

The reason why we kept the client method's name is because the routes.rb file specifies the client method in the code and we haven't fully tracked down the impact of that yet.

== Testing ==
=== Test Plan ===
There was no existing tests available for the Reputation web service controller.
Since we are refactoring it, Our testing plan is to have an automated testing to ensure that the refactoring such as splitting a method into separate methods does not affect the existing implementation.
We also added steps for the manual testing to make sure the page loads as expected after the refactoring.
 
For the automated testing, We are using Rspec tests.
 
===RSpec===
We have tested the two new methods created during refactoring and also a renamed method.
The test coverage has increased a bit by 0.6% to 44%.
 

The tests we created can also be manually run with command 
<code>rspec spec/controllers/reputation_web_controller_spec.rb. </code>
 

[[File:snip13.png]]

===Manual UI Testing===
 
The steps to test our branch are below, but they are failing right now due to errors that are in other files of the beta branch.

To test our program you must login to the site here: http://152.7.98.78:8080/

Username: instructor6
Password: password

Then the page "Manage content" doesn't show up, go to Manage... -> Assignments

[[File:snip14.png]]

Then on the CSC 517, Fall 2017 Row, click on "Add Participants" in the actions column. This is also indicated by a blue shirted person.

[[File:snip15.png]]

[[File:snip16.png]]

Once in there, copy on of the student names (such as student7487) and then go to Manage... -> Impersonate User and enter their name (student7487) into the text field.

[[File:snip17.png]]

After impersonating them, you should be able to see their assignments. Click on any of their assignments such as "Program 1", then click on "Alternate View" to the right of "Your Scores".

[[File:snip18.png]]

[[File:snip19.png]]

 
----

=='''Modified Files'''==
<code>reputation_web_service_controller.rb</code>

=='''New Files'''==
<code>reputation_web_service_controller_spec.rb</code>

==Team Information==
'''Project Mentor:''' 
Saurabh Shingte

'''Project Members:''' 
Abhishek Gupta 
Skieler Capezza 
Ummu Kolusum Yasmin Ahamed Adam

=='''References'''==

*[https://github.com/srcapezza/expertiza/tree/beta Project Repo] 
*[https://github.com/expertiza/expertiza/pull/1790 Github Pull Request]
*[https://github.com/expertiza/expertiza Expertiza on GitHub]
*[http://expertiza.ncsu.edu/ The live Expertiza website]
*[http://research.csc.ncsu.edu/efg/expertiza Expertiza project Details]
*[https://www.youtube.com/channel/UCdKXzox7hrWjfOMML6FzTWg Expertiza YouTube Channel]

CSC/ECE 517 Fall 2020 - E2064. Refactor reputation web service controller.rb

2020-10-20T03:21:19Z

Srcapezz:

=='''Introduction'''==
==='''Introduction to Expertiza'''===
[http://expertiza.ncsu.edu/ Expertiza] is a peer review based system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types for assignments, including the URLs and wiki pages.
==='''About Reputation Web Service Controller'''===
Expertiza allows student work to be peer-reviewed, since peers can provide more feedback than the instructor can. However, if we want to assure that all students receive competent feedback, or even use peer-assigned grades, we need a way to judge which peer reviewers are most credible. The solution is the reputation system. Reputation systems have been deployed as web services, peer-review researchers will be able to use them to calculate scores on assignments, both past and present (past data can be used to tune the algorithms).
For this project, our team's job is to refactor the file: reputation_web_service_controller.rb. This file is the controller to calculate the reputation scores. A “reputation” measures how close a reviewer’s scores are to other reviewers’ scores. This controller implements the calculation of reputation scores.
----

=='''Issues to be fixed'''==

reputation_web_service_controller.rb is a fairly complex file. It contains a lot of methods that are long and hard to understand (for e.g. send_post_request). These methods need to be broken down into simpler and more specific methods that are easier to read/understand. Also, the few instances of code duplication that exist should be removed.

# There is a lot of unused/commented code, which should be removed.
# Figure out what the code is doing and write appropriate comments for it.
# Rename bad method names such as (db_query, json_generator). Method names should be verbs, and should say what the method does. Method names should not be so general that they could apply to many different methods..
# In the case of db_query, the name should say what it queries for. Also, this method not only queries, but calculates sums. Since each method should do only one thing, the code for calculating sums should be in another method. And there should be comments in the code!
#json_generator should be generate_json. There needs to be a method comment saying what the parameters are.
# In send_post_request, there are references to specific assignments, such as 724, 735, and 756. They were put in to gather data for a paper published in 2015. They are no longer relevant and should be removed. send_post_request is 91 lines long, far too long.
#There is a password for a private key in the code (and the code is open-sourced!) It should be in the db instead.
#Fix spelling of “dimention”
#client is a bad method name; why is stuff being copied from class variables to instance variables?

----

=='''Steps taken to resolve the issues'''==

----

=== Refactor db_query===

Renaming of bad method names such as (<code>db_query</code>). Method names should be verbs, and should say what the method does.
Method names should not be so general that they could apply to many different methods.
The other problem with the method was that it did not follow the good practice of having each method perform only one task.
This method got the review responses with a db query.
Also, it iterated over the review responses to perform a calculation of peer review grades.

We have split the method into two to have the review responses do only the get responses part.

[[File:snip7.png]]

 

=== The code for calculating sums should be in another method. ===
The result of this method is stored and we have created a new method <code>calculate_peer_review_grades</code> and moved the calculation part to it. 
We also added a comment to indicate the calculate weighted sum part.

 
[[File:snip8.png]]

 
And then, we have changed the call to the <code> get review responses</code> and the new method calculate peer review grades accordingly
 
[[File:snip3.png]]
 

Similarly, we have changed <code>db_query_with_quiz_scores</code> to <code>calculate_quiz_scores</code>

 
[[File:snip5.png]]
 

===''' Change name of json_generator'''===

json_generator method should be <code>generate_json</code>
Also,there needs to be a method comment saying what the parameters are.
We have added the method comments with parameter information as seen below.

[[File:snip4.png]]

===''' Refactor send_post_request'''===

“In (<code>send_post_request</code>), there are references to specific assignments, such as 724, 735, and 756.
They were put in to gather data for a paper published in 2015. They are no longer relevant and should be removed.
send_post_request is 91 lines long, far too long”

We observed that encryption of request being sent to evaluate Algorithm and decryption of response is written in (<code>send_post_request</code>) only that is why send post is 91 lines long.
We have created two separate methods
(<code>encrypt_request</code>)
(<code>decrypt_response</code>)

In the image below we can see that we have separated Encryption functionality from (<code>send_post_request</code>) to (<code>encrypt_request</code>)

[[File:encryption-separated.jpg]]

On the similar lines we have separated Decryption functionality from (<code>send_post_request</code>) to (<code>decrypt_response</code>)

[[File:decryption-separated.jpg]]

(<code>encrypt_request</code>) has been refactored as follows

[[File:encrypt_request.png]]

(<code>decrypt_response</code>) has been refactored as follows

[[File:decrypt_request.png]]

===''' Fixed spelling of dimention'''===

[[File:capture2.png]]

==='''Updating client method'''===

We changed the class variables in the code to instance variables because we realized that the send_post_request method and client method were the only methods using the class variables.
A client.html.erb file was used to call our controller to fill out a form for send_post_request which set values of class variables then immediately redirected control to the client method which set the instance variables to those class variables. The instance variables were then used in the rest of the client.html.erb file.

The process of setting class variables to instance variables with a function was redundant, so we removed simply set the instance variables within the send_post_request method and took them out of the client method.
The client method did have a few actions that it completed besides setting class variables which we have left in the method until we can find a solution to replacing them.

[[File:old-client-method.png|frame|none|alt=Alt text|Old client method]]

[[File:new-client-method-and-helpers-new.png|frame|none|alt=Alt text|Newest client method]]

The reason why we kept the client method's name is because the routes.rb file specifies the client method in the code and we haven't fully tracked down the impact of that yet.

== Testing ==
=== Test Plan ===
There was no existing tests available for the Reputation web service controller.
Since we are refactoring it, Our testing plan is to have an automated testing to ensure that the refactoring such as splitting a method into separate methods does not affect the existing implementation.
We also added steps for the manual testing to make sure the page loads as expected after the refactoring.
 
For the automated testing, We are using Rspec tests.
 
===RSpec===
We have tested the two new methods created during refactoring and also a renamed method.
The test coverage has increased a bit by 0.6% to 44%.
 

The tests we created can also be manually run with command 
<code>rspec spec/controllers/reputation_web_controller_spec.rb. </code>
 

[[File:snip13.png]]

===Manual UI Testing===
 
The steps to test our branch are below, but they are failing right now due to errors that are in other files of the beta branch.

To test our program you must login to the site here: http://152.7.98.78:8080/

Username: instructor6
Password: password

Then the page "Manage content" doesn't show up, go to Manage... -> Assignments

Then on the CSC 517, Fall 2017 Row, click on "Add Participants" in the actions column. This is also indicated by a blue shirted person.

Once in there, copy on of the student names (such as student7487) and then go to Manage... -> Impersonate User and enter their name (student7487) into the text field.

After impersonating them, you should be able to see their assignments. Click on any of their assignments such as "Program 1", then click on "Alternate View" to the right of "Your Scores".

 
----

=='''Modified Files'''==
<code>reputation_web_service_controller.rb</code>

=='''New Files'''==
<code>reputation_web_service_controller_spec.rb</code>

==Team Information==
'''Project Mentor:''' 
Saurabh Shingte

'''Project Members:''' 
Abhishek Gupta 
Skieler Capezza 
Ummu Kolusum Yasmin Ahamed Adam

=='''References'''==

*[https://github.com/srcapezza/expertiza/tree/beta Project Repo] 
*[https://github.com/expertiza/expertiza/pull/1790 Github Pull Request]
*[https://github.com/expertiza/expertiza Expertiza on GitHub]
*[http://expertiza.ncsu.edu/ The live Expertiza website]
*[http://research.csc.ncsu.edu/efg/expertiza Expertiza project Details]
*[https://www.youtube.com/channel/UCdKXzox7hrWjfOMML6FzTWg Expertiza YouTube Channel]

CSC/ECE 517 Fall 2020 - E2064. Refactor reputation web service controller.rb

2020-10-20T01:23:42Z

Srcapezz:

=='''Introduction'''==
==='''Introduction to Expertiza'''===
[http://expertiza.ncsu.edu/ Expertiza] is a peer review based system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types for assignments, including the URLs and wiki pages.
==='''About Reputation Web Service Controller'''===
Expertiza allows student work to be peer-reviewed, since peers can provide more feedback than the instructor can. However, if we want to assure that all students receive competent feedback, or even use peer-assigned grades, we need a way to judge which peer reviewers are most credible. The solution is the reputation system. Reputation systems have been deployed as web services, peer-review researchers will be able to use them to calculate scores on assignments, both past and present (past data can be used to tune the algorithms).
For this project, our team's job is to refactor the file: reputation_web_service_controller.rb. This file is the controller to calculate the reputation scores. A “reputation” measures how close a reviewer’s scores are to other reviewers’ scores. This controller implements the calculation of reputation scores.
----

=='''Issues to be fixed'''==

reputation_web_service_controller.rb is a fairly complex file. It contains a lot of methods that are long and hard to understand (for e.g. send_post_request). These methods need to be broken down into simpler and more specific methods that are easier to read/understand. Also, the few instances of code duplication that exist should be removed.

# There is a lot of unused/commented code, which should be removed.
# Figure out what the code is doing and write appropriate comments for it.
# Rename bad method names such as (db_query, json_generator). Method names should be verbs, and should say what the method does. Method names should not be so general that they could apply to many different methods..
# In the case of db_query, the name should say what it queries for. Also, this method not only queries, but calculates sums. Since each method should do only one thing, the code for calculating sums should be in another method. And there should be comments in the code!
#json_generator should be generate_json. There needs to be a method comment saying what the parameters are.
# In send_post_request, there are references to specific assignments, such as 724, 735, and 756. They were put in to gather data for a paper published in 2015. They are no longer relevant and should be removed. send_post_request is 91 lines long, far too long.
#There is a password for a private key in the code (and the code is open-sourced!) It should be in the db instead.
#Fix spelling of “dimention”
#client is a bad method name; why is stuff being copied from class variables to instance variables?

----

=='''Steps taken to resolve the issues'''==

----

=== Refactor db_query===

Renaming of bad method names such as (<code>db_query</code>). Method names should be verbs, and should say what the method does.
Method names should not be so general that they could apply to many different methods.
The other problem with the method was that it did not follow the good practice of having each method perform only one task.
This method got the review responses with a db query.
Also, it iterated over the review responses to perform a calculation of peer review grades.

We have split the method into two to have the review responses do only the get responses part.

[[File:snip7.png]]

 

=== The code for calculating sums should be in another method. ===
The result of this method is stored and we have created a new method <code>calculate_peer_review_grades</code> and moved the calculation part to it. 
We also added a comment to indicate the calculate weighted sum part.

 
[[File:snip8.png]]

 
And then, we have changed the call to the <code> get review responses</code> and the new method calculate peer review grades accordingly
 
[[File:snip3.png]]
 

Similarly, we have changed <code>db_query_with_quiz_scores</code> to <code>calculate_quiz_scores</code>

 
[[File:snip5.png]]
 

===''' Change name of json_generator'''===

json_generator method should be <code>generate_json</code>
Also,there needs to be a method comment saying what the parameters are.
We have added the method comments with parameter information as seen below.

[[File:snip4.png]]

===''' Refactor send_post_request'''===

“In (<code>send_post_request</code>), there are references to specific assignments, such as 724, 735, and 756.
They were put in to gather data for a paper published in 2015. They are no longer relevant and should be removed.
send_post_request is 91 lines long, far too long”

We observed that encryption of request being sent to evaluate Algorithm and decryption of response is written in (<code>send_post_request</code>) only that is why send post is 91 lines long.
We have created two separate methods
(<code>encrypt_request</code>)
(<code>decrypt_response</code>)

In the image below we can see that we have separated Encryption functionality from (<code>send_post_request</code>) to (<code>encrypt_request</code>)

[[File:encryption-separated.jpg]]

On the similar lines we have separated Decryption functionality from (<code>send_post_request</code>) to (<code>decrypt_response</code>)

[[File:decryption-separated.jpg]]

===''' Fixed spelling of dimention'''===

[[File:capture2.png]]

==='''Updating client method'''===

We changed the class variables in the code to instance variables because we realized that the send_post_request method and client method were the only methods using the class variables.
A client.html.erb file was used to call our controller to fill out a form for send_post_request which set values of class variables then immediately redirected control to the client method which set the instance variables to those class variables. The instance variables were then used in the rest of the client.html.erb file.

The process of setting class variables to instance variables with a function was redundant, so we removed simply set the instance variables within the send_post_request method and took them out of the client method.
The client method did have a few actions that it completed besides setting class variables which we have left in the method until we can find a solution to replacing them.

[[File:old-client-method.png|frame|none|alt=Alt text|Old client method]]

[[File:new-client-method-and-helpers-new.png|frame|none|alt=Alt text|Newest client method]]

The reason why we kept the client method's name is because the routes.rb file specifies the client method in the code and we haven't fully tracked down the impact of that yet.

== Testing ==
=== Test Plan ===
There was no existing tests available for the Reputation web service controller.
Since we are refactoring it, Our testing plan is to have an automated testing to ensure that the refactoring such as splitting a method into separate methods does not affect the existing implementation.
We also added steps for the manual testing to make sure the page loads as expected after the refactoring.
 
For the automated testing, We are using Rspec tests.
 
===RSpec===
We have tested the two new methods created during refactoring and also a renamed method.
The test coverage has increased a bit by 0.6% to 44%.
 

The tests we created can also be manually run with command 
<code>rspec spec/controllers/reputation_web_controller_spec.rb. </code>
 

[[File:snip13.png]]

===Manual UI Testing===
 
To test our program you must login to the site here: http://152.7.98.78:8080/

Username: instructor6
Password: password

Then if this page "Manage content" doesn't show up, go to Manage... -> Assignments

Then on the CSC 517, Fall 2017 Row, click on "Add Participants" in the actions column. This is also indicated by a blue shirted person.

Once in there, copy on of the student names (such as student7487) and then go to Manage... -> Impersonate User and enter their name (student7487) into the text field.

After impersonating them, you should be able to see their assignments. Click on any of their assignments such as "Program 1", then click on "Alternate View" to the right of "Your Scores". This will take you to a site that shows a Reputation Score like in the screenshot below. This proves that our controller has given the information to this view for the

 
----

=='''Modified Files'''==
<code>reputation_web_service_controller.rb</code>

=='''New Files'''==
<code>reputation_web_service_controller_spec.rb</code>

==Team Information==
'''Project Mentor:''' 
Saurabh Shingte

'''Project Members:''' 
Abhishek Gupta 
Skieler Capezza 
Ummu Kolusum Yasmin Ahamed Adam

=='''References'''==

*[https://github.com/srcapezza/expertiza/tree/beta Project Repo] 
*[https://github.com/expertiza/expertiza/pull/1790 Github Pull Request]
*[https://github.com/expertiza/expertiza Expertiza on GitHub]
*[http://expertiza.ncsu.edu/ The live Expertiza website]
*[http://research.csc.ncsu.edu/efg/expertiza Expertiza project Details]
*[https://www.youtube.com/channel/UCdKXzox7hrWjfOMML6FzTWg Expertiza YouTube Channel]

CSC/ECE 517 Fall 2020 - E2064. Refactor reputation web service controller.rb

2020-10-14T02:48:01Z

Srcapezz:

=='''Introduction'''==
==='''Introduction to Expertiza'''===
[http://expertiza.ncsu.edu/ Expertiza] is a peer review based system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types for assignments, including the URLs and wiki pages.
==='''Problem Statement'''===
Expertiza allows student work to be peer-reviewed, since peers can provide more feedback than the instructor can. However, if we want to assure that all students receive competent feedback, or even use peer-assigned grades, we need a way to judge which peer reviewers are most credible. The solution is the reputation system. Reputation systems have been deployed as web services, peer-review researchers will be able to use them to calculate scores on assignments, both past and present (past data can be used to tune the algorithms).
For this project, our team's job is to refactor the file: reputation_web_service_controller.rb. This file is the controller to calculate the reputation scores. A “reputation” measures how close a reviewer’s scores are to other reviewers’ scores. This controller implements the calculation of reputation scores.
----

=='''Issues to be fixed'''==

reputation_web_service_controller.rb is a fairly complex file. It contains a lot of methods that are long and hard to understand (for e.g. send_post_request). These methods need to be broken down into simpler and more specific methods that are easier to read/understand. Also, the few instances of code duplication that exist should be removed.

# There is a lot of unused/commented code, which should be removed.
# Figure out what the code is doing and write appropriate comments for it.
# Rename bad method names such as (db_query, json_generator). Method names should be verbs, and should say what the method does. Method names should not be so general that they could apply to many different methods..
# In the case of db_query, the name should say what it queries for. Also, this method not only queries, but calculates sums. Since each method should do only one thing, the code for calculating sums should be in another method. And there should be comments in the code!
#json_generator should be generate_json. There needs to be a method comment saying what the parameters are.
# In send_post_request, there are references to specific assignments, such as 724, 735, and 756. They were put in to gather data for a paper published in 2015. They are no longer relevant and should be removed. send_post_request is 91 lines long, far too long.
#There is a password for a private key in the code (and the code is open-sourced!) It should be in the db instead.
#Fix spelling of “dimention”
#client is a bad method name; why is stuff being copied from class variables to instance variables?

----

=='''Modified Files'''==

reputation_web_service_controller.rb

----

=='''Important links'''==

[https://github.com/srcapezza/expertiza/tree/beta Project Repo] 

[https://github.com/expertiza/expertiza/pull/1790 Github Pull Request]

----

=='''Steps taken to resolve the issues'''==

----

=== Refactor db_query===

Renaming of bad method names such as (<code>db_query</code>). Method names should be verbs, and should say what the method does.
Method names should not be so general that they could apply to many different methods.
The other problem with the method was that it did not follow the good practice of having each method perform only one task.
This method got the review responses with a db query.
Also, it iterated over the review responses to perform a calculation of peer review grades.

We have split the method into two to have the review responses do only the get responses part.

[[File:snip7.png]]

 

=== The code for calculating sums should be in another method. ===
The result of this method is stored and we have created a new method <code>calculate_peer_review_grades</code> and moved the calculation part to it. 
We also added a comment to indicate the calculate weighted sum part.

 
[[File:snip8.png]]

 

And then, we have changed the call to the <code> get review responses</code> and the new method calculate peer review grades accordingly

 

[[File:snip3.png]]
 

Similarly, we have changed <code>db_query_with_quiz_scores</code> to <code>calculate_quiz_scores</code>

[[File:snip5.png]]
 

===''' Change name of json_generator'''===

json_generator method should be <code>generate_json</code>
Also,there needs to be a method comment saying what the parameters are.
We have added the method comments with parameter information as seen below.

[[File:snip4.png]]

===''' Refactor send_post_request'''===

“In (<code>send_post_request</code>), there are references to specific assignments, such as 724, 735, and 756.
They were put in to gather data for a paper published in 2015. They are no longer relevant and should be removed.
send_post_request is 91 lines long, far too long”

We observed that encryption of request being sent to evaluate Algorithm and decryption of response is written in (<code>send_post_request</code>) only that is why send post is 91 lines long.
We have created two separate methods
(<code>encrypt_request</code>)
(<code>decrypt_response</code>)

In the image below we can see that we have separated Encryption functionality from (<code>send_post_request</code>) to (<code>encrypt_request</code>)

[[File:encryption-separated.jpg]]

On the similar lines we have separated Decryption functionality from (<code>send_post_request</code>) to (<code>decrypt_response</code>)

[[File:decryption-separated.jpg]]

==='''Updating client method'''===

We changed the class variables in the code to instance variables because we realized that the send_post_request method and client method were the only methods using the class variables.
A client.html.erb file was used to call our controller to fill out a form for send_post_request which set values of class variables then immediately redirected control to the client method which set the instance variables to those class variables. The instance variables were then used in the rest of the client.html.erb file.

The process of setting class variables to instance variables with a function was redundant, so we removed simply set the instance variables within the send_post_request method and took them out of the client method.
The client method did have a few actions that it completed besides setting class variables which we have left in the method until we can find a solution to replacing them.

[[File:old-client-method.png|frame|none|alt=Alt text|Old client method]]

[[File:new-client-method-and-helpers-new.png|frame|none|alt=Alt text|Newest client method]]

The reason why we kept the client method's name is because the routes.rb file specifies the client method in the code and we haven't fully tracked down the impact of that yet.

----

'''Team Information''' 
'''Project Mentor:''' 
Saurabh Shingte

'''Project Members:''' 
Abhishek Gupta 
Skieler Capezza 
Ummu Kolusum Yasmin Ahamed Adam

CSC/ECE 517 Fall 2020 - E2064. Refactor reputation web service controller.rb

2020-10-14T02:47:54Z

Srcapezz:

=='''Introduction'''==
==='''Introduction to Expertiza'''===
[http://expertiza.ncsu.edu/ Expertiza] is a peer review based system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types for assignments, including the URLs and wiki pages.
==='''Problem Statement'''===
Expertiza allows student work to be peer-reviewed, since peers can provide more feedback than the instructor can. However, if we want to assure that all students receive competent feedback, or even use peer-assigned grades, we need a way to judge which peer reviewers are most credible. The solution is the reputation system. Reputation systems have been deployed as web services, peer-review researchers will be able to use them to calculate scores on assignments, both past and present (past data can be used to tune the algorithms).
For this project, our team's job is to refactor the file: reputation_web_service_controller.rb. This file is the controller to calculate the reputation scores. A “reputation” measures how close a reviewer’s scores are to other reviewers’ scores. This controller implements the calculation of reputation scores.
----

=='''Issues to be fixed'''==

reputation_web_service_controller.rb is a fairly complex file. It contains a lot of methods that are long and hard to understand (for e.g. send_post_request). These methods need to be broken down into simpler and more specific methods that are easier to read/understand. Also, the few instances of code duplication that exist should be removed.

# There is a lot of unused/commented code, which should be removed.
# Figure out what the code is doing and write appropriate comments for it.
# Rename bad method names such as (db_query, json_generator). Method names should be verbs, and should say what the method does. Method names should not be so general that they could apply to many different methods..
# In the case of db_query, the name should say what it queries for. Also, this method not only queries, but calculates sums. Since each method should do only one thing, the code for calculating sums should be in another method. And there should be comments in the code!
#json_generator should be generate_json. There needs to be a method comment saying what the parameters are.
# In send_post_request, there are references to specific assignments, such as 724, 735, and 756. They were put in to gather data for a paper published in 2015. They are no longer relevant and should be removed. send_post_request is 91 lines long, far too long.
#There is a password for a private key in the code (and the code is open-sourced!) It should be in the db instead.
#Fix spelling of “dimention”
#client is a bad method name; why is stuff being copied from class variables to instance variables?

----

=='''Modified Files'''==

reputation_web_service_controller.rb

----

=='''Important links'''==

[https://github.com/srcapezza/expertiza/tree/beta Project Repo] 

[https://github.com/expertiza/expertiza/pull/1790 Github Pull Request]

----

=='''Steps taken to resolve the issues'''==

----

=== Refactor db_query===

Renaming of bad method names such as (<code>db_query</code>). Method names should be verbs, and should say what the method does.
Method names should not be so general that they could apply to many different methods.
The other problem with the method was that it did not follow the good practice of having each method perform only one task.
This method got the review responses with a db query.
Also, it iterated over the review responses to perform a calculation of peer review grades.

We have split the method into two to have the review responses do only the get responses part.

[[File:snip7.png]]

 

=== The code for calculating sums should be in another method. ===
The result of this method is stored and we have created a new method <code>calculate_peer_review_grades</code> and moved the calculation part to it. 
We also added a comment to indicate the calculate weighted sum part.

 
[[File:snip8.png]]

 

And then, we have changed the call to the <code> get review responses</code> and the new method calculate peer review grades accordingly

 

[[File:snip3.png]]
 

Similarly, we have changed <code>db_query_with_quiz_scores</code> to <code>calculate_quiz_scores</code>

[[File:snip5.png]]
 

===''' Change name of json_generator'''===

json_generator method should be <code>generate_json</code>
Also,there needs to be a method comment saying what the parameters are.
We have added the method comments with parameter information as seen below.

[[File:snip4.png]]

===''' Refactor send_post_request'''===

“In (<code>send_post_request</code>), there are references to specific assignments, such as 724, 735, and 756.
They were put in to gather data for a paper published in 2015. They are no longer relevant and should be removed.
send_post_request is 91 lines long, far too long”

We observed that encryption of request being sent to evaluate Algorithm and decryption of response is written in (<code>send_post_request</code>) only that is why send post is 91 lines long.
We have created two separate methods
(<code>encrypt_request</code>)
(<code>decrypt_response</code>)

In the image below we can see that we have separated Encryption functionality from (<code>send_post_request</code>) to (<code>encrypt_request</code>)

[[File:encryption-separated.jpg]]

On the similar lines we have separated Decryption functionality from (<code>send_post_request</code>) to (<code>decrypt_response</code>)

[[File:decryption-separated.jpg]]

==='''Updating client method'''===

We changed the class variables in the code to instance variables because we realized that the send_post_request method and client method were the only methods using the class variables.
A client.html.erb file was used to call our controller to fill out a form for send_post_request which set values of class variables then immediately redirected control to the client method which set the instance variables to those class variables. The instance variables were then used in the rest of the client.html.erb file.

The process of setting class variables to instance variables with a function was redundant, so we removed simply set the instance variables within the send_post_request method and took them out of the client method.
The client method did have a few actions that it completed besides setting class variables which we have left in the method until we can find a solution to replacing them.

[[File:new-client-method-and-helpers-new.png|frame|none|alt=Alt text|Newest client method]]

The reason why we kept the client method's name is because the routes.rb file specifies the client method in the code and we haven't fully tracked down the impact of that yet.

----

'''Team Information''' 
'''Project Mentor:''' 
Saurabh Shingte

'''Project Members:''' 
Abhishek Gupta 
Skieler Capezza 
Ummu Kolusum Yasmin Ahamed Adam

File:Old-client-method.png

2020-10-14T02:47:32Z

Srcapezz: