Expertiza_Wiki - User contributions [en]

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

2021-11-30T01:20:57Z

Sguo25: /* Files Modified */

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_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==

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

2021-11-30T01:08:03Z

Sguo25: /* Files Modified */

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

==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_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==

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

2021-11-30T01:06:41Z

Sguo25: /* Files Modified */

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
*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

==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_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==

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

2021-11-30T00:58:37Z

Sguo25: /* 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===
*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===

==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_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:Gsj 5.png

2021-11-30T00:57:14Z

Sguo25:

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

2021-11-30T00:55:18Z

Sguo25: /* 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===
*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=====

=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==

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

2021-11-30T00:54:16Z

Sguo25: /* 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===
*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
*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:53:20Z

Sguo25: /* 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===
*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
*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:52:02Z

Sguo25: /* 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===
*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

*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.

====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:49:17Z

Sguo25: /* 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===
*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

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

*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

*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.

====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:35:21Z

Sguo25: /* 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===
*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:

<% 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. 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===
====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

*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.

====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:29:51Z

Sguo25: /* 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===
*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:

<% 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]]

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
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_fall2021.png|700px|thumb|center|Edit Revision Plan page demonstrating added view]]
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.
[[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]]
In the second round of review, instructor and student could see the revision plan questionnaire in a separate section.
*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===
====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

*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.

====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:22:55Z

Sguo25: /* 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===
*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:

<% 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]]

*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:Revison_planning_gsj_fall2021.png|700px|thumb|center|Edit Revision Plan page demonstrating added view]]

[[File:gsj_1.png|400px|thumb|center|Review page demonstrating added Revision Plan questions]]
[[File:gsj_2.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. 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===
====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

*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.

====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:21:33Z

Sguo25: /* 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===
*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:

<% 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, you can look into the revision plan.
[[File:211129-3.png|700px|thumb|center]]
After 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]]

*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:Revison_planning_gsj_fall2021.png"|700px|thumb|center|Edit Revision Plan page demonstrating added view]]
[[File:Revison_planning_gsj_fall2021.png".png|400px|thumb|center|Wireframe of Completing a Review for an Assignment]]
[[File:gsj_1.png|400px|thumb|center|Review page demonstrating added Revision Plan questions]]
[[File:gsj_2.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. 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===
====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

*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.

====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:19:02Z

Sguo25: /* 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===
*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:

<% 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, you can look into the revision plan.
[[File:211129-3.png|700px|thumb|center]]
After the round 2 submission, if we didn't deal with the "Revision Planning", then the "Your work" part becomes gray.
[[File:211129-4.png|700px|thumb|center]]

*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:Revison_planning_gsj_fall2021.png"|700px|thumb|center|Edit Revision Plan page demonstrating added view]]
[[File:gsj_fall2021.png|400px|thumb|center|Wireframe of Completing a Review for an Assignment]]
[[File:gsj_1.png|400px|thumb|center|Review page demonstrating added Revision Plan questions]]
[[File:gsj_2.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. 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===
====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

*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.

====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:Gsj 3.png

2021-11-30T00:17:57Z

Sguo25:

File:Gsj 2.png

2021-11-30T00:17:36Z

Sguo25:

File:Gsj 1.png

2021-11-30T00:17:14Z

Sguo25:

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

2021-11-30T00:15:15Z

Sguo25: /* 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===
*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:

<% 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, you can look into the revision plan.
[[File:211129-3.png|700px|thumb|center]]
After the round 2 submission, if we didn't deal with the "Revision Planning", then the "Your work" part becomes gray.
[[File:211129-4.png|700px|thumb|center]]

*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:Revison_planning_gsj_fall2021.png"|700px|thumb|center|Edit Revision Plan page demonstrating added view]]
[[File:gsj_fall2021.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===
====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

*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.

====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:Gsj fall2021.png

2021-11-30T00:14:04Z

Sguo25:

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

2021-11-30T00:10:15Z

Sguo25: /* 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===
*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:

<% 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, you can look into the revision plan.
[[File:211129-3.png|700px|thumb|center]]
After the round 2 submission, if we didn't deal with the "Revision Planning", then the "Your work" part becomes gray.
[[File:211129-4.png|700px|thumb|center]]

*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:Revison_planning_gsj_fall2021.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===
====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

*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.

====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:Revison planning gsj fall2021.png".png

2021-11-30T00:08:24Z

Sguo25: fal2021

fal2021

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

2021-11-30T00:04:13Z

Sguo25: /* 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===
*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:

<% 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, you can look into the revision plan.
[[File:211129-3.png|700px|thumb|center]]

*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:Revison_planning_exists_in_the_second_round.png".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===
====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

*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.

====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:Revison planning exists in the second round.png

2021-11-29T23:59:04Z

Sguo25:

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

2021-11-29T23:44:46Z

Sguo25: /* Goals */

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 at 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:

<% 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]]

*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===
====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

*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.

====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-29T21:48:04Z

Sguo25: /* 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 1st review phase.
*Set up an assignment with 2 rounds of review.
*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|410px|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===
====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

*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.

====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-06T22:23:10Z

Sguo25: /* Test Plan */

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===
====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:ini1.png|700px|thumb|center|Reviews cannot be done during the submission phase]]

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

=====Implementation=====

=Test Plan=

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

Controllers

*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.

====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-06T22:22:34Z

Sguo25: /* Manual 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===
*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===
====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:ini1.png|700px|thumb|center|Reviews cannot be done during the submission phase]]

=====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====
The RSpec tests are written to test both controller and models.

Controllers

*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.

====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-06T22:00:40Z

Sguo25: /* 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===
*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====
The RSpec tests are written to test both controller and models.

Controllers

*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.

====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:58:47Z

Sguo25: /* 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===
*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====
The RSpec tests are written to test both controller and models.

Controllers

*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

====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:58:34Z

Sguo25: /* 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===
*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====
The RSpec tests are written to test both controller and models.

*Controllers

*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

====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:58:17Z

Sguo25: /* 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===
*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====
The RSpec tests are written to test both controller and models.

*Controllers

*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

====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:57:22Z

Sguo25: /* 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===
*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====
*The RSpec tests are written to test both controller and models.

*Controllers

*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

====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:04Z

Sguo25: /* Test Plan */

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

2021-11-03T15:47:58Z

Sguo25: /* Test Plan */