Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-30T04:04:42Z

Yli273: /* RSpec Testing */

This page provides a description of the Expertiza based OSS project.

__TOC__
==Introduction==
Rounds of peer reviews may be implemented between submissions for assignments on Expertiza. In order to better track the implementation of reviewer's suggestions, a Revision Planning Tool should be implemented.

===Problem Statement===
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then the second round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

[[File:E2152_Problem_Statement.png|400px|center]]

===Previous Implementations===
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

Revision planning has been implemented three times before, once in [https://expertiza.csc.ncsu.edu/index.php/E1875_Revision_Planning_Tool E1875], once in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_E2016_Revision_planning_tool E2016] and another one in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2020_-_E2083._Revision_planning_tool_E2016 E2083]. While the functionality worked and effectively minimized changes to the code, they also had the following problems:
*Hardcoded “round” numbers in many places of the code.
*Documentation does not reflect the new changes they made.
*Revision planning responses and responses to the other items are not distinguished in heatgrid view.
*The idea of adding a <code>team_id</code> field to each question is intuitive. However, they failed to come up with a clean implementation of this idea. Specifically, they had passed some trailing parameters several methods down before reaching the place that needs them.

===Problems with Previous Implementation===
*Students cannot edit the revision plan in the review phase so the review doesn't get changed while other students are reviewing. However, it assumes that reviews cannot be done during the submission phase. Code needs to be written to take care of this part.
*Set up an assignment with 2 rounds of review.
*Allow editing the revision-planning rubric just like editing a normal rubric, using a shared template.
*Instructors and students can view the review report with the revision plan placed in a separate section.
*In RevisionPlanQuestionnairesController, the method for determining who's on a team would be better located in team.rb.
*The current_round method duplicates a method elsewhere in the system.
*The generate_heatgrid has too many conditional statements. It would be better to split it into smaller methods.
*A lot of code deals with score calculations, which shouldn't be a concern for this project.
*Too many files are involved, although they seem to make reasonable decisions about their changes.
*The code should have more comments.
*The team had a good initial design but took as twice much as LoC compared to the previous teams.

===Goals===
*Force the student to add revision plan before submit their work at round 2 submission.
*Set up an assignment with 2 rounds of review.
*Allow editing the revision-planning rubric just like editing a normal rubric, using a shared template.
*Relocate the method for determining who's on a team in RevisionPlanQuestionnairesController to team.rb.

===Rationale===
The general workflow is shown bellow.
[[File:E2152_Rationale.png|410px|center]]

=Proposed Solution=

===Implementation===

*1. Force the students to add revision plan before submit their work at round 2 submission
The revision plan cannot be operated in all of the phases but before round 2 submission. In the round 2 submission, the "Your Work" part cannot be chosen only if you finish to edit the "Revision Planning" part. By doing this, we can let students add revision plan before submit their work at round 2 submission.

Changes:

Change the logic, before the round 2 submission, there is no need to judge, directly let the "Revision planning" part invalid. And when it comes to the round 2 submission, the "Your Work" part is invalid, and the "Revision planning" part can be edited.

past code:

<% if @assignment.submission_allowed(@topic_id) %>

modified code:
app/views/student_task/view.html.erb
<% if (!@can_submit_revision_plan && @assignment.submission_allowed(@topic_id)) ||
(@can_submit_revision_plan && @revision_plan_questionnaire_id && @assignment.submission_allowed(@topic_id)) %>

Result:

Firstly, before the round 2 submission, you can look into your work, but the revision plan.
[[File:211129-2.png|700px|thumb|center]]
And then, when it comes to the round 2 submission, if we didn't deal with the "Revision Planning", then the "Your work" part becomes gray.
[[File:211129-5.png|700px|thumb|center]]
After editing the "Revision Planning", we can submit our work.
[[File:211129-6.png|700px|thumb|center]]

*2. Set up an assignment with 2 rounds of review
Set up assignment with 2 rounds of review. The result is shown above. And here's the figure in the background. We can set the rounds whatever we want.
[[File:211129-7.png|700px|thumb|center]]

*3. Revision-planning rubric
the revision-planning rubric was allowed to be edited after the first round of revision, using a shared template with normal rubric.
This page will be unavailable during all review periods.
[[File:gsj_5.png|700px|thumb|center|Revision Plan page exists]]
The Revision Plan Questionnaire could be edited by specifying the amount of questions and their type.
Questions can be removed by clicking Remove in the leftmost column.
Once the questionnaire is complete, it can be saved.
[[File:gsj_fall2021.png|700px|thumb|center|Edit Revision Plan page demonstrating]]
In the second round of review, the revision plan questionnaire which edited by autohrs could be seen in a separate section.
[[File:gsj_1.png|400px|thumb|center|Review page demonstrating added Revision Plan questions]]
[[File:gsj_3.png|400px|thumb|center|Review page demonstrating added Revision Plan questions]]

*4. Relocate the method
The method for determining who's on a team was in RevisionPlanQuestionnairesController, now has been reloacted in team.rb.

Before:
app/controllers/revision_plan_questionnaires_controller.rb
TeamsUser.where(["team_id = ?", params[:team_id]]).each do |teamuser|
@team_members.push( teamuser.user_id)
end
(user_logged_in? && @team_members.collect { |u| }.include?(session[:user].id)) || 1

After:
app/models/team.rb

def self.is_team_members?(team_id,user_id)
@team_members = Array.new
TeamsUser.where(["team_id = ?", team_id]).each do |teamuser|
@team_members.push(teamuser.user_id)
end
return @team_members.collect { |u| }.include?(user_id)
end

*5. Code Optimization
*Delete the duplicated current_round method.
*Split the conditional statements of generate_heatgrid into smaller subclass methods.

===Files Modified===
This is a list of files modified.
*app/controllers/revision_plan_questionnaires_controller.rb
*app/models/team.rb
*app/controllers/grades_controller.rb
*app/helpers/grades_helper.rb
*app/models/assignment_participant.rb
*app/models/response_map.rb
*app/views/grades/_participant_charts.html.erb
*app/views/grades/view_team.html.erb
*app/views/student_task/view.html.erb
*app/controllers/response_controller.rb
*app/views/response/response.html.erb
*config/routes.rb
*db/schema.rb
*spec/models/response_spec.rb
*spec/models/review_response_map_spec.rb
*spec/features/assignment_creation_general_tab_spec.rb
*app/models/revision_plan_team_map.rb

==Design==
===Database Design===
Items in green are additions.
[[File:E2152_Design.png|1000px|center]]
 
Changes:
*In the assignment table we have added <code>is_revision_planning_enabled?</code> column to indicate whether the assignment accepts a revision plan along with review rubric.
*<code>RevisionPlanTeamMap</code> maps a questionnaire to an assignment team and round. This will map to a questionnaire of type revision plan that will be created by the revewee.
*<code>RevisionPlanQuestionnaire</code> extends <code>Questionnaire</code> using single table inheritance.

===User Interface===
====Review Restriction Change====
In the previous version, students cannot edit the revision plan in the review during the submission phase. However, they just cannot edit during the review phase. There's the change for this mistake.
=====Initial Wireframe=====
[[File:Previous1.png|700px|thumb|center|Reviews cannot be done during the submission phase]]

=====Final UI=====
[[File:after1.png|700px|thumb|center|Reviews cannot be done during the submission phase]]

=====Implementation=====

=Test Plan=

====RSpec Testing====
The RSpec tests are written to test both controller and models.

Controllers

*rspec spec/controllers/grades_controller_spec.rb
[[Grades_controller_spec_new.png]]
*rspec spec/controllers/questionnaires_controller_spec.rb
*rspec spec/controllers/questions_controller_spec.rb
*rspec spec/controllers/student_teams_controller_spec.rb
*spec/controllers/response_controller_spec.rb: Updated spec by stubbing get_questions method to pass.
*spec/controllers/revision_plan_questionnaires_controller_spec.rb: Updated spec by adding four examples to test revision plan questionnaires controller
*spec/factories/revision_plan_factory.rb: Create a new factory.rb to create objects unique to revision plans, including RevisionPlanQuestionnaire RevisionPlanTeamMap

Models

*spec/models/response_spec.rb: Updated spec by updating expected html output to pass.
*spec/models/review_response_map_spec.rb: Updated spec by updating expected html output to pass.

Helpers

*rspec spec/heplers/grades_helper.rb

====Manual Testing====
Manual testing aims to verify the following:

*Can an assignment with revision planning enabled be created?
*Can an assignment with 2 rounds of review be set up?
*If the revision-planning rubric can be edited or not?
*Is the revision plan a separate section?
*Does the method determining the members of a team existed in team.rb?
*Dose the system have redundant functions?
*Are participants allowed to create/edit revision plan when round 1+ (1 or greater than 1) reviews have finished?
*Is revision plan editing disabled when assignment is in review stage?
*Are reviewers shown questions created by reviewees?
*Does participants show summary of score for revision plan after review deadline has expired?

Since we are still working on our project, the following is part of our UI testing.

1. Go to the overview page of the assignment, the revision planning should only be available at 1st review phase.
[[File:E2152_Revision_Plan_avaliable.png|1000px|center]]
[[File:E2152_Revision_Plan_unavaliable.png|1000px|center]]

==Team Members==
Kai Gao (kgao2@ncsu.edu)
 
Huangxing Chen (hchen63)
 
Yi Li (yli273)
 
Shengjie Guo (sguo25)
 
'''Mentor:''' Nicholas Himes (nnhimes@ncsu.edu)

==References==

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-30T00:55:06Z

Yli273: /* RSpec Testing */

This page provides a description of the Expertiza based OSS project.

__TOC__
==Introduction==
Rounds of peer reviews may be implemented between submissions for assignments on Expertiza. In order to better track the implementation of reviewer's suggestions, a Revision Planning Tool should be implemented.

===Problem Statement===
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then the second round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

[[File:E2152_Problem_Statement.png|400px|center]]

===Previous Implementations===
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

Revision planning has been implemented three times before, once in [https://expertiza.csc.ncsu.edu/index.php/E1875_Revision_Planning_Tool E1875], once in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_E2016_Revision_planning_tool E2016] and another one in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2020_-_E2083._Revision_planning_tool_E2016 E2083]. While the functionality worked and effectively minimized changes to the code, they also had the following problems:
*Hardcoded “round” numbers in many places of the code.
*Documentation does not reflect the new changes they made.
*Revision planning responses and responses to the other items are not distinguished in heatgrid view.
*The idea of adding a <code>team_id</code> field to each question is intuitive. However, they failed to come up with a clean implementation of this idea. Specifically, they had passed some trailing parameters several methods down before reaching the place that needs them.

===Problems with Previous Implementation===
*Students cannot edit the revision plan in the review phase so the review doesn't get changed while other students are reviewing. However, it assumes that reviews cannot be done during the submission phase. Code needs to be written to take care of this part.
*Set up an assignment with 2 rounds of review.
*Allow editing the revision-planning rubric just like editing a normal rubric, using a shared template.
*Instructors and students can view the review report with the revision plan placed in a separate section.
*In RevisionPlanQuestionnairesController, the method for determining who's on a team would be better located in team.rb.
*The current_round method duplicates a method elsewhere in the system.
*The generate_heatgrid has too many conditional statements. It would be better to split it into smaller methods.
*A lot of code deals with score calculations, which shouldn't be a concern for this project.
*Too many files are involved, although they seem to make reasonable decisions about their changes.
*The code should have more comments.
*The team had a good initial design but took as twice much as LoC compared to the previous teams.

===Goals===
*Force the student to add revision plan before submit their work at round 2 submission.
*Set up an assignment with 2 rounds of review.
*In the second round of review, the revision plan questionnaire can be seen in a separate section.
*Relocate the method for determining who's on a team in RevisionPlanQuestionnairesController to team.rb.

===Rationale===
The general workflow is shown bellow.
[[File:E2152_Rationale.png|410px|center]]

=Proposed Solution=

===Implementation===

*1. Force the students to add revision plan before submit their work at round 2 submission
The revision plan cannot be operated in all of the phases but before round 2 submission. In the round 2 submission, the "Your Work" part cannot be chosen only if you finish to edit the "Revision Planning" part. By doing this, we can let students add revision plan before submit their work at round 2 submission.

Changes:

Change the logic, before the round 2 submission, there is no need to judge, directly let the "Revision planning" part invalid. And when it comes to the round 2 submission, the "Your Work" part is invalid, and the "Revision planning" part can be edited.

past code:

<% if @assignment.submission_allowed(@topic_id) %>

modified code:
app/views/student_task/view.html.erb
<% if (!@can_submit_revision_plan && @assignment.submission_allowed(@topic_id)) ||
(@can_submit_revision_plan && @revision_plan_questionnaire_id && @assignment.submission_allowed(@topic_id)) %>

Result:

Firstly, before the round 2 submission, you can look into your work, but the revision plan.
[[File:211129-2.png|700px|thumb|center]]
And then, when it comes to the round 2 submission, if we didn't deal with the "Revision Planning", then the "Your work" part becomes gray.
[[File:211129-5.png|700px|thumb|center]]
After editing the "Revision Planning", we can submit our work.
[[File:211129-6.png|700px|thumb|center]]

*2. Set up an assignment with 2 rounds of review
Set up assignment with 2 rounds of review. The result is shown above. And here's the figure in the background. We can set the rounds whatever we want.
[[File:211129-7.png|700px|thumb|center]]

*3. Revision-planning rubric
the revision-planning rubric was allowed to be edited after the first round of revision, using a shared template with normal rubric.
This page will be unavailable during all review periods.

The Revision Plan Questionnaire could be edited by specifying the amount of questions and their type.
Questions can be removed by clicking Remove in the leftmost column.
Once the questionnaire is complete, it can be saved.
[[File:gsj_fall2021.png|700px|thumb|center|Edit Revision Plan page demonstrating]]
In the second round of review, the revision plan questionnaire which edited by autohrs could be seen in a separate section.
[[File:gsj_1.png|400px|thumb|center|Review page demonstrating added Revision Plan questions]]
[[File:gsj_3.png|400px|thumb|center|Review page demonstrating added Revision Plan questions]]

*4. Relocate the method
The method for determining who's on a team was in RevisionPlanQuestionnairesController, now has been reloacted in team.rb.

Before:
app/controllers/revision_plan_questionnaires_controller.rb
TeamsUser.where(["team_id = ?", params[:team_id]]).each do |teamuser|
@team_members.push( teamuser.user_id)
end
(user_logged_in? && @team_members.collect { |u| }.include?(session[:user].id)) || 1

After:
app/models/team.rb

def self.is_team_members?(team_id,user_id)
@team_members = Array.new
TeamsUser.where(["team_id = ?", team_id]).each do |teamuser|
@team_members.push(teamuser.user_id)
end
return @team_members.collect { |u| }.include?(user_id)
end

*5. Code Optimization
*Delete the duplicated current_round method.
*Split the conditional statements of generate_heatgrid into smaller subclass methods.

===Files Modified===

==Design==
===Database Design===
Items in green are additions.
[[File:E2152_Design.png|1000px|center]]
 
Changes:
*In the assignment table we have added <code>is_revision_planning_enabled?</code> column to indicate whether the assignment accepts a revision plan along with review rubric.
*<code>RevisionPlanTeamMap</code> maps a questionnaire to an assignment team and round. This will map to a questionnaire of type revision plan that will be created by the revewee.
*<code>RevisionPlanQuestionnaire</code> extends <code>Questionnaire</code> using single table inheritance.

===User Interface===
====Review Restriction Change====
In the previous version, students cannot edit the revision plan in the review during the submission phase. However, they just cannot edit during the review phase. There's the change for this mistake.
=====Initial Wireframe=====
[[File:Previous1.png|700px|thumb|center|Reviews cannot be done during the submission phase]]

=====Final UI=====
[[File:after1.png|700px|thumb|center|Reviews cannot be done during the submission phase]]

=====Implementation=====
*change the conditions for submission, which means the second round of assignment cannot be submitted without revision_plan being subbmited first
app/views/student_task/view.html.erb
before
<% if @assignment.submission_allowed(@topic_id) %>
after
<% if (!@can_submit_revision_plan && @assignment.submission_allowed(@topic_id)) ||
(@can_submit_revision_plan && @revision_plan_questionnaire_id && @assignment.submission_allowed(@topic_id)) %>

=Test Plan=

====RSpec Testing====
The RSpec tests are written to test both controller and models.

Controllers

*rspec spec/controllers/grades_controller_spec.rb
[[Grades_controller_spec_result.png]]
*rspec spec/controllers/questionnaires_controller_spec.rb
*rspec spec/controllers/questions_controller_spec.rb
*rspec spec/controllers/student_teams_controller_spec.rb
*spec/controllers/response_controller_spec.rb: Updated spec by stubbing get_questions method to pass.
*spec/controllers/revision_plan_questionnaires_controller_spec.rb: Updated spec by adding four examples to test revision plan questionnaires controller
*spec/factories/revision_plan_factory.rb: Create a new factory.rb to create objects unique to revision plans, including RevisionPlanQuestionnaire RevisionPlanTeamMap

Models

*spec/models/response_spec.rb: Updated spec by updating expected html output to pass.
*spec/models/review_response_map_spec.rb: Updated spec by updating expected html output to pass.

Helpers

*rspec spec/heplers/grades_helper.rb

====Manual Testing====
Manual testing aims to verify the following:

*Can an assignment with revision planning enabled be created?
*Can an assignment with 2 rounds of review be set up?
*If the revision-planning rubric can be edited or not?
*Is the revision plan a separate section?
*Does the method determining the members of a team existed in team.rb?
*Dose the system have redundant functions?
*Are participants allowed to create/edit revision plan when round 1+ (1 or greater than 1) reviews have finished?
*Is revision plan editing disabled when assignment is in review stage?
*Are reviewers shown questions created by reviewees?
*Does participants show summary of score for revision plan after review deadline has expired?

Since we are still working on our project, the following is part of our UI testing.

1. Go to the overview page of the assignment, the revision planning should only be available at 1st review phase.
[[File:E2152_Revision_Plan_avaliable.png|1000px|center]]
[[File:E2152_Revision_Plan_unavaliable.png|1000px|center]]

==Team Members==
Kai Gao (kgao2@ncsu.edu)
 
Huangxing Chen (hchen63)
 
Yi Li (yli273)
 
Shengjie Guo (sguo25)
 
'''Mentor:''' Nicholas Himes (nnhimes@ncsu.edu)

==References==

File:Grades controller spec result.png

2021-11-30T00:54:43Z

Yli273:

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-30T00:52:45Z

Yli273: /* RSpec Testing */

This page provides a description of the Expertiza based OSS project.

__TOC__
==Introduction==
Rounds of peer reviews may be implemented between submissions for assignments on Expertiza. In order to better track the implementation of reviewer's suggestions, a Revision Planning Tool should be implemented.

===Problem Statement===
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then the second round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

[[File:E2152_Problem_Statement.png|400px|center]]

===Previous Implementations===
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

Revision planning has been implemented three times before, once in [https://expertiza.csc.ncsu.edu/index.php/E1875_Revision_Planning_Tool E1875], once in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_E2016_Revision_planning_tool E2016] and another one in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2020_-_E2083._Revision_planning_tool_E2016 E2083]. While the functionality worked and effectively minimized changes to the code, they also had the following problems:
*Hardcoded “round” numbers in many places of the code.
*Documentation does not reflect the new changes they made.
*Revision planning responses and responses to the other items are not distinguished in heatgrid view.
*The idea of adding a <code>team_id</code> field to each question is intuitive. However, they failed to come up with a clean implementation of this idea. Specifically, they had passed some trailing parameters several methods down before reaching the place that needs them.

===Problems with Previous Implementation===
*Students cannot edit the revision plan in the review phase so the review doesn't get changed while other students are reviewing. However, it assumes that reviews cannot be done during the submission phase. Code needs to be written to take care of this part.
*Set up an assignment with 2 rounds of review.
*Allow editing the revision-planning rubric just like editing a normal rubric, using a shared template.
*Instructors and students can view the review report with the revision plan placed in a separate section.
*In RevisionPlanQuestionnairesController, the method for determining who's on a team would be better located in team.rb.
*The current_round method duplicates a method elsewhere in the system.
*The generate_heatgrid has too many conditional statements. It would be better to split it into smaller methods.
*A lot of code deals with score calculations, which shouldn't be a concern for this project.
*Too many files are involved, although they seem to make reasonable decisions about their changes.
*The code should have more comments.
*The team had a good initial design but took as twice much as LoC compared to the previous teams.

===Goals===
*Force the student to add revision plan before submit their work at round 2 submission.
*Set up an assignment with 2 rounds of review.
*In the second round of review, the revision plan questionnaire can be seen in a separate section.
*Relocate the method for determining who's on a team in RevisionPlanQuestionnairesController to team.rb.

===Rationale===
The general workflow is shown bellow.
[[File:E2152_Rationale.png|410px|center]]

=Proposed Solution=

===Implementation===

*1. Force the students to add revision plan before submit their work at round 2 submission
The revision plan cannot be operated in all of the phases but before round 2 submission. In the round 2 submission, the "Your Work" part cannot be chosen only if you finish to edit the "Revision Planning" part. By doing this, we can let students add revision plan before submit their work at round 2 submission.

Changes:

Change the logic, before the round 2 submission, there is no need to judge, directly let the "Revision planning" part invalid. And when it comes to the round 2 submission, the "Your Work" part is invalid, and the "Revision planning" part can be edited.

past code:

<% if @assignment.submission_allowed(@topic_id) %>

modified code:
app/views/student_task/view.html.erb
<% if (!@can_submit_revision_plan && @assignment.submission_allowed(@topic_id)) ||
(@can_submit_revision_plan && @revision_plan_questionnaire_id && @assignment.submission_allowed(@topic_id)) %>

Result:

Firstly, before the round 2 submission, you can look into your work, but the revision plan.
[[File:211129-2.png|700px|thumb|center]]
And then, when it comes to the round 2 submission, if we didn't deal with the "Revision Planning", then the "Your work" part becomes gray.
[[File:211129-5.png|700px|thumb|center]]
After editing the "Revision Planning", we can submit our work.
[[File:211129-6.png|700px|thumb|center]]

*2. Set up an assignment with 2 rounds of review
Set up assignment with 2 rounds of review. The result is shown above. And here's the figure in the background. We can set the rounds whatever we want.
[[File:211129-7.png|700px|thumb|center]]

*3. Revision-planning rubric
the revision-planning rubric was allowed to be edited after the first round of revision, using a shared template with normal rubric.
This page will be unavailable during all review periods.

The Revision Plan Questionnaire could be edited by specifying the amount of questions and their type.
Questions can be removed by clicking Remove in the leftmost column.
Once the questionnaire is complete, it can be saved.
[[File:gsj_fall2021.png|700px|thumb|center|Edit Revision Plan page demonstrating]]
In the second round of review, the revision plan questionnaire which edited by autohrs could be seen in a separate section.
[[File:gsj_1.png|400px|thumb|center|Review page demonstrating added Revision Plan questions]]
[[File:gsj_3.png|400px|thumb|center|Review page demonstrating added Revision Plan questions]]

*4. Relocate the method
The method for determining who's on a team was in RevisionPlanQuestionnairesController, now has been reloacted in team.rb.
Before
app/controllers/revision_plan_questionnaires_controller.rb

After
app/models/team.rb

def self.is_team_members?(team_id,user_id)
@team_members = Array.new
TeamsUser.where(["team_id = ?", team_id]).each do |teamuser|
@team_members.push(teamuser.user_id)
end
return @team_members.collect { |u| }.include?(user_id)
end

*5. Code Optimization
*Delete the duplicated current_round method.
*Split the conditional statements of generate_heatgrid into smaller subclass methods.

===Files Modified===

==Design==
===Database Design===
Items in green are additions.
[[File:E2152_Design.png|1000px|center]]
 
Changes:
*In the assignment table we have added <code>is_revision_planning_enabled?</code> column to indicate whether the assignment accepts a revision plan along with review rubric.
*<code>RevisionPlanTeamMap</code> maps a questionnaire to an assignment team and round. This will map to a questionnaire of type revision plan that will be created by the revewee.
*<code>RevisionPlanQuestionnaire</code> extends <code>Questionnaire</code> using single table inheritance.

===User Interface===
====Review Restriction Change====
In the previous version, students cannot edit the revision plan in the review during the submission phase. However, they just cannot edit during the review phase. There's the change for this mistake.
=====Initial Wireframe=====
[[File:Previous1.png|700px|thumb|center|Reviews cannot be done during the submission phase]]

=====Final UI=====
[[File:after1.png|700px|thumb|center|Reviews cannot be done during the submission phase]]

=====Implementation=====
*change the conditions for submission, which means the second round of assignment cannot be submitted without revision_plan being subbmited first
app/views/student_task/view.html.erb
before
<% if @assignment.submission_allowed(@topic_id) %>
after
<% if (!@can_submit_revision_plan && @assignment.submission_allowed(@topic_id)) ||
(@can_submit_revision_plan && @revision_plan_questionnaire_id && @assignment.submission_allowed(@topic_id)) %>

=Test Plan=

====RSpec Testing====
The RSpec tests are written to test both controller and models.

Controllers

*rspec spec/controllers/grades_controller_spec.rb
*rspec spec/controllers/questionnaires_controller_spec.rb
*rspec spec/controllers/questions_controller_spec.rb
*rspec spec/controllers/student_teams_controller_spec.rb
*spec/controllers/response_controller_spec.rb: Updated spec by stubbing get_questions method to pass.
*spec/controllers/revision_plan_questionnaires_controller_spec.rb: Updated spec by adding four examples to test revision plan questionnaires controller
*spec/factories/revision_plan_factory.rb: Create a new factory.rb to create objects unique to revision plans, including RevisionPlanQuestionnaire RevisionPlanTeamMap

Models

*spec/models/response_spec.rb: Updated spec by updating expected html output to pass.
*spec/models/review_response_map_spec.rb: Updated spec by updating expected html output to pass.

Helpers

*rspec spec/heplers/grades_helper.rb

====Manual Testing====
Manual testing aims to verify the following:

*Can an assignment with revision planning enabled be created?
*Can an assignment with 2 rounds of review be set up?
*If the revision-planning rubric can be edited or not?
*Is the revision plan a separate section?
*Does the method determining the members of a team existed in team.rb?
*Dose the system have redundant functions?
*Are participants allowed to create/edit revision plan when round 1+ (1 or greater than 1) reviews have finished?
*Is revision plan editing disabled when assignment is in review stage?
*Are reviewers shown questions created by reviewees?
*Does participants show summary of score for revision plan after review deadline has expired?

Since we are still working on our project, the following is part of our UI testing.

1. Go to the overview page of the assignment, the revision planning should only be available at 1st review phase.
[[File:E2152_Revision_Plan_avaliable.png|1000px|center]]
[[File:E2152_Revision_Plan_unavaliable.png|1000px|center]]

==Team Members==
Kai Gao (kgao2@ncsu.edu)
 
Huangxing Chen (hchen63)
 
Yi Li (yli273)
 
Shengjie Guo (sguo25)
 
'''Mentor:''' Nicholas Himes (nnhimes@ncsu.edu)

==References==

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-06T21:56:29Z

Yli273: /* Implementation */

This page provides a description of the Expertiza based OSS project.

__TOC__
==Introduction==
Rounds of peer reviews may be implemented between submissions for assignments on Expertiza. In order to better track the implementation of reviewer's suggestions, a Revision Planning Tool should be implemented.

===Problem Statement===
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then the second round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

[[File:E2152_Problem_Statement.png|400px|center]]

===Previous Implementations===
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

Revision planning has been implemented three times before, once in [https://expertiza.csc.ncsu.edu/index.php/E1875_Revision_Planning_Tool E1875], once in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_E2016_Revision_planning_tool E2016] and another one in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2020_-_E2083._Revision_planning_tool_E2016 E2083]. While the functionality worked and effectively minimized changes to the code, they also had the following problems:
*Hardcoded “round” numbers in many places of the code.
*Documentation does not reflect the new changes they made.
*Revision planning responses and responses to the other items are not distinguished in heatgrid view.
*The idea of adding a <code>team_id</code> field to each question is intuitive. However, they failed to come up with a clean implementation of this idea. Specifically, they had passed some trailing parameters several methods down before reaching the place that needs them.

===Problems with Previous Implementation===
Students cannot edit the revision plan in the review phase so the review doesn't get changed while other students are reviewing. However, it assumes that reviews cannot be done during the submission phase. Code needs to be written to take care of this part.
Set up an assignment with 2 rounds of review.
Allow editing the revision-planning rubric just like editing a normal rubric, using a shared template
.Instructors and students can view the review report with the revision plan placed in a separate section.
In RevisionPlanQuestionnairesController, the method for determining who's on a team would be better located in team.rb.
The current_round method duplicates a method elsewhere in the system.
The generate_heatgrid has too many conditional statements. It would be better to split it into smaller methods.
A lot of code deals with score calculations, which shouldn't be a concern for this project.
Too many files are involved, although they seem to make reasonable decisions about their changes.
The code should have more comments.
The team had a good initial design but took as twice much as LoC compared to the previous teams.

===Goals===
*Let the authors be able to edit the revision plan during the review phase.
*Set up an assignment with 2 rounds of review.
*Allow editing the revision-planning rubric just like editing a normal rubric, using a shared template.
*Instructors and students can view the review report with the revision plan placed in a separate section.
*Relocate the method for determining who's on a team in RevisionPlanQuestionnairesController to team.rb.
*Delete the duplicated current_round method.
*Split the conditional statements of generate_heatgrid into smaller subclass methods.

===Rationale===
The general workflow is shown bellow.

[[File:E2152_Rationale.png|400px|center]]

=Proposed Solution=

===Implementation===

*1. Enable Revision Planning during the review phase
Let the author make a choice to decide whether to enable revision planning during the review phase. In order to enable Revision Planning, the setting must be enabled when creating or editing an assignment under the General tab. The wireframe below demonstrates creating an assignment, and editing the assignment functions similarly. Revision plan check box should be checked to enable this option.

[[File:Revision_Planning_Link.png|600px|thumb|center|Submit or Review Work page demonstrating added Revision Planning link]]

*2. Set up assignments
Set up assignment with 2 rounds of review. The Revision Planning link is available to students during every submission period (except the first round submission) and not available during every review period. As shown in the wireframe, by clicking Revision Planning students would be redirected to the ‘Revision planning page’.

In order to check if a team is allowed to submit a revision plan @can_submit_revision_plan field is added to StudentTaskController's view action. If a revision plan questionnaire (@revision_plan_questionnaire_id) exists for the current round then clicking the link performs RevisionPlanQuestionnairesController's edit action else new action is performed.

[[File:Create_New_Assignment.png|700px|thumb|center|Create New Assignment page in the UI, with added Revision Planning checkbox]]

*3. Revision-planning rubric
Allow editing the revision-planning rubric just like editing a normal rubric, using a shared template. After creating the Revision Plan Questionnaire, it must be edited. Questions can be added by specifying the amount of questions and their type. Questions can be removed by clicking Remove in the leftmost column. Once the questionnaire is complete, it can be saved. This page will be visible during each submission period after the first and will be unavailable during all review periods.

[[File:Edit_Revision_Plan.png|700px|thumb|center|Edit Revision Plan page demonstrating added view]]
[[File:Review_Wireframe.png|400px|thumb|center|Wireframe of Completing a Review for an Assignment]]
[[File:Revision_Plan_Questionnaire.png|400px|thumb|center|Review page demonstrating added Revision Plan questions]]

*4. Report Summary
Instructors and students can view the review report with the revision plan placed in a separate section. When a project has been reviewed at least once, a participant is able to view their team's score. The UI below shows what this looks like after the second round of reviews. For the second and all subsequent reviews, the results of questions that were created by the instructor are shown under Assignment Questionnaire. The results of the questions created by the team are shown under Improvement Plan.

[[File:Summary_Report.png|600px|thumb|center|Summary Report page demonstrating added Revision Plan heatgrid]]

*5. Code Optimization
*Relocate the method for determining who's on a team in RevisionPlanQuestionnairesController to team.rb.
*Delete the duplicated current_round method.
*Split the conditional statements of generate_heatgrid into smaller subclass methods.

===Files Modified===

==Design==
===Database Design===
Items in green are additions.
[[File:E2152_Design.png|1000px|center]]
 
Changes:
*In the assignment table we have added <code>is_revision_planning_enabled?</code> column to indicate whether the assignment accepts a revision plan along with review rubric.
*<code>RevisionPlanTeamMap</code> maps a questionnaire to an assignment team and round. This will map to a questionnaire of type revision plan that will be created by the revewee.
*<code>RevisionPlanQuestionnaire</code> extends <code>Questionnaire</code> using single table inheritance.

===User Interface===
====Enable Revision Planning====
In order to enable '''Revision Planning''', the setting must be enabled when creating or editing an assignment under the '''General''' tab. The wireframe below demonstrates creating an assignment, and editing the assignment functions similarly. '''Revision plan?''' should be checked to enable this option.
=====Initial Wireframe=====
[[File:Enable_Revision_Planning_Wireframe.png|700px|thumb|center|Wireframe of Enabling Assignment's Revision Planning]]
=====Final UI=====

=====Implementation=====

====Editing the Revision Plan Questionnaire====

=====Initial Wireframe=====

=====Final UI=====

=====Implementation=====

====Reviewing an Assignment====

=====Initial Wireframe=====

=====Final UI=====

=====Implementation=====

====Summary Report Page====

=====Initial Wireframe=====

=====Final UI=====

=====Implementation=====

=Test Plan=
*There should be 2 rounds of reviews. And reviews should only be available at the review phase, not at the submission phase. Also, students should not be able to edit the revision plan during the review phase.
*The revision-planning rubric can be edited.
*The revision plan will be placed in a separate section.
*The method for determining who's on a team would be located in team.rb.
*Delete the redundant functions and test the system's integrity.
*Break down the long functions into small functions and reduce conditional cases, then test the system's integrity.
*Reduce the score calculation and test the system's integrity.
====RSpec Testing====

====Manual Testing====

==Team Members==
Kai Gao (kgao2@ncsu.edu)
 
Huangxing Chen (hchen63)
 
Yi Li (yli273)
 
Shengjie Guo (sguo25)
 
'''Mentor:''' Nicholas Himes (nnhimes@ncsu.edu)

==References==

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-06T21:55:59Z

Yli273: /* Implementation */

This page provides a description of the Expertiza based OSS project.

__TOC__
==Introduction==
Rounds of peer reviews may be implemented between submissions for assignments on Expertiza. In order to better track the implementation of reviewer's suggestions, a Revision Planning Tool should be implemented.

===Problem Statement===
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then the second round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

[[File:E2152_Problem_Statement.png|400px|center]]

===Previous Implementations===
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

Revision planning has been implemented three times before, once in [https://expertiza.csc.ncsu.edu/index.php/E1875_Revision_Planning_Tool E1875], once in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_E2016_Revision_planning_tool E2016] and another one in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2020_-_E2083._Revision_planning_tool_E2016 E2083]. While the functionality worked and effectively minimized changes to the code, they also had the following problems:
*Hardcoded “round” numbers in many places of the code.
*Documentation does not reflect the new changes they made.
*Revision planning responses and responses to the other items are not distinguished in heatgrid view.
*The idea of adding a <code>team_id</code> field to each question is intuitive. However, they failed to come up with a clean implementation of this idea. Specifically, they had passed some trailing parameters several methods down before reaching the place that needs them.

===Problems with Previous Implementation===
Students cannot edit the revision plan in the review phase so the review doesn't get changed while other students are reviewing. However, it assumes that reviews cannot be done during the submission phase. Code needs to be written to take care of this part.
Set up an assignment with 2 rounds of review.
Allow editing the revision-planning rubric just like editing a normal rubric, using a shared template
.Instructors and students can view the review report with the revision plan placed in a separate section.
In RevisionPlanQuestionnairesController, the method for determining who's on a team would be better located in team.rb.
The current_round method duplicates a method elsewhere in the system.
The generate_heatgrid has too many conditional statements. It would be better to split it into smaller methods.
A lot of code deals with score calculations, which shouldn't be a concern for this project.
Too many files are involved, although they seem to make reasonable decisions about their changes.
The code should have more comments.
The team had a good initial design but took as twice much as LoC compared to the previous teams.

===Goals===
*Let the authors be able to edit the revision plan during the review phase.
*Set up an assignment with 2 rounds of review.
*Allow editing the revision-planning rubric just like editing a normal rubric, using a shared template.
*Instructors and students can view the review report with the revision plan placed in a separate section.
*Relocate the method for determining who's on a team in RevisionPlanQuestionnairesController to team.rb.
*Delete the duplicated current_round method.
*Split the conditional statements of generate_heatgrid into smaller subclass methods.

===Rationale===
The general workflow is shown bellow.

[[File:E2152_Rationale.png|400px|center]]

=Proposed Solution=

===Implementation===

*1. Enable Revision Planning during the review phase
Let the author make a choice to decide whether to enable revision planning during the review phase. In order to enable Revision Planning, the setting must be enabled when creating or editing an assignment under the General tab. The wireframe below demonstrates creating an assignment, and editing the assignment functions similarly. Revision plan check box should be checked to enable this option.

[[File:Revision_Planning_Link.png|600px|thumb|center|Submit or Review Work page demonstrating added Revision Planning link]]

*2. Set up assignments
Set up assignment with 2 rounds of review. The Revision Planning link is available to students during every submission period (except the first round submission) and not available during every review period. As shown in the wireframe, by clicking Revision Planning students would be redirected to the ‘Revision planning page’.

In order to check if a team is allowed to submit a revision plan @can_submit_revision_plan field is added to StudentTaskController's view action. If a revision plan questionnaire (@revision_plan_questionnaire_id) exists for the current round then clicking the link performs RevisionPlanQuestionnairesController's edit action else new action is performed.

[[File:Create_New_Assignment.png|700px|thumb|center|Create New Assignment page in the UI, with added Revision Planning checkbox]]

*3. Revision-planning rubric
Allow editing the revision-planning rubric just like editing a normal rubric, using a shared template. After creating the Revision Plan Questionnaire, it must be edited. Questions can be added by specifying the amount of questions and their type. Questions can be removed by clicking Remove in the leftmost column. Once the questionnaire is complete, it can be saved. This page will be visible during each submission period after the first and will be unavailable during all review periods.

[[File:Edit_Revision_Plan.png|700px|thumb|center|Edit Revision Plan page demonstrating added view]]
[[File:Review_Wireframe.png|400px|thumb|center|Wireframe of Completing a Review for an Assignment]]
[[File:Revision_Plan_Questionnaire.png|400px|thumb|center|Review page demonstrating added Revision Plan questions]]

*4. Report Summary
Instructors and students can view the review report with the revision plan placed in a separate section. When a project has been reviewed at least once, a participant is able to view their team's score. The UI below shows what this looks like after the second round of reviews. For the second and all subsequent reviews, the results of questions that were created by the instructor are shown under Assignment Questionnaire. The results of the questions created by the team are shown under Improvement Plan.

[[File:Summary_Report.png|600px|thumb|center|Summary Report page demonstrating added Revision Plan heatgrid]]

*5. Code Optimization
Relocate the method for determining who's on a team in RevisionPlanQuestionnairesController to team.rb.
Delete the duplicated current_round method.
Split the conditional statements of generate_heatgrid into smaller subclass methods.

===Files Modified===

==Design==
===Database Design===
Items in green are additions.
[[File:E2152_Design.png|1000px|center]]
 
Changes:
*In the assignment table we have added <code>is_revision_planning_enabled?</code> column to indicate whether the assignment accepts a revision plan along with review rubric.
*<code>RevisionPlanTeamMap</code> maps a questionnaire to an assignment team and round. This will map to a questionnaire of type revision plan that will be created by the revewee.
*<code>RevisionPlanQuestionnaire</code> extends <code>Questionnaire</code> using single table inheritance.

===User Interface===
====Enable Revision Planning====

=====Initial Wireframe=====

=====Final UI=====

=====Implementation=====

====Editing the Revision Plan Questionnaire====

=====Initial Wireframe=====

=====Final UI=====

=====Implementation=====

====Reviewing an Assignment====

=====Initial Wireframe=====

=====Final UI=====

=====Implementation=====

====Summary Report Page====

=====Initial Wireframe=====

=====Final UI=====

=====Implementation=====

=Test Plan=
*There should be 2 rounds of reviews. And reviews should only be available at the review phase, not at the submission phase. Also, students should not be able to edit the revision plan during the review phase.
*The revision-planning rubric can be edited.
*The revision plan will be placed in a separate section.
*The method for determining who's on a team would be located in team.rb.
*Delete the redundant functions and test the system's integrity.
*Break down the long functions into small functions and reduce conditional cases, then test the system's integrity.
*Reduce the score calculation and test the system's integrity.
====RSpec Testing====

====Manual Testing====

==Team Members==
Kai Gao (kgao2@ncsu.edu)
 
Huangxing Chen (hchen63)
 
Yi Li (yli273)
 
Shengjie Guo (sguo25)
 
'''Mentor:''' Nicholas Himes (nnhimes@ncsu.edu)

==References==

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-06T21:53:43Z

Yli273: /* Implementation */

This page provides a description of the Expertiza based OSS project.

__TOC__
==Introduction==
Rounds of peer reviews may be implemented between submissions for assignments on Expertiza. In order to better track the implementation of reviewer's suggestions, a Revision Planning Tool should be implemented.

===Problem Statement===
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then the second round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

[[File:E2152_Problem_Statement.png|400px|center]]

===Previous Implementations===
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

Revision planning has been implemented three times before, once in [https://expertiza.csc.ncsu.edu/index.php/E1875_Revision_Planning_Tool E1875], once in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_E2016_Revision_planning_tool E2016] and another one in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2020_-_E2083._Revision_planning_tool_E2016 E2083]. While the functionality worked and effectively minimized changes to the code, they also had the following problems:
*Hardcoded “round” numbers in many places of the code.
*Documentation does not reflect the new changes they made.
*Revision planning responses and responses to the other items are not distinguished in heatgrid view.
*The idea of adding a <code>team_id</code> field to each question is intuitive. However, they failed to come up with a clean implementation of this idea. Specifically, they had passed some trailing parameters several methods down before reaching the place that needs them.

===Problems with Previous Implementation===
Students cannot edit the revision plan in the review phase so the review doesn't get changed while other students are reviewing. However, it assumes that reviews cannot be done during the submission phase. Code needs to be written to take care of this part.
Set up an assignment with 2 rounds of review.
Allow editing the revision-planning rubric just like editing a normal rubric, using a shared template
.Instructors and students can view the review report with the revision plan placed in a separate section.
In RevisionPlanQuestionnairesController, the method for determining who's on a team would be better located in team.rb.
The current_round method duplicates a method elsewhere in the system.
The generate_heatgrid has too many conditional statements. It would be better to split it into smaller methods.
A lot of code deals with score calculations, which shouldn't be a concern for this project.
Too many files are involved, although they seem to make reasonable decisions about their changes.
The code should have more comments.
The team had a good initial design but took as twice much as LoC compared to the previous teams.

===Goals===
*Let the authors be able to edit the revision plan during the review phase.
*Set up an assignment with 2 rounds of review.
*Allow editing the revision-planning rubric just like editing a normal rubric, using a shared template.
*Instructors and students can view the review report with the revision plan placed in a separate section.
*Relocate the method for determining who's on a team in RevisionPlanQuestionnairesController to team.rb.
*Delete the duplicated current_round method.
*Split the conditional statements of generate_heatgrid into smaller subclass methods.

===Rationale===
The general workflow is shown bellow.

[[File:E2152_Rationale.png|400px|center]]

=Proposed Solution=

===Implementation===

*1. Enable Revision Planning during the review phase
Let the author make a choice to decide whether to enable revision planning during the review phase. In order to enable Revision Planning, the setting must be enabled when creating or editing an assignment under the General tab. The wireframe below demonstrates creating an assignment, and editing the assignment functions similarly. Revision plan check box should be checked to enable this option.

[[File:Revision_Planning_Link.png|600px|thumb|center|Submit or Review Work page demonstrating added Revision Planning link]]

*2. Set up assignments
Set up assignment with 2 rounds of review. The Revision Planning link is available to students during every submission period (except the first round submission) and not available during every review period. As shown in the wireframe, by clicking Revision Planning students would be redirected to the ‘Revision planning page’.

In order to check if a team is allowed to submit a revision plan @can_submit_revision_plan field is added to StudentTaskController's view action. If a revision plan questionnaire (@revision_plan_questionnaire_id) exists for the current round then clicking the link performs RevisionPlanQuestionnairesController's edit action else new action is performed.

[[File:Create_New_Assignment.png|700px|thumb|center|Create New Assignment page in the UI, with added Revision Planning checkbox]]

*3. Revision-planning rubric
Allow editing the revision-planning rubric just like editing a normal rubric, using a shared template.

*4. Instructors and students can view the review report with the revision plan placed in a separate section.

*5. Code Optimization
Relocate the method for determining who's on a team in RevisionPlanQuestionnairesController to team.rb.
Delete the duplicated current_round method.
Split the conditional statements of generate_heatgrid into smaller subclass methods.

===Files Modified===

==Design==
===Database Design===
Items in green are additions.
[[File:E2152_Design.png|1000px|center]]
 
Changes:
*In the assignment table we have added <code>is_revision_planning_enabled?</code> column to indicate whether the assignment accepts a revision plan along with review rubric.
*<code>RevisionPlanTeamMap</code> maps a questionnaire to an assignment team and round. This will map to a questionnaire of type revision plan that will be created by the revewee.
*<code>RevisionPlanQuestionnaire</code> extends <code>Questionnaire</code> using single table inheritance.

===User Interface===
====Enable Revision Planning====

=====Initial Wireframe=====

=====Final UI=====

=====Implementation=====

====Editing the Revision Plan Questionnaire====

=====Initial Wireframe=====

=====Final UI=====

=====Implementation=====

====Reviewing an Assignment====

=====Initial Wireframe=====

=====Final UI=====

=====Implementation=====

====Summary Report Page====

=====Initial Wireframe=====

=====Final UI=====

=====Implementation=====

=Test Plan=
*There should be 2 rounds of reviews. And reviews should only be available at the review phase, not at the submission phase. Also, students should not be able to edit the revision plan during the review phase.
*The revision-planning rubric can be edited.
*The revision plan will be placed in a separate section.
*The method for determining who's on a team would be located in team.rb.
*Delete the redundant functions and test the system's integrity.
*Break down the long functions into small functions and reduce conditional cases, then test the system's integrity.
*Reduce the score calculation and test the system's integrity.
====RSpec Testing====

====Manual Testing====

==Team Members==
Kai Gao (kgao2@ncsu.edu)
 
Huangxing Chen (hchen63)
 
Yi Li (yli273)
 
Shengjie Guo (sguo25)
 
'''Mentor:''' Nicholas Himes (nnhimes@ncsu.edu)

==References==

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-06T21:48:33Z

Yli273: /* Implementation */

This page provides a description of the Expertiza based OSS project.

__TOC__
==Introduction==
Rounds of peer reviews may be implemented between submissions for assignments on Expertiza. In order to better track the implementation of reviewer's suggestions, a Revision Planning Tool should be implemented.

===Problem Statement===
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then the second round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

[[File:E2152_Problem_Statement.png|400px|center]]

===Previous Implementations===
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

Revision planning has been implemented three times before, once in [https://expertiza.csc.ncsu.edu/index.php/E1875_Revision_Planning_Tool E1875], once in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_E2016_Revision_planning_tool E2016] and another one in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2020_-_E2083._Revision_planning_tool_E2016 E2083]. While the functionality worked and effectively minimized changes to the code, they also had the following problems:
*Hardcoded “round” numbers in many places of the code.
*Documentation does not reflect the new changes they made.
*Revision planning responses and responses to the other items are not distinguished in heatgrid view.
*The idea of adding a <code>team_id</code> field to each question is intuitive. However, they failed to come up with a clean implementation of this idea. Specifically, they had passed some trailing parameters several methods down before reaching the place that needs them.

===Problems with Previous Implementation===
Students cannot edit the revision plan in the review phase so the review doesn't get changed while other students are reviewing. However, it assumes that reviews cannot be done during the submission phase. Code needs to be written to take care of this part.
Set up an assignment with 2 rounds of review.
Allow editing the revision-planning rubric just like editing a normal rubric, using a shared template
.Instructors and students can view the review report with the revision plan placed in a separate section.
In RevisionPlanQuestionnairesController, the method for determining who's on a team would be better located in team.rb.
The current_round method duplicates a method elsewhere in the system.
The generate_heatgrid has too many conditional statements. It would be better to split it into smaller methods.
A lot of code deals with score calculations, which shouldn't be a concern for this project.
Too many files are involved, although they seem to make reasonable decisions about their changes.
The code should have more comments.
The team had a good initial design but took as twice much as LoC compared to the previous teams.

===Goals===
*Let the authors be able to edit the revision plan during the review phase.
*Set up an assignment with 2 rounds of review.
*Allow editing the revision-planning rubric just like editing a normal rubric, using a shared template.
*Instructors and students can view the review report with the revision plan placed in a separate section.
*Relocate the method for determining who's on a team in RevisionPlanQuestionnairesController to team.rb.
*Delete the duplicated current_round method.
*Split the conditional statements of generate_heatgrid into smaller subclass methods.

===Rationale===
The general workflow is shown bellow.

[[File:E2152_Rationale.png|400px|center]]

=Proposed Solution=

===Implementation===

*1. Enable Revision Planning during the review phase
Let the author make a choice to decide whether to enable revision planning during the review phase. In order to enable Revision Planning, the setting must be enabled when creating or editing an assignment under the General tab. The wireframe below demonstrates creating an assignment, and editing the assignment functions similarly. Revision plan check box should be checked to enable this option.

[[File:Create_New_Assignment.png|700px|thumb|center|Create New Assignment page in the UI, with added Revision Planning checkbox]]

*2. Set up assignments
Set up assignment with 2 rounds of review. The Revision Planning link is available to students during every submission period (except the first round submission) and not available during every review period. As shown in the wireframe, by clicking Revision Planning students would be redirected to the ‘Revision planning page’.

In order to check if a team is allowed to submit a revision plan @can_submit_revision_plan field is added to StudentTaskController's view action. If a revision plan questionnaire (@revision_plan_questionnaire_id) exists for the current round then clicking the link performs RevisionPlanQuestionnairesController's edit action else new action is performed.

[[File:Revision_Planning_Link.png|600px|thumb|center|Submit or Review Work page demonstrating added Revision Planning link]]

*3. Allow editing the revision-planning rubric just like editing a normal rubric, using a shared template.

*4. Instructors and students can view the review report with the revision plan placed in a separate section.

*5. Relocate the method for determining who's on a team in RevisionPlanQuestionnairesController to team.rb.

*6. Delete the duplicated current_round method.

*7. Split the conditional statements of generate_heatgrid into smaller subclass methods.

===Files Modified===

==Design==
===Database Design===
Items in green are additions.
[[File:E2152_Design.png|1000px|center]]
 
Changes:
*In the assignment table we have added <code>is_revision_planning_enabled?</code> column to indicate whether the assignment accepts a revision plan along with review rubric.
*<code>RevisionPlanTeamMap</code> maps a questionnaire to an assignment team and round. This will map to a questionnaire of type revision plan that will be created by the revewee.
*<code>RevisionPlanQuestionnaire</code> extends <code>Questionnaire</code> using single table inheritance.

===User Interface===
====Enable Revision Planning====

=====Initial Wireframe=====

=====Final UI=====

=====Implementation=====

====Editing the Revision Plan Questionnaire====

=====Initial Wireframe=====

=====Final UI=====

=====Implementation=====

====Reviewing an Assignment====

=====Initial Wireframe=====

=====Final UI=====

=====Implementation=====

====Summary Report Page====

=====Initial Wireframe=====

=====Final UI=====

=====Implementation=====

=Test Plan=
*There should be 2 rounds of reviews. And reviews should only be available at the review phase, not at the submission phase. Also, students should not be able to edit the revision plan during the review phase.
*The revision-planning rubric can be edited.
*The revision plan will be placed in a separate section.
*The method for determining who's on a team would be located in team.rb.
*Delete the redundant functions and test the system's integrity.
*Break down the long functions into small functions and reduce conditional cases, then test the system's integrity.
*Reduce the score calculation and test the system's integrity.
====RSpec Testing====

====Manual Testing====

==Team Members==
Kai Gao (kgao2@ncsu.edu)
 
Huangxing Chen (hchen63)
 
Yi Li (yli273)
 
Shengjie Guo (sguo25)
 
'''Mentor:''' Nicholas Himes (nnhimes@ncsu.edu)

==References==

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-06T21:48:05Z

Yli273: /* Implementation */

This page provides a description of the Expertiza based OSS project.

__TOC__
==Introduction==
Rounds of peer reviews may be implemented between submissions for assignments on Expertiza. In order to better track the implementation of reviewer's suggestions, a Revision Planning Tool should be implemented.

===Problem Statement===
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then the second round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

[[File:E2152_Problem_Statement.png|400px|center]]

===Previous Implementations===
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

Revision planning has been implemented three times before, once in [https://expertiza.csc.ncsu.edu/index.php/E1875_Revision_Planning_Tool E1875], once in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_E2016_Revision_planning_tool E2016] and another one in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2020_-_E2083._Revision_planning_tool_E2016 E2083]. While the functionality worked and effectively minimized changes to the code, they also had the following problems:
*Hardcoded “round” numbers in many places of the code.
*Documentation does not reflect the new changes they made.
*Revision planning responses and responses to the other items are not distinguished in heatgrid view.
*The idea of adding a <code>team_id</code> field to each question is intuitive. However, they failed to come up with a clean implementation of this idea. Specifically, they had passed some trailing parameters several methods down before reaching the place that needs them.

===Problems with Previous Implementation===
Students cannot edit the revision plan in the review phase so the review doesn't get changed while other students are reviewing. However, it assumes that reviews cannot be done during the submission phase. Code needs to be written to take care of this part.
Set up an assignment with 2 rounds of review.
Allow editing the revision-planning rubric just like editing a normal rubric, using a shared template
.Instructors and students can view the review report with the revision plan placed in a separate section.
In RevisionPlanQuestionnairesController, the method for determining who's on a team would be better located in team.rb.
The current_round method duplicates a method elsewhere in the system.
The generate_heatgrid has too many conditional statements. It would be better to split it into smaller methods.
A lot of code deals with score calculations, which shouldn't be a concern for this project.
Too many files are involved, although they seem to make reasonable decisions about their changes.
The code should have more comments.
The team had a good initial design but took as twice much as LoC compared to the previous teams.

===Goals===
*Let the authors be able to edit the revision plan during the review phase.
*Set up an assignment with 2 rounds of review.
*Allow editing the revision-planning rubric just like editing a normal rubric, using a shared template.
*Instructors and students can view the review report with the revision plan placed in a separate section.
*Relocate the method for determining who's on a team in RevisionPlanQuestionnairesController to team.rb.
*Delete the duplicated current_round method.
*Split the conditional statements of generate_heatgrid into smaller subclass methods.

===Rationale===
The general workflow is shown bellow.

[[File:E2152_Rationale.png|400px|center]]

=Proposed Solution=

===Implementation===

*1. Enable Revision Planning during the review phase
Let the author make a choice to decide whether to enable revision planning during the review phase. In order to enable Revision Planning, the setting must be enabled when creating or editing an assignment under the General tab. The wireframe below demonstrates creating an assignment, and editing the assignment functions similarly. Revision plan check box should be checked to enable this option.

[[File:Create_New_Assignment.png|700px|thumb|center|Create New Assignment page in the UI, with added Revision Planning checkbox]]

*2. Set up assignment with 2 rounds of review
The Revision Planning link is available to students during every submission period (except the first round submission) and not available during every review period. As shown in the wireframe, by clicking Revision Planning students would be redirected to the ‘Revision planning page’.

In order to check if a team is allowed to submit a revision plan @can_submit_revision_plan field is added to StudentTaskController's view action. If a revision plan questionnaire (@revision_plan_questionnaire_id) exists for the current round then clicking the link performs RevisionPlanQuestionnairesController's edit action else new action is performed.

[[File:Revision_Planning_Link.png|600px|thumb|center|Submit or Review Work page demonstrating added Revision Planning link]]

*3. Allow editing the revision-planning rubric just like editing a normal rubric, using a shared template.

*4. Instructors and students can view the review report with the revision plan placed in a separate section.

*5. Relocate the method for determining who's on a team in RevisionPlanQuestionnairesController to team.rb.

*6. Delete the duplicated current_round method.

*7. Split the conditional statements of generate_heatgrid into smaller subclass methods.

===Files Modified===

==Design==
===Database Design===
Items in green are additions.
[[File:E2152_Design.png|1000px|center]]
 
Changes:
*In the assignment table we have added <code>is_revision_planning_enabled?</code> column to indicate whether the assignment accepts a revision plan along with review rubric.
*<code>RevisionPlanTeamMap</code> maps a questionnaire to an assignment team and round. This will map to a questionnaire of type revision plan that will be created by the revewee.
*<code>RevisionPlanQuestionnaire</code> extends <code>Questionnaire</code> using single table inheritance.

===User Interface===
====Enable Revision Planning====

=====Initial Wireframe=====

=====Final UI=====

=====Implementation=====

====Editing the Revision Plan Questionnaire====

=====Initial Wireframe=====

=====Final UI=====

=====Implementation=====

====Reviewing an Assignment====

=====Initial Wireframe=====

=====Final UI=====

=====Implementation=====

====Summary Report Page====

=====Initial Wireframe=====

=====Final UI=====

=====Implementation=====

=Test Plan=
*There should be 2 rounds of reviews. And reviews should only be available at the review phase, not at the submission phase. Also, students should not be able to edit the revision plan during the review phase.
*The revision-planning rubric can be edited.
*The revision plan will be placed in a separate section.
*The method for determining who's on a team would be located in team.rb.
*Delete the redundant functions and test the system's integrity.
*Break down the long functions into small functions and reduce conditional cases, then test the system's integrity.
*Reduce the score calculation and test the system's integrity.
====RSpec Testing====

====Manual Testing====

==Team Members==
Kai Gao (kgao2@ncsu.edu)
 
Huangxing Chen (hchen63)
 
Yi Li (yli273)
 
Shengjie Guo (sguo25)
 
'''Mentor:''' Nicholas Himes (nnhimes@ncsu.edu)

==References==

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-06T21:46:14Z

Yli273: /* Proposed Solution */

This page provides a description of the Expertiza based OSS project.

__TOC__
==Introduction==
Rounds of peer reviews may be implemented between submissions for assignments on Expertiza. In order to better track the implementation of reviewer's suggestions, a Revision Planning Tool should be implemented.

===Problem Statement===
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then the second round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

[[File:E2152_Problem_Statement.png|400px|center]]

===Previous Implementations===
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

Revision planning has been implemented three times before, once in [https://expertiza.csc.ncsu.edu/index.php/E1875_Revision_Planning_Tool E1875], once in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_E2016_Revision_planning_tool E2016] and another one in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2020_-_E2083._Revision_planning_tool_E2016 E2083]. While the functionality worked and effectively minimized changes to the code, they also had the following problems:
*Hardcoded “round” numbers in many places of the code.
*Documentation does not reflect the new changes they made.
*Revision planning responses and responses to the other items are not distinguished in heatgrid view.
*The idea of adding a <code>team_id</code> field to each question is intuitive. However, they failed to come up with a clean implementation of this idea. Specifically, they had passed some trailing parameters several methods down before reaching the place that needs them.

===Problems with Previous Implementation===
Students cannot edit the revision plan in the review phase so the review doesn't get changed while other students are reviewing. However, it assumes that reviews cannot be done during the submission phase. Code needs to be written to take care of this part.
Set up an assignment with 2 rounds of review.
Allow editing the revision-planning rubric just like editing a normal rubric, using a shared template
.Instructors and students can view the review report with the revision plan placed in a separate section.
In RevisionPlanQuestionnairesController, the method for determining who's on a team would be better located in team.rb.
The current_round method duplicates a method elsewhere in the system.
The generate_heatgrid has too many conditional statements. It would be better to split it into smaller methods.
A lot of code deals with score calculations, which shouldn't be a concern for this project.
Too many files are involved, although they seem to make reasonable decisions about their changes.
The code should have more comments.
The team had a good initial design but took as twice much as LoC compared to the previous teams.

===Goals===
*Let the authors be able to edit the revision plan during the review phase.
*Set up an assignment with 2 rounds of review.
*Allow editing the revision-planning rubric just like editing a normal rubric, using a shared template.
*Instructors and students can view the review report with the revision plan placed in a separate section.
*Relocate the method for determining who's on a team in RevisionPlanQuestionnairesController to team.rb.
*Delete the duplicated current_round method.
*Split the conditional statements of generate_heatgrid into smaller subclass methods.

===Rationale===
The general workflow is shown bellow.

[[File:E2152_Rationale.png|400px|center]]

=Proposed Solution=

===Implementation===

*1. Enable Revision Planning during the review phase.
Let the author make a choice to decide whether to enable revision planning during the review phase. In order to enable Revision Planning, the setting must be enabled when creating or editing an assignment under the General tab. The wireframe below demonstrates creating an assignment, and editing the assignment functions similarly. Revision plan check box should be checked to enable this option.

[[File:Create_New_Assignment.png|700px|thumb|center|Create New Assignment page in the UI, with added Revision Planning checkbox]]

*2. Set up assignment with 2 rounds of review.
The Revision Planning link is available to students during every submission period (except the first round submission) and not available during every review period. As shown in the wireframe, by clicking Revision Planning students would be redirected to the ‘Revision planning page’.

In order to check if a team is allowed to submit a revision plan @can_submit_revision_plan field is added to StudentTaskController's view action. If a revision plan questionnaire (@revision_plan_questionnaire_id) exists for the current round then clicking the link performs RevisionPlanQuestionnairesController's edit action else new action is performed.

[[File:Revision_Planning_Link.png|600px|thumb|center|Submit or Review Work page demonstrating added Revision Planning link]]

*3. Allow editing the revision-planning rubric just like editing a normal rubric, using a shared template.

*4. Instructors and students can view the review report with the revision plan placed in a separate section.

*5. Relocate the method for determining who's on a team in RevisionPlanQuestionnairesController to team.rb.

*6. Delete the duplicated current_round method.

*7. Split the conditional statements of generate_heatgrid into smaller subclass methods.

===Files Modified===

==Design==
===Database Design===
Items in green are additions.
[[File:E2152_Design.png|1000px|center]]
 
Changes:
*In the assignment table we have added <code>is_revision_planning_enabled?</code> column to indicate whether the assignment accepts a revision plan along with review rubric.
*<code>RevisionPlanTeamMap</code> maps a questionnaire to an assignment team and round. This will map to a questionnaire of type revision plan that will be created by the revewee.
*<code>RevisionPlanQuestionnaire</code> extends <code>Questionnaire</code> using single table inheritance.

===User Interface===
====Enable Revision Planning====

=====Initial Wireframe=====

=====Final UI=====

=====Implementation=====

====Editing the Revision Plan Questionnaire====

=====Initial Wireframe=====

=====Final UI=====

=====Implementation=====

====Reviewing an Assignment====

=====Initial Wireframe=====

=====Final UI=====

=====Implementation=====

====Summary Report Page====

=====Initial Wireframe=====

=====Final UI=====

=====Implementation=====

=Test Plan=
*There should be 2 rounds of reviews. And reviews should only be available at the review phase, not at the submission phase. Also, students should not be able to edit the revision plan during the review phase.
*The revision-planning rubric can be edited.
*The revision plan will be placed in a separate section.
*The method for determining who's on a team would be located in team.rb.
*Delete the redundant functions and test the system's integrity.
*Break down the long functions into small functions and reduce conditional cases, then test the system's integrity.
*Reduce the score calculation and test the system's integrity.
====RSpec Testing====

====Manual Testing====

==Team Members==
Kai Gao (kgao2@ncsu.edu)
 
Huangxing Chen (hchen63)
 
Yi Li (yli273)
 
Shengjie Guo (sguo25)
 
'''Mentor:''' Nicholas Himes (nnhimes@ncsu.edu)

==References==

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-06T21:35:29Z

Yli273: /* Implementation */

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-06T21:32:46Z

Yli273: /* Test Plan */

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-06T21:32:19Z

Yli273: /* Implementation */

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-06T21:31:11Z

Yli273: /* Implementation */

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-06T21:27:12Z

Yli273: /* Implementation */

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-06T21:27:03Z

Yli273: /* Implementation */

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-06T21:26:53Z

Yli273: /* Introduction */

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-06T21:22:34Z

Yli273: /* Problems with Previous Implementation */

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-06T21:22:10Z

Yli273: /* Introduction */

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-06T21:14:44Z

Yli273: /* Implementation */

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-04T02:32:06Z

Yli273: /* Test Plan */

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-04T02:31:53Z

Yli273: /* Test Plan */

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-01T23:49:28Z

Yli273: /* Previous Implementations */

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-01T23:48:52Z

Yli273: /* Previous Implementations */

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-01T23:48:23Z

Yli273: /* Previous Implementations */

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-01T23:46:39Z

Yli273: /* Previous Implementations */

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-01T23:45:47Z

Yli273: /* Goals */

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-01T23:44:11Z

Yli273: /* Problem Statement */

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-01T23:38:53Z

Yli273: /* Rationale */

CSC/ECE 517 Fall 2021 - E2152. Revision planning tool

2021-11-01T23:38:47Z

Yli273: /* Problem Statement */

CSC/ECE 517 Fall 2021 - E2124. Refactor review mapping controller.rb

2021-10-25T21:40:41Z

Yli273: /* Manual UI Testing */

This wiki page is for the description of changes made under E2124 OSS assignment for Fall 2021, CSC/ECE 517.
== About Expertiza==

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Description of the project ==
The focus of the project is on a controller named ReviewMappingController and the primary goal is to make changes to the internal structure of the controller to make it easier to read and cheaper to maintain without changing its observable behavior. This can be achieved through refactoring some of the more complex methods, modifying some of the language to make it more Ruby friendly, removing redundant code, etc. 
Link to the Pull Request Submitted: [https://github.com/expertiza/expertiza/pull/2060] 
link to the deployed project: [http://152.7.176.14:8080/] 
Link to the Repository: [https://github.com/JesseChen1031/expertiza] 

== Functionality of review_mapping_controller ==
The functionality of review_mapping_controller is to provide mapping for reviewer and assignment. Basically, the controller handles assignment of reviews to different teams or single student user, such as the event of peer review and self review. Also, this controller is responsible to respond student user request for extra bonus reviews based on assignment policy.

== Problem Statement ==

The review_mapping_controller is a long and complex file. Most of the methods are sparsely commented on. Some methods are way too long to understand, please break them down into pieces for better understanding. Also, the few instances of code duplication that exist should also be removed.

== Tasks ==
-Refactor the long methods in review_mapping_controller.rb 
-Rename variable names such as student_review_num, submission_review_num, calibrated_artifacts_num, participants_hash to convey what they are actually used for 
-Replace switch statements with subclasses methods 
-Create models for the subclasses 
-Remove hardcoded parameters 

== Flow Chart & Design Pattern ==
[[File:Work_flow.png|1000px]]
 
We were asked to refactor the long methods in review_mapping_controller.rb. We followed the flow chart above during the refactoring process. It happened many times when the Rspec test suit and Cucumber tests passed locally, but ran into an issue when we commit changes on GitHub. The error log from the TRAVIS CI helped us identify the issue. Then we debugged on local machine and followed the whole implementation process again. In this way, we covered every refactoring we did and ensured that the TRAVIS CI get passed with minimal issues.

== Files modified/created in the current project ==

1. review_mapping_controller.rb 
2. review_mapping_controller_spec.rb 
3. select_reviewer.html.haml 
4. app/views/assignments/edit/_calibration.html.erb 
5. app/views/review_mapping/select_reviewer.html.haml 
6. app/views/student_quizzes/_set_dynamic_quiz.html.erb 
7. app/views/student_review/_set_dynamic_review.html.erb 
8. config/routes.rb 
9. db/schema.rb 
10. spec/controllers/review_mapping_controller_spec.rb 
11. spec/features/assignment_creation_spec.rb 
12. spec/features/review_assignment_spec.rb 
13. spec/features/review_mapping_spec.rb 

=== ReviewMappingController ===

This controller will map the submissions made by the teams to the students for facilitating peer-reviewing. A couple of '''long''' and '''complex methods''' such as '''peer_review_strategy''' and '''automatic_review_mapping''' were refactored from this controller along with the '''removal''' of some '''non-related methods''' such as '''add_calibration''' and '''assign_quiz_dynamically'''. Variable names have been changed and code has been modularized and helper methods were separated from the important methods into a module and were included in the class.

Test Cases were created for the newly created controllers such as assign_quiz_controller etc.

=== review_mapping_controller_spec.rb ===

Added a test in this file.

=== _set_dynamic_review.html.erb & review_assignment_spec.rb & review_mapping_spec.rb & routes.rb & assignment_creation_review_strategy_spec.rb & assignment_creation_spec.rb ===

Modified due to the variable name change.

=== views/partials ===

Routes were changed in the views and partials.

==== Modified View Files: ====
app\views\review_mapping\select_reviewer.html.haml 
app/views/student_quizzes/_set_dynamic_quiz.html.erb 

== Details of the changes made==
1. A couple of long and coplex methods such as peer_review_strategy were refactored from this controller. 
       *A random participant_id is generated from the possible pool of candidates but the code block for that is kind of a query, i.e. it does not change or set anything. 
       *And it is equally complex enough to confuse the reader. So this has been put into a helper method with an expressive name to increase readability. 
       *Removed code redundancy from review_mapping_controller#peer_review_strategy. Long and reusable code were sorted out to form a new helper function. 
       *Replaced the one in the before(:each) loop by @instructor = build(:instructor, id: 1) and used @instructor class variable, wherever required. 
[[File:Peer review.png|1000px]] 
2. Rename variable names and remove hardcoded paramters. 
       *Changed :i_dont_care to :no_particular_topic. 
       *:i_dont_care was used in the /app/views/student_review/_set_dynamic_review.html.erb as a flag to store if student is interested in any particular topic or doesn't care which topic to review. 
       *It was also used in review_mapping_controller.rb to check if student has selected any particular topic. 

       *Since, name :i_dont_care was very difficult to understand, we replaced it with something logical such as :no_particular_topic. It gives hint about what the symbol stores. 
[[File:i_dont_care1.png|1000px]] 

       *Changed :add_reviewer to :assign_reviewer_dynamically. 
[[File:Add_Reviewer.png|1000px]] 

       *Changed :student_review_num to :num_reviews_per_students. 
       *Changed :submission_review_num to :num_reviews_per_submission. 
[[File:Student_review_num.png|1000px]] 

       *Changed :participants_hash to :team_participants_hash. 
[[File:Participants_hash.png|1000px]] 

       *Changed :replace hardcoded parameter (e.g.,0 and 1) with meaningful zero_review and one_review naming scheme. 
[[File:Hardcoded.png|1000px]] 

3. Replace switch statements with subclasses methods 
       We used "check_num_reviews_args" function to represent the switch statements in "automatic review mapping" function to simply it.
       [[File:Subfunc_for_switch.png|1000px]] 

4. Create models for the subclasses 
       We created 3 modules and put relative subclasses methods in to make the controller more organized.
       [[File:3_modules.png|1000px]] 

5. Added one test case and modified "select_metaviewver" to check if a mapping can be found correctly.
 [[File:Test_case.png|1000px]] 

== Test Plan ==

=== Manual UI Testing ===

According to the introduction, the modification of this project is about review_mapping_controller.rb. The main job of this controller is to correctly assign the review to each student who is requesting them for a certain assignment. Unfortunately, the deployed project database is not complete, and student accounts cannot be created. Therefore, we cannot use the deployed project to give a complete UI test plan.

In fact, due to system reasons, the internal logic of these controllers cannot be tested using UI tests because they are work flow and logic that have nothing to do with the UI. (The work flow can be found here [https://expertiza.csc.ncsu.edu/index.php/Review_mappings]) So we will re-introduce and emphasis the tests in Rspec unit test section to explain why the project is still complete after modification.

=== Rspec Unit Tests ===

Since this is a refactoring project, We followed the implementation flowchart provided in the above section step by step. In the refactoring process, we made sure that the changes did not break any functionality and passed all the existing test cases. Additionally, we added select_metareviewer to capture one edge case scenario. New test case select_metareviewer makes sure that ReponseMap can be correctly found. 
 [[File:Test_case.png|1000px]] 

The current test suit carefully follows Test Driven Development (TDD) approach, and offers testers automated testing environment using rSpec. The tests take advantages of double and stub features of rSpec gems, and pre-define different user types (e.g., instructor and student) in each case for different purpose. Testers can enter "rspec spec/controllers/review_mapping_controller_spec.rb" command in the terminal to execute the automated rspec test suit. After execution of the test cases, result of passing all test cases is shown as below.

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

Note: If you are interested in what each test case does, the link below is highly recommended for you to review as you could get better understanding by reading the assertion per test case: 
https://github.com/JesseChen1031/expertiza/blob/master/spec/controllers/review_mapping_controller_spec.rb

=== Capybara Integration and Functional Tests ===

Our project passed the Travis CI build test.

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

== Code Coverage ==

The code Coverage for Controllers has increased as shown below.

[https://coveralls.io/builds/43657457/source?filename=app%2Fcontrollers%2Freview_mapping_controller.rb] # Link for the COVERALLS stats of our pull request.

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

== Project Mentor ==

Jialin Cui (jcui9@ncsu.edu)

== Team Members ==

Yi Li (yli273@ncsu.edu)

Zijun Lu (zlu5@ncsu.edu)

Huangxing Chen (hchen63@ncsu.edu)

CSC/ECE 517 Fall 2021 - E2124. Refactor review mapping controller.rb

2021-10-25T21:40:26Z

Yli273: /* Manual UI Testing */

This wiki page is for the description of changes made under E2124 OSS assignment for Fall 2021, CSC/ECE 517.
== About Expertiza==

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Description of the project ==
The focus of the project is on a controller named ReviewMappingController and the primary goal is to make changes to the internal structure of the controller to make it easier to read and cheaper to maintain without changing its observable behavior. This can be achieved through refactoring some of the more complex methods, modifying some of the language to make it more Ruby friendly, removing redundant code, etc. 
Link to the Pull Request Submitted: [https://github.com/expertiza/expertiza/pull/2060] 
link to the deployed project: [http://152.7.176.14:8080/] 
Link to the Repository: [https://github.com/JesseChen1031/expertiza] 

== Functionality of review_mapping_controller ==
The functionality of review_mapping_controller is to provide mapping for reviewer and assignment. Basically, the controller handles assignment of reviews to different teams or single student user, such as the event of peer review and self review. Also, this controller is responsible to respond student user request for extra bonus reviews based on assignment policy.

== Problem Statement ==

The review_mapping_controller is a long and complex file. Most of the methods are sparsely commented on. Some methods are way too long to understand, please break them down into pieces for better understanding. Also, the few instances of code duplication that exist should also be removed.

== Tasks ==
-Refactor the long methods in review_mapping_controller.rb 
-Rename variable names such as student_review_num, submission_review_num, calibrated_artifacts_num, participants_hash to convey what they are actually used for 
-Replace switch statements with subclasses methods 
-Create models for the subclasses 
-Remove hardcoded parameters 

== Flow Chart & Design Pattern ==
[[File:Work_flow.png|1000px]]
 
We were asked to refactor the long methods in review_mapping_controller.rb. We followed the flow chart above during the refactoring process. It happened many times when the Rspec test suit and Cucumber tests passed locally, but ran into an issue when we commit changes on GitHub. The error log from the TRAVIS CI helped us identify the issue. Then we debugged on local machine and followed the whole implementation process again. In this way, we covered every refactoring we did and ensured that the TRAVIS CI get passed with minimal issues.

== Files modified/created in the current project ==

1. review_mapping_controller.rb 
2. review_mapping_controller_spec.rb 
3. select_reviewer.html.haml 
4. app/views/assignments/edit/_calibration.html.erb 
5. app/views/review_mapping/select_reviewer.html.haml 
6. app/views/student_quizzes/_set_dynamic_quiz.html.erb 
7. app/views/student_review/_set_dynamic_review.html.erb 
8. config/routes.rb 
9. db/schema.rb 
10. spec/controllers/review_mapping_controller_spec.rb 
11. spec/features/assignment_creation_spec.rb 
12. spec/features/review_assignment_spec.rb 
13. spec/features/review_mapping_spec.rb 

=== ReviewMappingController ===

This controller will map the submissions made by the teams to the students for facilitating peer-reviewing. A couple of '''long''' and '''complex methods''' such as '''peer_review_strategy''' and '''automatic_review_mapping''' were refactored from this controller along with the '''removal''' of some '''non-related methods''' such as '''add_calibration''' and '''assign_quiz_dynamically'''. Variable names have been changed and code has been modularized and helper methods were separated from the important methods into a module and were included in the class.

Test Cases were created for the newly created controllers such as assign_quiz_controller etc.

=== review_mapping_controller_spec.rb ===

Added a test in this file.

=== _set_dynamic_review.html.erb & review_assignment_spec.rb & review_mapping_spec.rb & routes.rb & assignment_creation_review_strategy_spec.rb & assignment_creation_spec.rb ===

Modified due to the variable name change.

=== views/partials ===

Routes were changed in the views and partials.

==== Modified View Files: ====
app\views\review_mapping\select_reviewer.html.haml 
app/views/student_quizzes/_set_dynamic_quiz.html.erb 

== Details of the changes made==
1. A couple of long and coplex methods such as peer_review_strategy were refactored from this controller. 
       *A random participant_id is generated from the possible pool of candidates but the code block for that is kind of a query, i.e. it does not change or set anything. 
       *And it is equally complex enough to confuse the reader. So this has been put into a helper method with an expressive name to increase readability. 
       *Removed code redundancy from review_mapping_controller#peer_review_strategy. Long and reusable code were sorted out to form a new helper function. 
       *Replaced the one in the before(:each) loop by @instructor = build(:instructor, id: 1) and used @instructor class variable, wherever required. 
[[File:Peer review.png|1000px]] 
2. Rename variable names and remove hardcoded paramters. 
       *Changed :i_dont_care to :no_particular_topic. 
       *:i_dont_care was used in the /app/views/student_review/_set_dynamic_review.html.erb as a flag to store if student is interested in any particular topic or doesn't care which topic to review. 
       *It was also used in review_mapping_controller.rb to check if student has selected any particular topic. 

       *Since, name :i_dont_care was very difficult to understand, we replaced it with something logical such as :no_particular_topic. It gives hint about what the symbol stores. 
[[File:i_dont_care1.png|1000px]] 

       *Changed :add_reviewer to :assign_reviewer_dynamically. 
[[File:Add_Reviewer.png|1000px]] 

       *Changed :student_review_num to :num_reviews_per_students. 
       *Changed :submission_review_num to :num_reviews_per_submission. 
[[File:Student_review_num.png|1000px]] 

       *Changed :participants_hash to :team_participants_hash. 
[[File:Participants_hash.png|1000px]] 

       *Changed :replace hardcoded parameter (e.g.,0 and 1) with meaningful zero_review and one_review naming scheme. 
[[File:Hardcoded.png|1000px]] 

3. Replace switch statements with subclasses methods 
       We used "check_num_reviews_args" function to represent the switch statements in "automatic review mapping" function to simply it.
       [[File:Subfunc_for_switch.png|1000px]] 

4. Create models for the subclasses 
       We created 3 modules and put relative subclasses methods in to make the controller more organized.
       [[File:3_modules.png|1000px]] 

5. Added one test case and modified "select_metaviewver" to check if a mapping can be found correctly.
 [[File:Test_case.png|1000px]] 

== Test Plan ==

=== Manual UI Testing ===

According to the introduction, the modification of this project is about review_mapping_controller.rb. The main job of this controller is to correctly assign the review to each student who is requesting them for a certain assignment. Unfortunately, the deployed project database is not complete, and student accounts cannot be created. Therefore, we cannot use the deployed project to give a complete UI test plan.

In fact, due to system reasons, the internal logic of these controllers cannot be tested using UI tests because they are work flow and logic that have nothing to do with the UI. (The work flow can be found here [https://expertiza.csc.ncsu.edu/index.php/Review_mappings])So we will re-introduce and emphasis the tests in Rspec unit test section to explain why the project is still complete after modification.

=== Rspec Unit Tests ===

Since this is a refactoring project, We followed the implementation flowchart provided in the above section step by step. In the refactoring process, we made sure that the changes did not break any functionality and passed all the existing test cases. Additionally, we added select_metareviewer to capture one edge case scenario. New test case select_metareviewer makes sure that ReponseMap can be correctly found. 
 [[File:Test_case.png|1000px]] 

The current test suit carefully follows Test Driven Development (TDD) approach, and offers testers automated testing environment using rSpec. The tests take advantages of double and stub features of rSpec gems, and pre-define different user types (e.g., instructor and student) in each case for different purpose. Testers can enter "rspec spec/controllers/review_mapping_controller_spec.rb" command in the terminal to execute the automated rspec test suit. After execution of the test cases, result of passing all test cases is shown as below.

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

Note: If you are interested in what each test case does, the link below is highly recommended for you to review as you could get better understanding by reading the assertion per test case: 
https://github.com/JesseChen1031/expertiza/blob/master/spec/controllers/review_mapping_controller_spec.rb

=== Capybara Integration and Functional Tests ===

Our project passed the Travis CI build test.

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

== Code Coverage ==

The code Coverage for Controllers has increased as shown below.

[https://coveralls.io/builds/43657457/source?filename=app%2Fcontrollers%2Freview_mapping_controller.rb] # Link for the COVERALLS stats of our pull request.

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

== Project Mentor ==

Jialin Cui (jcui9@ncsu.edu)

== Team Members ==

Yi Li (yli273@ncsu.edu)

Zijun Lu (zlu5@ncsu.edu)

Huangxing Chen (hchen63@ncsu.edu)

CSC/ECE 517 Fall 2021 - E2124. Refactor review mapping controller.rb

2021-10-25T21:39:25Z

Yli273: /* Test Plan */

This wiki page is for the description of changes made under E2124 OSS assignment for Fall 2021, CSC/ECE 517.
== About Expertiza==

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Description of the project ==
The focus of the project is on a controller named ReviewMappingController and the primary goal is to make changes to the internal structure of the controller to make it easier to read and cheaper to maintain without changing its observable behavior. This can be achieved through refactoring some of the more complex methods, modifying some of the language to make it more Ruby friendly, removing redundant code, etc. 
Link to the Pull Request Submitted: [https://github.com/expertiza/expertiza/pull/2060] 
link to the deployed project: [http://152.7.176.14:8080/] 
Link to the Repository: [https://github.com/JesseChen1031/expertiza] 

== Functionality of review_mapping_controller ==
The functionality of review_mapping_controller is to provide mapping for reviewer and assignment. Basically, the controller handles assignment of reviews to different teams or single student user, such as the event of peer review and self review. Also, this controller is responsible to respond student user request for extra bonus reviews based on assignment policy.

== Problem Statement ==

The review_mapping_controller is a long and complex file. Most of the methods are sparsely commented on. Some methods are way too long to understand, please break them down into pieces for better understanding. Also, the few instances of code duplication that exist should also be removed.

== Tasks ==
-Refactor the long methods in review_mapping_controller.rb 
-Rename variable names such as student_review_num, submission_review_num, calibrated_artifacts_num, participants_hash to convey what they are actually used for 
-Replace switch statements with subclasses methods 
-Create models for the subclasses 
-Remove hardcoded parameters 

== Flow Chart & Design Pattern ==
[[File:Work_flow.png|1000px]]
 
We were asked to refactor the long methods in review_mapping_controller.rb. We followed the flow chart above during the refactoring process. It happened many times when the Rspec test suit and Cucumber tests passed locally, but ran into an issue when we commit changes on GitHub. The error log from the TRAVIS CI helped us identify the issue. Then we debugged on local machine and followed the whole implementation process again. In this way, we covered every refactoring we did and ensured that the TRAVIS CI get passed with minimal issues.

== Files modified/created in the current project ==

1. review_mapping_controller.rb 
2. review_mapping_controller_spec.rb 
3. select_reviewer.html.haml 
4. app/views/assignments/edit/_calibration.html.erb 
5. app/views/review_mapping/select_reviewer.html.haml 
6. app/views/student_quizzes/_set_dynamic_quiz.html.erb 
7. app/views/student_review/_set_dynamic_review.html.erb 
8. config/routes.rb 
9. db/schema.rb 
10. spec/controllers/review_mapping_controller_spec.rb 
11. spec/features/assignment_creation_spec.rb 
12. spec/features/review_assignment_spec.rb 
13. spec/features/review_mapping_spec.rb 

=== ReviewMappingController ===

This controller will map the submissions made by the teams to the students for facilitating peer-reviewing. A couple of '''long''' and '''complex methods''' such as '''peer_review_strategy''' and '''automatic_review_mapping''' were refactored from this controller along with the '''removal''' of some '''non-related methods''' such as '''add_calibration''' and '''assign_quiz_dynamically'''. Variable names have been changed and code has been modularized and helper methods were separated from the important methods into a module and were included in the class.

Test Cases were created for the newly created controllers such as assign_quiz_controller etc.

=== review_mapping_controller_spec.rb ===

Added a test in this file.

=== _set_dynamic_review.html.erb & review_assignment_spec.rb & review_mapping_spec.rb & routes.rb & assignment_creation_review_strategy_spec.rb & assignment_creation_spec.rb ===

Modified due to the variable name change.

=== views/partials ===

Routes were changed in the views and partials.

==== Modified View Files: ====
app\views\review_mapping\select_reviewer.html.haml 
app/views/student_quizzes/_set_dynamic_quiz.html.erb 

== Details of the changes made==
1. A couple of long and coplex methods such as peer_review_strategy were refactored from this controller. 
       *A random participant_id is generated from the possible pool of candidates but the code block for that is kind of a query, i.e. it does not change or set anything. 
       *And it is equally complex enough to confuse the reader. So this has been put into a helper method with an expressive name to increase readability. 
       *Removed code redundancy from review_mapping_controller#peer_review_strategy. Long and reusable code were sorted out to form a new helper function. 
       *Replaced the one in the before(:each) loop by @instructor = build(:instructor, id: 1) and used @instructor class variable, wherever required. 
[[File:Peer review.png|1000px]] 
2. Rename variable names and remove hardcoded paramters. 
       *Changed :i_dont_care to :no_particular_topic. 
       *:i_dont_care was used in the /app/views/student_review/_set_dynamic_review.html.erb as a flag to store if student is interested in any particular topic or doesn't care which topic to review. 
       *It was also used in review_mapping_controller.rb to check if student has selected any particular topic. 

       *Since, name :i_dont_care was very difficult to understand, we replaced it with something logical such as :no_particular_topic. It gives hint about what the symbol stores. 
[[File:i_dont_care1.png|1000px]] 

       *Changed :add_reviewer to :assign_reviewer_dynamically. 
[[File:Add_Reviewer.png|1000px]] 

       *Changed :student_review_num to :num_reviews_per_students. 
       *Changed :submission_review_num to :num_reviews_per_submission. 
[[File:Student_review_num.png|1000px]] 

       *Changed :participants_hash to :team_participants_hash. 
[[File:Participants_hash.png|1000px]] 

       *Changed :replace hardcoded parameter (e.g.,0 and 1) with meaningful zero_review and one_review naming scheme. 
[[File:Hardcoded.png|1000px]] 

3. Replace switch statements with subclasses methods 
       We used "check_num_reviews_args" function to represent the switch statements in "automatic review mapping" function to simply it.
       [[File:Subfunc_for_switch.png|1000px]] 

4. Create models for the subclasses 
       We created 3 modules and put relative subclasses methods in to make the controller more organized.
       [[File:3_modules.png|1000px]] 

5. Added one test case and modified "select_metaviewver" to check if a mapping can be found correctly.
 [[File:Test_case.png|1000px]] 

== Test Plan ==

=== Manual UI Testing ===

According to the introduction, the modification of this project is about review_mapping_controller.rb. The main job of this controller is to correctly assign the review to each student who is requesting them for a certain assignment. Unfortunately, the deployed project database is not complete, and student accounts cannot be created. Therefore, we cannot use the deployed project to give a complete UI test plan. In fact, due to system reasons, the internal logic of these controllers cannot be tested using UI tests because they are work flow and logic that have nothing to do with the UI. So we will re-introduce and emphasis the tests in Rspec unit test section to explain why the project is still complete after modification.

=== Rspec Unit Tests ===

Since this is a refactoring project, We followed the implementation flowchart provided in the above section step by step. In the refactoring process, we made sure that the changes did not break any functionality and passed all the existing test cases. Additionally, we added select_metareviewer to capture one edge case scenario. New test case select_metareviewer makes sure that ReponseMap can be correctly found. 
 [[File:Test_case.png|1000px]] 

The current test suit carefully follows Test Driven Development (TDD) approach, and offers testers automated testing environment using rSpec. The tests take advantages of double and stub features of rSpec gems, and pre-define different user types (e.g., instructor and student) in each case for different purpose. Testers can enter "rspec spec/controllers/review_mapping_controller_spec.rb" command in the terminal to execute the automated rspec test suit. After execution of the test cases, result of passing all test cases is shown as below.

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

Note: If you are interested in what each test case does, the link below is highly recommended for you to review as you could get better understanding by reading the assertion per test case: 
https://github.com/JesseChen1031/expertiza/blob/master/spec/controllers/review_mapping_controller_spec.rb

=== Capybara Integration and Functional Tests ===

Our project passed the Travis CI build test.

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

== Code Coverage ==

The code Coverage for Controllers has increased as shown below.

[https://coveralls.io/builds/43657457/source?filename=app%2Fcontrollers%2Freview_mapping_controller.rb] # Link for the COVERALLS stats of our pull request.

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

== Project Mentor ==

Jialin Cui (jcui9@ncsu.edu)

== Team Members ==

Yi Li (yli273@ncsu.edu)

Zijun Lu (zlu5@ncsu.edu)

Huangxing Chen (hchen63@ncsu.edu)

CSC/ECE 517 Fall 2021 - E2124. Refactor review mapping controller.rb

2021-10-25T21:29:41Z

Yli273: /* Rspec Unit Tests */

CSC/ECE 517 Fall 2021 - E2124. Refactor review mapping controller.rb

2021-10-21T03:44:50Z

Yli273: /* Description of the project */

CSC/ECE 517 Fall 2021 - E2124. Refactor review mapping controller.rb

2021-10-21T03:29:46Z

Yli273: /* Description of the project */

CSC/ECE 517 Fall 2021 - E2124. Refactor review mapping controller.rb

2021-10-21T03:27:50Z

Yli273: /* Description of the project */

CSC/ECE 517 Fall 2021 - E2124. Refactor review mapping controller.rb

2021-10-21T03:19:08Z

Yli273:

CSC/ECE 517 Fall 2021 - E2124. Refactor review mapping controller.rb

2021-10-21T03:01:42Z

Yli273: /* Details of the changes made */

CSC/ECE 517 Fall 2021 - E2124. Refactor review mapping controller.rb

2021-10-21T03:01:10Z

Yli273: /* Details of the changes made */

CSC/ECE 517 Fall 2021 - E2124. Refactor review mapping controller.rb

2021-10-21T02:53:15Z

Yli273: /* Details of the changes made */

This wiki page is for the description of changes made under E2124 OSS assignment for Fall 2021, CSC/ECE 517.
== About Expertiza==

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Functionality of review_mapping_controller ==
The functionality of review_mapping_controller is to provide mapping for reviewer and assignment. Basically, the controller handles assignment of reviews to different teams or single student user, such as the event of peer review and self review. Also, this controller is responsible to respond student user request for extra bonus reviews based on assignment policy.

== Problem Statement ==

The review_mapping_controller is a long and complex file. Most of the methods are sparsely commented on. Some methods are way too long to understand, please break them down into pieces for better understanding. Also, the few instances of code duplication that exist should also be removed.

== Tasks ==
-Refactor the long methods in review_mapping_controller.rb 
-Rename variable names such as student_review_num, submission_review_num, calibrated_artifacts_num, participants_hash to convey what they are actually used for 
-Replace switch statements with subclasses methods 
-Create models for the subclasses 
-Remove hardcoded parameters 

== Implementation ==
[[File:FlowchartOODD.jpg]]
 
We were tasked to refactor the review_mapping_controller.rb and solve any cascading issues or bugs we could find. We followed the above work plan to complete this task. There were many times when all the Rspec and Cucumber tests passed locally but ran into an issue when we uploaded the changes on GitHub. Prompt feedback from the TRAVIS CI helped us recognize the issue. Then we went on local machine and followed the whole process of refactoring again. In this way, we covered every refactoring we did and ensured that the TRAVIS CI get passed with minimum issues on the code-climate.

== Files modified/created in the current project ==

1. review_mapping_controller.rb 
2. review_mapping_controller_spec.rb 
3. select_reviewer.html.haml 
4. app/views/assignments/edit/_calibration.html.erb 
5. app/views/review_mapping/select_reviewer.html.haml 
6. app/views/student_quizzes/_set_dynamic_quiz.html.erb 
7. app/views/student_review/_set_dynamic_review.html.erb 
8. config/routes.rb 
9. db/schema.rb 
10. spec/controllers/review_mapping_controller_spec.rb 
11. spec/features/assignment_creation_spec.rb 
12. spec/features/review_assignment_spec.rb 
13. spec/features/review_mapping_spec.rb 

=== ReviewMappingController ===

This controller will map the submissions made by the teams to the students for facilitating peer-reviewing. A couple of '''long''' and '''complex methods''' such as '''peer_review_strategy''' and '''automatic_review_mapping''' were refactored from this controller along with the '''removal''' of some '''non-related methods''' such as '''add_calibration''' and '''assign_quiz_dynamically'''. Variable names have been changed and code has been modularized and helper methods were separated from the important methods into a module and were included in the class.

Test Cases were created for the newly created controllers such as assign_quiz_controller etc.

=== review_mapping_controller_spec.rb ===

Added a test in this file.

=== _set_dynamic_review.html.erb & review_assignment_spec.rb & review_mapping_spec.rb & routes.rb & assignment_creation_review_strategy_spec.rb & assignment_creation_spec.rb ===

Modified due to the variable name change.

=== views/partials ===

Routes were changed in the views and partials.

==== Modified View Files: ====
app\views\review_mapping\select_reviewer.html.haml 
app/views/student_quizzes/_set_dynamic_quiz.html.erb 

== Details of the changes made==
1. A couple of long and coplex methods such as peer_review_strategy were refactored from this controller. 
       *Removed code redundancy from review_mapping_controller#peer_review_strategy. Long and reusable code were sorted out to form a new helper function. 
       *Replaced the one in the before(:each) loop by @instructor = build(:instructor, id: 1) and used @instructor class variable, wherever required. 
[[File:Peer_review.png]] 

2. Changed :i_dont_care to :no_particular_topic 
       *:i_dont_care was used in the /app/views/student_review/_set_dynamic_review.html.erb as a flag to store if student is interested in any particular topic or doesn't care which topic to review. 
       *It was also used in review_mapping_controller.rb to check if student has selected any particular topic. 
       *Since, name :i_dont_care was very difficult to understand, we replaced it with something logical such as :no_particular_topic. It gives hint about what the symbol stores. 

3. Replace switch statements with subclasses methods 
       We used "check_num_reviews_args" function to represent the switch statements in "automatic review mapping" function to simply it.
       [[File:Subfunc_for_switch.png]] 

4. Create models for the subclasses 
       We created 3 modules and put relative subclasses methods in to make the controller more organized.
       [[File:3_modules.png]] 

5. Refactored Peer_review_strategy by using a helper method gen_random_participant_id 
       *A random participant_id is generated from the possible pool of candidates but the code block for that is kind of a query, i.e. it does not change or set anything. 
       *And it is equally complex enough to confuse the reader. So this has been put into a helper method with an expressive name to increase readability. 
<pre>
## Helper Method for generating a random participant which is to be used in peer_review_strategy method.
def gen_random_participant_id(iterator, participants_hash, num_participants, participants)
if iterator.zero?
rand_num = rand(0..num_participants - 1)
else
min_value = participants_hash.values.min
# get the temp array including indices of participants, each participant has minimum review number in hash table.
participants_with_min_assigned_reviews = []
participants.each do |participant|
participants_with_min_assigned_reviews << participants.index(participant) if participants_hash[participant.id] == min_value
end
# if participants_with_min_assigned_reviews is blank
no_particpants = participants_with_min_assigned_reviews.empty?
# or only one element in participants_with_min_assigned_reviews, prohibit one student to review his/her own artifact
participant_is_owner = (participants_with_min_assigned_reviews.size == 1 and TeamsUser.exists?(team_id: team.id, user_id: participants[participants_with_min_assigned_reviews[0]].user_id))
rand_num = if no_particpants or participant_is_owner
# use original method to get random number
rand(0..num_participants - 1)
else
# rand_num should be the position of this participant in original array
participants_with_min_assigned_reviews[rand(0..participants_with_min_assigned_reviews.size - 1)]
end
end
return rand_num
end
</pre>
6. Refactored automatic_review_mapping by using a helper method check_num_reviews_args 
       *Parameters such as num_reviews_per_student, num_calibrated_artifacts etc passed are first verified to check if they are in acceptable range or pattern 
       *To increase readability, the not-so good looking sets of if-else statements have been moved into check_num_reviews_args method. 
<pre>
# Helper Method to check num_reviews_per_student and num_reviews_per_submission arguments passed in by params hash.
def check_num_reviews_args(num_reviews_per_student, num_reviews_per_submission, teams)
has_error_not_raised = true
# check for exit paths first
if num_reviews_per_student == 0 and num_reviews_per_submission == 0
flash[:error] = "Please choose either the number of reviews per student or the number of reviewers per team (student)."
has_error_not_raised = false
elsif num_reviews_per_student != 0 and num_reviews_per_submission != 0
flash[:error] = "Please choose either the number of reviews per student or the number of reviewers per team (student), not both."
has_error_not_raised = false
elsif num_reviews_per_student >= teams.size
# Exception detection: If instructor want to assign too many reviews done
# by each student, there will be an error msg.
flash[:error] = 'You cannot set the number of reviews done ' \
'by each student to be greater than or equal to total number of teams ' \
'[or "participants" if it is an individual assignment].'
has_error_not_raised = false
end
end
</pre>
7. Modularized helper methods into a module and was mixed in the ReviewMappingController Class. 
       *Only some of the methods written in the class have external usage i.e called by another controllers, views etc. 
       *The other methods are just helpers and as such moved into a Helper method module and mixed in the class 
Before Modularization
<pre>
class ReviewMappingController < ApplicationController
...................
...................
512 Lines & 25 Methods Defined (After moving a few methods into separate controllers)
...................
...................
end
</pre>
After Modularization
<pre>
module Helper_methods
...................
5 Methods and 170 lines
...................
end

class ReviewMappingController < ApplicationController
include Helper_methods
...................
340 Lines & 20 Methods (All of those are used elsewhere directly in the application)
...................
end
</pre>

8. Abided to the principles of Magic Tricks of testing and did not test any internally used methods, The other tests are written were already following this principle. 
       *Internally used methods were not tested 
       *Tests for newly created controllers have been moved into a separate spec files. 

9. Isolated AssignQuizDynamically method into a separate controller as the functionality was not related to ReviewMappingController. 
       *This method assigns a quiz(Stored as an assignment object) to the participant. 
       *This method is not related to ReviewMapping functionality, so it was made into a new controller. 

10. Associated Specs/routes/views/partials have been modified to adapt the change in controllers. 
       *The controller paths present in the views/partials have to be changed to not to break the functionality 
       *The controller paths in views/partials/routes have been changed for the newly created controller of AssignQuizDynamically 

View File Affected by the creation of AssinQuizController
[[File:View.png]]

11. student_review_num sounds like a number or an id associated with a student review, while it actually stores the number of reviews that a student can perform. So it is renamed num_reviews_per_student. 
12. submission_review_num sounds like a number or an id associated with a submission review, while it actually stores the total number of reviews that can be performed on a single submission. So it is renamed num_reviews_per_submission. 
13. calibrated_artifacts_num sounds like a number or an id associated with the calibrated artifacts, while it actually stores the number of calibrated artifacts. So it is renamed num_calibrated_artifacts. Similarly, uncalibrated_artifacts_num is renamed num_uncalibrated_artifacts. 
14. participants_hash is not an appropriate name for a hash whose keys are participant ids and values are number of reviews performed by corresponding participants. So it is renamed num_reviews_by_participant_hash. 
15. Extracted a method make_review_strategy (from automatic_review_mapping_strategy) that returns a review_strategy based on the values of num_reviews_per_submission and num_reviews_per_submission. 
16. add_calibration is a method that changes the attribute of a ReviewResponseMap and has little to do with Review Mapping. So it is now put in a separate controller named ReviewResponseMapController. 
17. Added one test case and modified "select_metaviewver" to check if a mapping can be found correctly.
 [[File:Test_case.png]] 

== Test Plan ==

=== Rspec Unit Tests ===

Since this is a Refactoring Project, We made sure that the changes made did not break any functionality.

[[File:rspec_test_passed.png]]

=== Capybara Integration and Functional Tests ===

As the controller routes have been modified in the routes.rb and the other view files, there are potential chances of failures in Integration tests.

However, no such failure has been reported by Travis build.

[[File:Travis CI.png]]

[[File:FeaturesCI.png]]

== Code Coverage ==

Code Coverage for Controllers section climbed up.

[https://coveralls.io/builds/26607665] # Link for the COVERALLS stats of our pull request.

[[File:CCC1.png]]

== Project Mentor ==

Ramya Vijayakumar (rvijaya4@ncsu.edu)

== Team Members ==

Yaswanth Soodini (ysoodin@ncsu.edu)

Saurabh Shingte (svshingt@ncsu.edu)

Vivek Karri (vkarri@ncsu.edu)

== Links for Demo Videos ==

Assign Reviewer Manually Demo[https://drive.google.com/file/d/1o9vJQ7fCwk0hwHJdErwpg1z_XjsN_XRT/view?usp=sharing]

Regression and Unit Testing of Controllers Demo[https://youtu.be/XejKHQKtpuA]

Automatic Assignment of Reviewer Demo [https://drive.google.com/file/d/17wpo7mTDenLvEcgubVflLtF_vmLb623a/view?usp=sharing]

CSC/ECE 517 Fall 2021 - E2124. Refactor review mapping controller.rb

2021-10-21T02:51:08Z

Yli273: /* Details of the changes made */

This wiki page is for the description of changes made under E2124 OSS assignment for Fall 2021, CSC/ECE 517.
== About Expertiza==

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Functionality of review_mapping_controller ==
The functionality of review_mapping_controller is to provide mapping for reviewer and assignment. Basically, the controller handles assignment of reviews to different teams or single student user, such as the event of peer review and self review. Also, this controller is responsible to respond student user request for extra bonus reviews based on assignment policy.

== Problem Statement ==

The review_mapping_controller is a long and complex file. Most of the methods are sparsely commented on. Some methods are way too long to understand, please break them down into pieces for better understanding. Also, the few instances of code duplication that exist should also be removed.

== Tasks ==
-Refactor the long methods in review_mapping_controller.rb 
-Rename variable names such as student_review_num, submission_review_num, calibrated_artifacts_num, participants_hash to convey what they are actually used for 
-Replace switch statements with subclasses methods 
-Create models for the subclasses 
-Remove hardcoded parameters 

== Implementation ==
[[File:FlowchartOODD.jpg]]
 
We were tasked to refactor the review_mapping_controller.rb and solve any cascading issues or bugs we could find. We followed the above work plan to complete this task. There were many times when all the Rspec and Cucumber tests passed locally but ran into an issue when we uploaded the changes on GitHub. Prompt feedback from the TRAVIS CI helped us recognize the issue. Then we went on local machine and followed the whole process of refactoring again. In this way, we covered every refactoring we did and ensured that the TRAVIS CI get passed with minimum issues on the code-climate.

== Files modified/created in the current project ==

1. review_mapping_controller.rb 
2. review_mapping_controller_spec.rb 
3. select_reviewer.html.haml 
4. app/views/assignments/edit/_calibration.html.erb 
5. app/views/review_mapping/select_reviewer.html.haml 
6. app/views/student_quizzes/_set_dynamic_quiz.html.erb 
7. app/views/student_review/_set_dynamic_review.html.erb 
8. config/routes.rb 
9. db/schema.rb 
10. spec/controllers/review_mapping_controller_spec.rb 
11. spec/features/assignment_creation_spec.rb 
12. spec/features/review_assignment_spec.rb 
13. spec/features/review_mapping_spec.rb 

=== ReviewMappingController ===

This controller will map the submissions made by the teams to the students for facilitating peer-reviewing. A couple of '''long''' and '''complex methods''' such as '''peer_review_strategy''' and '''automatic_review_mapping''' were refactored from this controller along with the '''removal''' of some '''non-related methods''' such as '''add_calibration''' and '''assign_quiz_dynamically'''. Variable names have been changed and code has been modularized and helper methods were separated from the important methods into a module and were included in the class.

Test Cases were created for the newly created controllers such as assign_quiz_controller etc.

=== review_mapping_controller_spec.rb ===

Added a test in this file.

=== _set_dynamic_review.html.erb & review_assignment_spec.rb & review_mapping_spec.rb & routes.rb & assignment_creation_review_strategy_spec.rb & assignment_creation_spec.rb ===

Modified due to the variable name change.

=== views/partials ===

Routes were changed in the views and partials.

==== Modified View Files: ====
app\views\review_mapping\select_reviewer.html.haml 
app/views/student_quizzes/_set_dynamic_quiz.html.erb 

== Details of the changes made==
1. A couple of long and coplex methods such as peer_review_strategy were refactored from this controller. 
       *Removed code redundancy from review_mapping_controller#peer_review_strategy. Two variables were being initialized containing the same value. One was in the before(:each) loop and other was being called in first three test cases. 
       *Replaced the one in the before(:each) loop by @instructor = build(:instructor, id: 1) and used @instructor class variable, wherever required. 
[[File:Peer_review.png]] 

2. Changed :i_dont_care to :no_particular_topic 
       *:i_dont_care was used in the /app/views/student_review/_set_dynamic_review.html.erb as a flag to store if student is interested in any particular topic or doesn't care which topic to review. 
       *It was also used in review_mapping_controller.rb to check if student has selected any particular topic. 
       *Since, name :i_dont_care was very difficult to understand, we replaced it with something logical such as :no_particular_topic. It gives hint about what the symbol stores. 

3. Replace switch statements with subclasses methods 
       We used "check_num_reviews_args" function to represent the switch statements in "automatic review mapping" function to simply it.
       [[File:Subfunc_for_switch.png]] 

4. Create models for the subclasses 
       We created 3 modules and put relative subclasses methods in to make the controller more organized.
       [[File:3_modules.png]] 

5. Refactored Peer_review_strategy by using a helper method gen_random_participant_id 
       *A random participant_id is generated from the possible pool of candidates but the code block for that is kind of a query, i.e. it does not change or set anything. 
       *And it is equally complex enough to confuse the reader. So this has been put into a helper method with an expressive name to increase readability. 
<pre>
## Helper Method for generating a random participant which is to be used in peer_review_strategy method.
def gen_random_participant_id(iterator, participants_hash, num_participants, participants)
if iterator.zero?
rand_num = rand(0..num_participants - 1)
else
min_value = participants_hash.values.min
# get the temp array including indices of participants, each participant has minimum review number in hash table.
participants_with_min_assigned_reviews = []
participants.each do |participant|
participants_with_min_assigned_reviews << participants.index(participant) if participants_hash[participant.id] == min_value
end
# if participants_with_min_assigned_reviews is blank
no_particpants = participants_with_min_assigned_reviews.empty?
# or only one element in participants_with_min_assigned_reviews, prohibit one student to review his/her own artifact
participant_is_owner = (participants_with_min_assigned_reviews.size == 1 and TeamsUser.exists?(team_id: team.id, user_id: participants[participants_with_min_assigned_reviews[0]].user_id))
rand_num = if no_particpants or participant_is_owner
# use original method to get random number
rand(0..num_participants - 1)
else
# rand_num should be the position of this participant in original array
participants_with_min_assigned_reviews[rand(0..participants_with_min_assigned_reviews.size - 1)]
end
end
return rand_num
end
</pre>
6. Refactored automatic_review_mapping by using a helper method check_num_reviews_args 
       *Parameters such as num_reviews_per_student, num_calibrated_artifacts etc passed are first verified to check if they are in acceptable range or pattern 
       *To increase readability, the not-so good looking sets of if-else statements have been moved into check_num_reviews_args method. 
<pre>
# Helper Method to check num_reviews_per_student and num_reviews_per_submission arguments passed in by params hash.
def check_num_reviews_args(num_reviews_per_student, num_reviews_per_submission, teams)
has_error_not_raised = true
# check for exit paths first
if num_reviews_per_student == 0 and num_reviews_per_submission == 0
flash[:error] = "Please choose either the number of reviews per student or the number of reviewers per team (student)."
has_error_not_raised = false
elsif num_reviews_per_student != 0 and num_reviews_per_submission != 0
flash[:error] = "Please choose either the number of reviews per student or the number of reviewers per team (student), not both."
has_error_not_raised = false
elsif num_reviews_per_student >= teams.size
# Exception detection: If instructor want to assign too many reviews done
# by each student, there will be an error msg.
flash[:error] = 'You cannot set the number of reviews done ' \
'by each student to be greater than or equal to total number of teams ' \
'[or "participants" if it is an individual assignment].'
has_error_not_raised = false
end
end
</pre>
7. Modularized helper methods into a module and was mixed in the ReviewMappingController Class. 
       *Only some of the methods written in the class have external usage i.e called by another controllers, views etc. 
       *The other methods are just helpers and as such moved into a Helper method module and mixed in the class 
Before Modularization
<pre>
class ReviewMappingController < ApplicationController
...................
...................
512 Lines & 25 Methods Defined (After moving a few methods into separate controllers)
...................
...................
end
</pre>
After Modularization
<pre>
module Helper_methods
...................
5 Methods and 170 lines
...................
end

class ReviewMappingController < ApplicationController
include Helper_methods
...................
340 Lines & 20 Methods (All of those are used elsewhere directly in the application)
...................
end
</pre>

8. Abided to the principles of Magic Tricks of testing and did not test any internally used methods, The other tests are written were already following this principle. 
       *Internally used methods were not tested 
       *Tests for newly created controllers have been moved into a separate spec files. 

9. Isolated AssignQuizDynamically method into a separate controller as the functionality was not related to ReviewMappingController. 
       *This method assigns a quiz(Stored as an assignment object) to the participant. 
       *This method is not related to ReviewMapping functionality, so it was made into a new controller. 

10. Associated Specs/routes/views/partials have been modified to adapt the change in controllers. 
       *The controller paths present in the views/partials have to be changed to not to break the functionality 
       *The controller paths in views/partials/routes have been changed for the newly created controller of AssignQuizDynamically 

View File Affected by the creation of AssinQuizController
[[File:View.png]]

11. student_review_num sounds like a number or an id associated with a student review, while it actually stores the number of reviews that a student can perform. So it is renamed num_reviews_per_student. 
12. submission_review_num sounds like a number or an id associated with a submission review, while it actually stores the total number of reviews that can be performed on a single submission. So it is renamed num_reviews_per_submission. 
13. calibrated_artifacts_num sounds like a number or an id associated with the calibrated artifacts, while it actually stores the number of calibrated artifacts. So it is renamed num_calibrated_artifacts. Similarly, uncalibrated_artifacts_num is renamed num_uncalibrated_artifacts. 
14. participants_hash is not an appropriate name for a hash whose keys are participant ids and values are number of reviews performed by corresponding participants. So it is renamed num_reviews_by_participant_hash. 
15. Extracted a method make_review_strategy (from automatic_review_mapping_strategy) that returns a review_strategy based on the values of num_reviews_per_submission and num_reviews_per_submission. 
16. add_calibration is a method that changes the attribute of a ReviewResponseMap and has little to do with Review Mapping. So it is now put in a separate controller named ReviewResponseMapController. 
17. Added one test case and modified "select_metaviewver" to check if a mapping can be found correctly.
 [[File:Test_case.png]] 

== Test Plan ==

=== Rspec Unit Tests ===

Since this is a Refactoring Project, We made sure that the changes made did not break any functionality.

[[File:rspec_test_passed.png]]

=== Capybara Integration and Functional Tests ===

As the controller routes have been modified in the routes.rb and the other view files, there are potential chances of failures in Integration tests.

However, no such failure has been reported by Travis build.

[[File:Travis CI.png]]

[[File:FeaturesCI.png]]

== Code Coverage ==

Code Coverage for Controllers section climbed up.

[https://coveralls.io/builds/26607665] # Link for the COVERALLS stats of our pull request.

[[File:CCC1.png]]

== Project Mentor ==

Ramya Vijayakumar (rvijaya4@ncsu.edu)

== Team Members ==

Yaswanth Soodini (ysoodin@ncsu.edu)

Saurabh Shingte (svshingt@ncsu.edu)

Vivek Karri (vkarri@ncsu.edu)

== Links for Demo Videos ==

Assign Reviewer Manually Demo[https://drive.google.com/file/d/1o9vJQ7fCwk0hwHJdErwpg1z_XjsN_XRT/view?usp=sharing]

Regression and Unit Testing of Controllers Demo[https://youtu.be/XejKHQKtpuA]

Automatic Assignment of Reviewer Demo [https://drive.google.com/file/d/17wpo7mTDenLvEcgubVflLtF_vmLb623a/view?usp=sharing]

CSC/ECE 517 Fall 2021 - E2124. Refactor review mapping controller.rb

2021-10-21T02:50:11Z

Yli273: /* Details of the changes made */

This wiki page is for the description of changes made under E2124 OSS assignment for Fall 2021, CSC/ECE 517.
== About Expertiza==

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Functionality of review_mapping_controller ==
The functionality of review_mapping_controller is to provide mapping for reviewer and assignment. Basically, the controller handles assignment of reviews to different teams or single student user, such as the event of peer review and self review. Also, this controller is responsible to respond student user request for extra bonus reviews based on assignment policy.

== Problem Statement ==

The review_mapping_controller is a long and complex file. Most of the methods are sparsely commented on. Some methods are way too long to understand, please break them down into pieces for better understanding. Also, the few instances of code duplication that exist should also be removed.

== Tasks ==
-Refactor the long methods in review_mapping_controller.rb 
-Rename variable names such as student_review_num, submission_review_num, calibrated_artifacts_num, participants_hash to convey what they are actually used for 
-Replace switch statements with subclasses methods 
-Create models for the subclasses 
-Remove hardcoded parameters 

== Implementation ==
[[File:FlowchartOODD.jpg]]
 
We were tasked to refactor the review_mapping_controller.rb and solve any cascading issues or bugs we could find. We followed the above work plan to complete this task. There were many times when all the Rspec and Cucumber tests passed locally but ran into an issue when we uploaded the changes on GitHub. Prompt feedback from the TRAVIS CI helped us recognize the issue. Then we went on local machine and followed the whole process of refactoring again. In this way, we covered every refactoring we did and ensured that the TRAVIS CI get passed with minimum issues on the code-climate.

== Files modified/created in the current project ==

1. review_mapping_controller.rb 
2. review_mapping_controller_spec.rb 
3. select_reviewer.html.haml 
4. app/views/assignments/edit/_calibration.html.erb 
5. app/views/review_mapping/select_reviewer.html.haml 
6. app/views/student_quizzes/_set_dynamic_quiz.html.erb 
7. app/views/student_review/_set_dynamic_review.html.erb 
8. config/routes.rb 
9. db/schema.rb 
10. spec/controllers/review_mapping_controller_spec.rb 
11. spec/features/assignment_creation_spec.rb 
12. spec/features/review_assignment_spec.rb 
13. spec/features/review_mapping_spec.rb 

=== ReviewMappingController ===

This controller will map the submissions made by the teams to the students for facilitating peer-reviewing. A couple of '''long''' and '''complex methods''' such as '''peer_review_strategy''' and '''automatic_review_mapping''' were refactored from this controller along with the '''removal''' of some '''non-related methods''' such as '''add_calibration''' and '''assign_quiz_dynamically'''. Variable names have been changed and code has been modularized and helper methods were separated from the important methods into a module and were included in the class.

Test Cases were created for the newly created controllers such as assign_quiz_controller etc.

=== review_mapping_controller_spec.rb ===

Added a test in this file.

=== _set_dynamic_review.html.erb & review_assignment_spec.rb & review_mapping_spec.rb & routes.rb & assignment_creation_review_strategy_spec.rb & assignment_creation_spec.rb ===

Modified due to the variable name change.

=== views/partials ===

Routes were changed in the views and partials.

==== Modified View Files: ====
app\views\review_mapping\select_reviewer.html.haml 
app/views/student_quizzes/_set_dynamic_quiz.html.erb 

== Details of the changes made==
1. A couple of long and coplex methods such as peer_review_strategy were refactored from this controller. 
       *Removed code redundancy from review_mapping_controller_spec.rb. Two variables were being initialized containing the same value. One was in the before(:each) loop and other was being called in first three test cases. 
       *Replaced the one in the before(:each) loop by @instructor = build(:instructor, id: 1) and used @instructor class variable, wherever required. 
[[File:Peer_review.png]] 

2. Changed :i_dont_care to :no_particular_topic 
       *:i_dont_care was used in the /app/views/student_review/_set_dynamic_review.html.erb as a flag to store if student is interested in any particular topic or doesn't care which topic to review. 
       *It was also used in review_mapping_controller.rb to check if student has selected any particular topic. 
       *Since, name :i_dont_care was very difficult to understand, we replaced it with something logical such as :no_particular_topic. It gives hint about what the symbol stores. 

3. Replace switch statements with subclasses methods 
       We used "check_num_reviews_args" function to represent the switch statements in "automatic review mapping" function to simply it.
       [[File:Subfunc_for_switch.png]] 

4. Create models for the subclasses 
       We created 3 modules and put relative subclasses methods in to make the controller more organized.
       [[File:3_modules.png]] 

5. Refactored Peer_review_strategy by using a helper method gen_random_participant_id 
       *A random participant_id is generated from the possible pool of candidates but the code block for that is kind of a query, i.e. it does not change or set anything. 
       *And it is equally complex enough to confuse the reader. So this has been put into a helper method with an expressive name to increase readability. 
<pre>
## Helper Method for generating a random participant which is to be used in peer_review_strategy method.
def gen_random_participant_id(iterator, participants_hash, num_participants, participants)
if iterator.zero?
rand_num = rand(0..num_participants - 1)
else
min_value = participants_hash.values.min
# get the temp array including indices of participants, each participant has minimum review number in hash table.
participants_with_min_assigned_reviews = []
participants.each do |participant|
participants_with_min_assigned_reviews << participants.index(participant) if participants_hash[participant.id] == min_value
end
# if participants_with_min_assigned_reviews is blank
no_particpants = participants_with_min_assigned_reviews.empty?
# or only one element in participants_with_min_assigned_reviews, prohibit one student to review his/her own artifact
participant_is_owner = (participants_with_min_assigned_reviews.size == 1 and TeamsUser.exists?(team_id: team.id, user_id: participants[participants_with_min_assigned_reviews[0]].user_id))
rand_num = if no_particpants or participant_is_owner
# use original method to get random number
rand(0..num_participants - 1)
else
# rand_num should be the position of this participant in original array
participants_with_min_assigned_reviews[rand(0..participants_with_min_assigned_reviews.size - 1)]
end
end
return rand_num
end
</pre>
6. Refactored automatic_review_mapping by using a helper method check_num_reviews_args 
       *Parameters such as num_reviews_per_student, num_calibrated_artifacts etc passed are first verified to check if they are in acceptable range or pattern 
       *To increase readability, the not-so good looking sets of if-else statements have been moved into check_num_reviews_args method. 
<pre>
# Helper Method to check num_reviews_per_student and num_reviews_per_submission arguments passed in by params hash.
def check_num_reviews_args(num_reviews_per_student, num_reviews_per_submission, teams)
has_error_not_raised = true
# check for exit paths first
if num_reviews_per_student == 0 and num_reviews_per_submission == 0
flash[:error] = "Please choose either the number of reviews per student or the number of reviewers per team (student)."
has_error_not_raised = false
elsif num_reviews_per_student != 0 and num_reviews_per_submission != 0
flash[:error] = "Please choose either the number of reviews per student or the number of reviewers per team (student), not both."
has_error_not_raised = false
elsif num_reviews_per_student >= teams.size
# Exception detection: If instructor want to assign too many reviews done
# by each student, there will be an error msg.
flash[:error] = 'You cannot set the number of reviews done ' \
'by each student to be greater than or equal to total number of teams ' \
'[or "participants" if it is an individual assignment].'
has_error_not_raised = false
end
end
</pre>
7. Modularized helper methods into a module and was mixed in the ReviewMappingController Class. 
       *Only some of the methods written in the class have external usage i.e called by another controllers, views etc. 
       *The other methods are just helpers and as such moved into a Helper method module and mixed in the class 
Before Modularization
<pre>
class ReviewMappingController < ApplicationController
...................
...................
512 Lines & 25 Methods Defined (After moving a few methods into separate controllers)
...................
...................
end
</pre>
After Modularization
<pre>
module Helper_methods
...................
5 Methods and 170 lines
...................
end

class ReviewMappingController < ApplicationController
include Helper_methods
...................
340 Lines & 20 Methods (All of those are used elsewhere directly in the application)
...................
end
</pre>

8. Abided to the principles of Magic Tricks of testing and did not test any internally used methods, The other tests are written were already following this principle. 
       *Internally used methods were not tested 
       *Tests for newly created controllers have been moved into a separate spec files. 

9. Isolated AssignQuizDynamically method into a separate controller as the functionality was not related to ReviewMappingController. 
       *This method assigns a quiz(Stored as an assignment object) to the participant. 
       *This method is not related to ReviewMapping functionality, so it was made into a new controller. 

10. Associated Specs/routes/views/partials have been modified to adapt the change in controllers. 
       *The controller paths present in the views/partials have to be changed to not to break the functionality 
       *The controller paths in views/partials/routes have been changed for the newly created controller of AssignQuizDynamically 

View File Affected by the creation of AssinQuizController
[[File:View.png]]

11. student_review_num sounds like a number or an id associated with a student review, while it actually stores the number of reviews that a student can perform. So it is renamed num_reviews_per_student. 
12. submission_review_num sounds like a number or an id associated with a submission review, while it actually stores the total number of reviews that can be performed on a single submission. So it is renamed num_reviews_per_submission. 
13. calibrated_artifacts_num sounds like a number or an id associated with the calibrated artifacts, while it actually stores the number of calibrated artifacts. So it is renamed num_calibrated_artifacts. Similarly, uncalibrated_artifacts_num is renamed num_uncalibrated_artifacts. 
14. participants_hash is not an appropriate name for a hash whose keys are participant ids and values are number of reviews performed by corresponding participants. So it is renamed num_reviews_by_participant_hash. 
15. Extracted a method make_review_strategy (from automatic_review_mapping_strategy) that returns a review_strategy based on the values of num_reviews_per_submission and num_reviews_per_submission. 
16. add_calibration is a method that changes the attribute of a ReviewResponseMap and has little to do with Review Mapping. So it is now put in a separate controller named ReviewResponseMapController. 
17. Added one test case and modified "select_metaviewver" to check if a mapping can be found correctly.
 [[File:Test_case.png]] 

== Test Plan ==

=== Rspec Unit Tests ===

Since this is a Refactoring Project, We made sure that the changes made did not break any functionality.

[[File:rspec_test_passed.png]]

=== Capybara Integration and Functional Tests ===

As the controller routes have been modified in the routes.rb and the other view files, there are potential chances of failures in Integration tests.

However, no such failure has been reported by Travis build.

[[File:Travis CI.png]]

[[File:FeaturesCI.png]]

== Code Coverage ==

Code Coverage for Controllers section climbed up.

[https://coveralls.io/builds/26607665] # Link for the COVERALLS stats of our pull request.

[[File:CCC1.png]]

== Project Mentor ==

Ramya Vijayakumar (rvijaya4@ncsu.edu)

== Team Members ==

Yaswanth Soodini (ysoodin@ncsu.edu)

Saurabh Shingte (svshingt@ncsu.edu)

Vivek Karri (vkarri@ncsu.edu)

== Links for Demo Videos ==

Assign Reviewer Manually Demo[https://drive.google.com/file/d/1o9vJQ7fCwk0hwHJdErwpg1z_XjsN_XRT/view?usp=sharing]

Regression and Unit Testing of Controllers Demo[https://youtu.be/XejKHQKtpuA]

Automatic Assignment of Reviewer Demo [https://drive.google.com/file/d/17wpo7mTDenLvEcgubVflLtF_vmLb623a/view?usp=sharing]

CSC/ECE 517 Fall 2021 - E2124. Refactor review mapping controller.rb

2021-10-21T02:48:21Z

Yli273: /* Details of the changes made */

This wiki page is for the description of changes made under E2124 OSS assignment for Fall 2021, CSC/ECE 517.
== About Expertiza==

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Functionality of review_mapping_controller ==
The functionality of review_mapping_controller is to provide mapping for reviewer and assignment. Basically, the controller handles assignment of reviews to different teams or single student user, such as the event of peer review and self review. Also, this controller is responsible to respond student user request for extra bonus reviews based on assignment policy.

== Problem Statement ==

The review_mapping_controller is a long and complex file. Most of the methods are sparsely commented on. Some methods are way too long to understand, please break them down into pieces for better understanding. Also, the few instances of code duplication that exist should also be removed.

== Tasks ==
-Refactor the long methods in review_mapping_controller.rb 
-Rename variable names such as student_review_num, submission_review_num, calibrated_artifacts_num, participants_hash to convey what they are actually used for 
-Replace switch statements with subclasses methods 
-Create models for the subclasses 
-Remove hardcoded parameters 

== Implementation ==
[[File:FlowchartOODD.jpg]]
 
We were tasked to refactor the review_mapping_controller.rb and solve any cascading issues or bugs we could find. We followed the above work plan to complete this task. There were many times when all the Rspec and Cucumber tests passed locally but ran into an issue when we uploaded the changes on GitHub. Prompt feedback from the TRAVIS CI helped us recognize the issue. Then we went on local machine and followed the whole process of refactoring again. In this way, we covered every refactoring we did and ensured that the TRAVIS CI get passed with minimum issues on the code-climate.

== Files modified/created in the current project ==

1. review_mapping_controller.rb 
2. review_mapping_controller_spec.rb 
3. select_reviewer.html.haml 
4. app/views/assignments/edit/_calibration.html.erb 
5. app/views/review_mapping/select_reviewer.html.haml 
6. app/views/student_quizzes/_set_dynamic_quiz.html.erb 
7. app/views/student_review/_set_dynamic_review.html.erb 
8. config/routes.rb 
9. db/schema.rb 
10. spec/controllers/review_mapping_controller_spec.rb 
11. spec/features/assignment_creation_spec.rb 
12. spec/features/review_assignment_spec.rb 
13. spec/features/review_mapping_spec.rb 

=== ReviewMappingController ===

This controller will map the submissions made by the teams to the students for facilitating peer-reviewing. A couple of '''long''' and '''complex methods''' such as '''peer_review_strategy''' and '''automatic_review_mapping''' were refactored from this controller along with the '''removal''' of some '''non-related methods''' such as '''add_calibration''' and '''assign_quiz_dynamically'''. Variable names have been changed and code has been modularized and helper methods were separated from the important methods into a module and were included in the class.

Test Cases were created for the newly created controllers such as assign_quiz_controller etc.

=== review_mapping_controller_spec.rb ===

Added a test in this file.

=== _set_dynamic_review.html.erb & review_assignment_spec.rb & review_mapping_spec.rb & routes.rb & assignment_creation_review_strategy_spec.rb & assignment_creation_spec.rb ===

Modified due to the variable name change.

=== views/partials ===

Routes were changed in the views and partials.

==== Modified View Files: ====
app\views\review_mapping\select_reviewer.html.haml 
app/views/student_quizzes/_set_dynamic_quiz.html.erb 

== Details of the changes made==
1. Changed 'instructor = build(:instructor)' to ‘@instructor = build(:instructor, id: 1)’. 
       *Removed code redundancy from review_mapping_controller_spec.rb. Two variables were being initialized containing the same value. One was in the before(:each) loop and other was being called in first three test cases. 
       *Replaced the one in the before(:each) loop by @instructor = build(:instructor, id: 1) and used @instructor class variable, wherever required. 
[[File:Peer_review.png]] 

2. Changed :i_dont_care to :no_particular_topic 
       *:i_dont_care was used in the /app/views/student_review/_set_dynamic_review.html.erb as a flag to store if student is interested in any particular topic or doesn't care which topic to review. 
       *It was also used in review_mapping_controller.rb to check if student has selected any particular topic. 
       *Since, name :i_dont_care was very difficult to understand, we replaced it with something logical such as :no_particular_topic. It gives hint about what the symbol stores. 

3. Replace switch statements with subclasses methods 
       We used "check_num_reviews_args" function to represent the switch statements in "automatic review mapping" function to simply it.
       [[File:Subfunc_for_switch.png]] 

4. Create models for the subclasses 
       We created 3 modules and put relative subclasses methods in to make the controller more organized.
       [[File:3_modules.png]] 

5. Refactored Peer_review_strategy by using a helper method gen_random_participant_id 
       *A random participant_id is generated from the possible pool of candidates but the code block for that is kind of a query, i.e. it does not change or set anything. 
       *And it is equally complex enough to confuse the reader. So this has been put into a helper method with an expressive name to increase readability. 
<pre>
## Helper Method for generating a random participant which is to be used in peer_review_strategy method.
def gen_random_participant_id(iterator, participants_hash, num_participants, participants)
if iterator.zero?
rand_num = rand(0..num_participants - 1)
else
min_value = participants_hash.values.min
# get the temp array including indices of participants, each participant has minimum review number in hash table.
participants_with_min_assigned_reviews = []
participants.each do |participant|
participants_with_min_assigned_reviews << participants.index(participant) if participants_hash[participant.id] == min_value
end
# if participants_with_min_assigned_reviews is blank
no_particpants = participants_with_min_assigned_reviews.empty?
# or only one element in participants_with_min_assigned_reviews, prohibit one student to review his/her own artifact
participant_is_owner = (participants_with_min_assigned_reviews.size == 1 and TeamsUser.exists?(team_id: team.id, user_id: participants[participants_with_min_assigned_reviews[0]].user_id))
rand_num = if no_particpants or participant_is_owner
# use original method to get random number
rand(0..num_participants - 1)
else
# rand_num should be the position of this participant in original array
participants_with_min_assigned_reviews[rand(0..participants_with_min_assigned_reviews.size - 1)]
end
end
return rand_num
end
</pre>
6. Refactored automatic_review_mapping by using a helper method check_num_reviews_args 
       *Parameters such as num_reviews_per_student, num_calibrated_artifacts etc passed are first verified to check if they are in acceptable range or pattern 
       *To increase readability, the not-so good looking sets of if-else statements have been moved into check_num_reviews_args method. 
<pre>
# Helper Method to check num_reviews_per_student and num_reviews_per_submission arguments passed in by params hash.
def check_num_reviews_args(num_reviews_per_student, num_reviews_per_submission, teams)
has_error_not_raised = true
# check for exit paths first
if num_reviews_per_student == 0 and num_reviews_per_submission == 0
flash[:error] = "Please choose either the number of reviews per student or the number of reviewers per team (student)."
has_error_not_raised = false
elsif num_reviews_per_student != 0 and num_reviews_per_submission != 0
flash[:error] = "Please choose either the number of reviews per student or the number of reviewers per team (student), not both."
has_error_not_raised = false
elsif num_reviews_per_student >= teams.size
# Exception detection: If instructor want to assign too many reviews done
# by each student, there will be an error msg.
flash[:error] = 'You cannot set the number of reviews done ' \
'by each student to be greater than or equal to total number of teams ' \
'[or "participants" if it is an individual assignment].'
has_error_not_raised = false
end
end
</pre>
7. Modularized helper methods into a module and was mixed in the ReviewMappingController Class. 
       *Only some of the methods written in the class have external usage i.e called by another controllers, views etc. 
       *The other methods are just helpers and as such moved into a Helper method module and mixed in the class 
Before Modularization
<pre>
class ReviewMappingController < ApplicationController
...................
...................
512 Lines & 25 Methods Defined (After moving a few methods into separate controllers)
...................
...................
end
</pre>
After Modularization
<pre>
module Helper_methods
...................
5 Methods and 170 lines
...................
end

class ReviewMappingController < ApplicationController
include Helper_methods
...................
340 Lines & 20 Methods (All of those are used elsewhere directly in the application)
...................
end
</pre>

8. Abided to the principles of Magic Tricks of testing and did not test any internally used methods, The other tests are written were already following this principle. 
       *Internally used methods were not tested 
       *Tests for newly created controllers have been moved into a separate spec files. 

9. Isolated AssignQuizDynamically method into a separate controller as the functionality was not related to ReviewMappingController. 
       *This method assigns a quiz(Stored as an assignment object) to the participant. 
       *This method is not related to ReviewMapping functionality, so it was made into a new controller. 

10. Associated Specs/routes/views/partials have been modified to adapt the change in controllers. 
       *The controller paths present in the views/partials have to be changed to not to break the functionality 
       *The controller paths in views/partials/routes have been changed for the newly created controller of AssignQuizDynamically 

View File Affected by the creation of AssinQuizController
[[File:View.png]]

11. student_review_num sounds like a number or an id associated with a student review, while it actually stores the number of reviews that a student can perform. So it is renamed num_reviews_per_student. 
12. submission_review_num sounds like a number or an id associated with a submission review, while it actually stores the total number of reviews that can be performed on a single submission. So it is renamed num_reviews_per_submission. 
13. calibrated_artifacts_num sounds like a number or an id associated with the calibrated artifacts, while it actually stores the number of calibrated artifacts. So it is renamed num_calibrated_artifacts. Similarly, uncalibrated_artifacts_num is renamed num_uncalibrated_artifacts. 
14. participants_hash is not an appropriate name for a hash whose keys are participant ids and values are number of reviews performed by corresponding participants. So it is renamed num_reviews_by_participant_hash. 
15. Extracted a method make_review_strategy (from automatic_review_mapping_strategy) that returns a review_strategy based on the values of num_reviews_per_submission and num_reviews_per_submission. 
16. add_calibration is a method that changes the attribute of a ReviewResponseMap and has little to do with Review Mapping. So it is now put in a separate controller named ReviewResponseMapController. 
17. Added one test case and modified "select_metaviewver" to check if a mapping can be found correctly.
 [[File:Test_case.png]] 

== Test Plan ==

=== Rspec Unit Tests ===

Since this is a Refactoring Project, We made sure that the changes made did not break any functionality.

[[File:rspec_test_passed.png]]

=== Capybara Integration and Functional Tests ===

As the controller routes have been modified in the routes.rb and the other view files, there are potential chances of failures in Integration tests.

However, no such failure has been reported by Travis build.

[[File:Travis CI.png]]

[[File:FeaturesCI.png]]

== Code Coverage ==

Code Coverage for Controllers section climbed up.

[https://coveralls.io/builds/26607665] # Link for the COVERALLS stats of our pull request.

[[File:CCC1.png]]

== Project Mentor ==

Ramya Vijayakumar (rvijaya4@ncsu.edu)

== Team Members ==

Yaswanth Soodini (ysoodin@ncsu.edu)

Saurabh Shingte (svshingt@ncsu.edu)

Vivek Karri (vkarri@ncsu.edu)

== Links for Demo Videos ==

Assign Reviewer Manually Demo[https://drive.google.com/file/d/1o9vJQ7fCwk0hwHJdErwpg1z_XjsN_XRT/view?usp=sharing]

Regression and Unit Testing of Controllers Demo[https://youtu.be/XejKHQKtpuA]

Automatic Assignment of Reviewer Demo [https://drive.google.com/file/d/17wpo7mTDenLvEcgubVflLtF_vmLb623a/view?usp=sharing]

File:Peer review.png

2021-10-21T02:47:34Z

Yli273:

File:Peer review strategy.png

2021-10-21T02:46:15Z

Yli273:

CSC/ECE 517 Fall 2021 - E2124. Refactor review mapping controller.rb

2021-10-21T02:45:47Z

Yli273: /* Details of the changes made */

This wiki page is for the description of changes made under E2124 OSS assignment for Fall 2021, CSC/ECE 517.
== About Expertiza==

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Functionality of review_mapping_controller ==
The functionality of review_mapping_controller is to provide mapping for reviewer and assignment. Basically, the controller handles assignment of reviews to different teams or single student user, such as the event of peer review and self review. Also, this controller is responsible to respond student user request for extra bonus reviews based on assignment policy.

== Problem Statement ==

The review_mapping_controller is a long and complex file. Most of the methods are sparsely commented on. Some methods are way too long to understand, please break them down into pieces for better understanding. Also, the few instances of code duplication that exist should also be removed.

== Tasks ==
-Refactor the long methods in review_mapping_controller.rb 
-Rename variable names such as student_review_num, submission_review_num, calibrated_artifacts_num, participants_hash to convey what they are actually used for 
-Replace switch statements with subclasses methods 
-Create models for the subclasses 
-Remove hardcoded parameters 

== Implementation ==
[[File:FlowchartOODD.jpg]]
 
We were tasked to refactor the review_mapping_controller.rb and solve any cascading issues or bugs we could find. We followed the above work plan to complete this task. There were many times when all the Rspec and Cucumber tests passed locally but ran into an issue when we uploaded the changes on GitHub. Prompt feedback from the TRAVIS CI helped us recognize the issue. Then we went on local machine and followed the whole process of refactoring again. In this way, we covered every refactoring we did and ensured that the TRAVIS CI get passed with minimum issues on the code-climate.

== Files modified/created in the current project ==

1. review_mapping_controller.rb 
2. review_mapping_controller_spec.rb 
3. select_reviewer.html.haml 
4. app/views/assignments/edit/_calibration.html.erb 
5. app/views/review_mapping/select_reviewer.html.haml 
6. app/views/student_quizzes/_set_dynamic_quiz.html.erb 
7. app/views/student_review/_set_dynamic_review.html.erb 
8. config/routes.rb 
9. db/schema.rb 
10. spec/controllers/review_mapping_controller_spec.rb 
11. spec/features/assignment_creation_spec.rb 
12. spec/features/review_assignment_spec.rb 
13. spec/features/review_mapping_spec.rb 

=== ReviewMappingController ===

This controller will map the submissions made by the teams to the students for facilitating peer-reviewing. A couple of '''long''' and '''complex methods''' such as '''peer_review_strategy''' and '''automatic_review_mapping''' were refactored from this controller along with the '''removal''' of some '''non-related methods''' such as '''add_calibration''' and '''assign_quiz_dynamically'''. Variable names have been changed and code has been modularized and helper methods were separated from the important methods into a module and were included in the class.

Test Cases were created for the newly created controllers such as assign_quiz_controller etc.

=== review_mapping_controller_spec.rb ===

Added a test in this file.

=== _set_dynamic_review.html.erb & review_assignment_spec.rb & review_mapping_spec.rb & routes.rb & assignment_creation_review_strategy_spec.rb & assignment_creation_spec.rb ===

Modified due to the variable name change.

=== views/partials ===

Routes were changed in the views and partials.

==== Modified View Files: ====
app\views\review_mapping\select_reviewer.html.haml 
app/views/student_quizzes/_set_dynamic_quiz.html.erb 

== Details of the changes made==
1. Changed 'instructor = build(:instructor)' to ‘@instructor = build(:instructor, id: 1)’. 
       *Removed code redundancy from review_mapping_controller_spec.rb. Two variables were being initialized containing the same value. One was in the before(:each) loop and other was being called in first three test cases. 
       *Replaced the one in the before(:each) loop by @instructor = build(:instructor, id: 1) and used @instructor class variable, wherever required. 
[[File:Peer_review_strategy.png]] 

2. Changed :i_dont_care to :no_particular_topic 
       *:i_dont_care was used in the /app/views/student_review/_set_dynamic_review.html.erb as a flag to store if student is interested in any particular topic or doesn't care which topic to review. 
       *It was also used in review_mapping_controller.rb to check if student has selected any particular topic. 
       *Since, name :i_dont_care was very difficult to understand, we replaced it with something logical such as :no_particular_topic. It gives hint about what the symbol stores. 

3. Replace switch statements with subclasses methods 
       We used "check_num_reviews_args" function to represent the switch statements in "automatic review mapping" function to simply it.
       [[File:Subfunc_for_switch.png]] 

4. Create models for the subclasses 
       We created 3 modules and put relative subclasses methods in to make the controller more organized.
       [[File:3_modules.png]] 

5. Refactored Peer_review_strategy by using a helper method gen_random_participant_id 
       *A random participant_id is generated from the possible pool of candidates but the code block for that is kind of a query, i.e. it does not change or set anything. 
       *And it is equally complex enough to confuse the reader. So this has been put into a helper method with an expressive name to increase readability. 
<pre>
## Helper Method for generating a random participant which is to be used in peer_review_strategy method.
def gen_random_participant_id(iterator, participants_hash, num_participants, participants)
if iterator.zero?
rand_num = rand(0..num_participants - 1)
else
min_value = participants_hash.values.min
# get the temp array including indices of participants, each participant has minimum review number in hash table.
participants_with_min_assigned_reviews = []
participants.each do |participant|
participants_with_min_assigned_reviews << participants.index(participant) if participants_hash[participant.id] == min_value
end
# if participants_with_min_assigned_reviews is blank
no_particpants = participants_with_min_assigned_reviews.empty?
# or only one element in participants_with_min_assigned_reviews, prohibit one student to review his/her own artifact
participant_is_owner = (participants_with_min_assigned_reviews.size == 1 and TeamsUser.exists?(team_id: team.id, user_id: participants[participants_with_min_assigned_reviews[0]].user_id))
rand_num = if no_particpants or participant_is_owner
# use original method to get random number
rand(0..num_participants - 1)
else
# rand_num should be the position of this participant in original array
participants_with_min_assigned_reviews[rand(0..participants_with_min_assigned_reviews.size - 1)]
end
end
return rand_num
end
</pre>
6. Refactored automatic_review_mapping by using a helper method check_num_reviews_args 
       *Parameters such as num_reviews_per_student, num_calibrated_artifacts etc passed are first verified to check if they are in acceptable range or pattern 
       *To increase readability, the not-so good looking sets of if-else statements have been moved into check_num_reviews_args method. 
<pre>
# Helper Method to check num_reviews_per_student and num_reviews_per_submission arguments passed in by params hash.
def check_num_reviews_args(num_reviews_per_student, num_reviews_per_submission, teams)
has_error_not_raised = true
# check for exit paths first
if num_reviews_per_student == 0 and num_reviews_per_submission == 0
flash[:error] = "Please choose either the number of reviews per student or the number of reviewers per team (student)."
has_error_not_raised = false
elsif num_reviews_per_student != 0 and num_reviews_per_submission != 0
flash[:error] = "Please choose either the number of reviews per student or the number of reviewers per team (student), not both."
has_error_not_raised = false
elsif num_reviews_per_student >= teams.size
# Exception detection: If instructor want to assign too many reviews done
# by each student, there will be an error msg.
flash[:error] = 'You cannot set the number of reviews done ' \
'by each student to be greater than or equal to total number of teams ' \
'[or "participants" if it is an individual assignment].'
has_error_not_raised = false
end
end
</pre>
7. Modularized helper methods into a module and was mixed in the ReviewMappingController Class. 
       *Only some of the methods written in the class have external usage i.e called by another controllers, views etc. 
       *The other methods are just helpers and as such moved into a Helper method module and mixed in the class 
Before Modularization
<pre>
class ReviewMappingController < ApplicationController
...................
...................
512 Lines & 25 Methods Defined (After moving a few methods into separate controllers)
...................
...................
end
</pre>
After Modularization
<pre>
module Helper_methods
...................
5 Methods and 170 lines
...................
end

class ReviewMappingController < ApplicationController
include Helper_methods
...................
340 Lines & 20 Methods (All of those are used elsewhere directly in the application)
...................
end
</pre>

8. Abided to the principles of Magic Tricks of testing and did not test any internally used methods, The other tests are written were already following this principle. 
       *Internally used methods were not tested 
       *Tests for newly created controllers have been moved into a separate spec files. 

9. Isolated AssignQuizDynamically method into a separate controller as the functionality was not related to ReviewMappingController. 
       *This method assigns a quiz(Stored as an assignment object) to the participant. 
       *This method is not related to ReviewMapping functionality, so it was made into a new controller. 

10. Associated Specs/routes/views/partials have been modified to adapt the change in controllers. 
       *The controller paths present in the views/partials have to be changed to not to break the functionality 
       *The controller paths in views/partials/routes have been changed for the newly created controller of AssignQuizDynamically 

View File Affected by the creation of AssinQuizController
[[File:View.png]]

11. student_review_num sounds like a number or an id associated with a student review, while it actually stores the number of reviews that a student can perform. So it is renamed num_reviews_per_student. 
12. submission_review_num sounds like a number or an id associated with a submission review, while it actually stores the total number of reviews that can be performed on a single submission. So it is renamed num_reviews_per_submission. 
13. calibrated_artifacts_num sounds like a number or an id associated with the calibrated artifacts, while it actually stores the number of calibrated artifacts. So it is renamed num_calibrated_artifacts. Similarly, uncalibrated_artifacts_num is renamed num_uncalibrated_artifacts. 
14. participants_hash is not an appropriate name for a hash whose keys are participant ids and values are number of reviews performed by corresponding participants. So it is renamed num_reviews_by_participant_hash. 
15. Extracted a method make_review_strategy (from automatic_review_mapping_strategy) that returns a review_strategy based on the values of num_reviews_per_submission and num_reviews_per_submission. 
16. add_calibration is a method that changes the attribute of a ReviewResponseMap and has little to do with Review Mapping. So it is now put in a separate controller named ReviewResponseMapController. 
17. Added one test case and modified "select_metaviewver" to check if a mapping can be found correctly.
 [[File:Test_case.png]] 

== Test Plan ==

=== Rspec Unit Tests ===

Since this is a Refactoring Project, We made sure that the changes made did not break any functionality.

[[File:rspec_test_passed.png]]

=== Capybara Integration and Functional Tests ===

As the controller routes have been modified in the routes.rb and the other view files, there are potential chances of failures in Integration tests.

However, no such failure has been reported by Travis build.

[[File:Travis CI.png]]

[[File:FeaturesCI.png]]

== Code Coverage ==

Code Coverage for Controllers section climbed up.

[https://coveralls.io/builds/26607665] # Link for the COVERALLS stats of our pull request.

[[File:CCC1.png]]

== Project Mentor ==

Ramya Vijayakumar (rvijaya4@ncsu.edu)

== Team Members ==

Yaswanth Soodini (ysoodin@ncsu.edu)

Saurabh Shingte (svshingt@ncsu.edu)

Vivek Karri (vkarri@ncsu.edu)

== Links for Demo Videos ==

Assign Reviewer Manually Demo[https://drive.google.com/file/d/1o9vJQ7fCwk0hwHJdErwpg1z_XjsN_XRT/view?usp=sharing]

Regression and Unit Testing of Controllers Demo[https://youtu.be/XejKHQKtpuA]

Automatic Assignment of Reviewer Demo [https://drive.google.com/file/d/17wpo7mTDenLvEcgubVflLtF_vmLb623a/view?usp=sharing]