Expertiza_Wiki - User contributions [en]

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

2021-12-09T15:58:16Z

Hchen63: /* Initial Wireframe */

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

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

The UI workflow test are shown in this video:
https://www.youtube.com/watch?v=d0bukq6o2sc

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

==References==
*Pull Request: https://github.com/expertiza/expertiza/pull/2152
*GitHub Repository: https://github.com/YiLi98317/expertiza
*Deployment: http://152.7.176.63:8080/
*Video: https://www.youtube.com/watch?v=d0bukq6o2sc

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

2021-12-09T15:57:51Z

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

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

The UI workflow test are shown in this video:
https://www.youtube.com/watch?v=d0bukq6o2sc

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

==References==
*Pull Request: https://github.com/expertiza/expertiza/pull/2152
*GitHub Repository: https://github.com/YiLi98317/expertiza
*Deployment: http://152.7.176.63:8080/
*Video: https://www.youtube.com/watch?v=d0bukq6o2sc

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

2021-12-09T15:55:33Z

Hchen63: /* RSpec Testing */

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

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

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

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

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

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

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

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

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

=Proposed Solution=

===Implementation===

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

Changes:

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

past code:

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

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

Result:

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

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

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

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

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

After:
app/models/team.rb

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

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

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

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

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

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

=====Implementation=====

=Test Plan=

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

Controllers

*rspec spec/controllers/grades_controller_spec.rb
*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?

The UI workflow test are shown in this video:
https://www.youtube.com/watch?v=d0bukq6o2sc

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

==References==
*Pull Request: https://github.com/expertiza/expertiza/pull/2152
*GitHub Repository: https://github.com/YiLi98317/expertiza
*Deployment: http://152.7.176.63:8080/
*Video: https://www.youtube.com/watch?v=d0bukq6o2sc

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

2021-12-09T15:54:01Z

Hchen63: /* References */

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

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

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

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

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

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

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

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

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

=Proposed Solution=

===Implementation===

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

Changes:

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

past code:

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

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

Result:

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

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

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

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

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

After:
app/models/team.rb

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

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

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

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

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

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

=====Implementation=====

=Test Plan=

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

Controllers

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

Models

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

Helpers

*rspec spec/heplers/grades_helper.rb

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

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

The UI workflow test are shown in this video:
https://www.youtube.com/watch?v=d0bukq6o2sc

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

==References==
*Pull Request: https://github.com/expertiza/expertiza/pull/2152
*GitHub Repository: https://github.com/YiLi98317/expertiza
*Deployment: http://152.7.176.63:8080/
*Video: https://www.youtube.com/watch?v=d0bukq6o2sc

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

2021-12-09T15:53:24Z

Hchen63: /* References */

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

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

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

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

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

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

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

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

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

=Proposed Solution=

===Implementation===

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

Changes:

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

past code:

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

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

Result:

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

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

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

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

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

After:
app/models/team.rb

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

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

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

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

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

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

=====Implementation=====

=Test Plan=

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

Controllers

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

Models

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

Helpers

*rspec spec/heplers/grades_helper.rb

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

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

The UI workflow test are shown in this video:
https://www.youtube.com/watch?v=d0bukq6o2sc

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

==References==
*Pull Request: https://github.com/expertiza/expertiza/pull/2152
*GitHub Repository: https://github.com/YiLi98317/expertiza
*Deployment: http://152.7.176.63:8080/

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

2021-12-09T15:53:05Z

Hchen63: /* References */

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

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

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

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

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

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

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

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

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

=Proposed Solution=

===Implementation===

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

Changes:

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

past code:

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

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

Result:

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

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

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

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

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

After:
app/models/team.rb

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

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

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

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

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

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

=====Implementation=====

=Test Plan=

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

Controllers

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

Models

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

Helpers

*rspec spec/heplers/grades_helper.rb

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

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

The UI workflow test are shown in this video:
https://www.youtube.com/watch?v=d0bukq6o2sc

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

==References==
Pull Request: https://github.com/expertiza/expertiza/pull/2152
Github Repository: https://github.com/YiLi98317/expertiza
Deployment: http://152.7.176.63:8080/

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

2021-12-09T15:52:52Z

Hchen63: /* References */

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

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

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

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

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

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

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

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

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

=Proposed Solution=

===Implementation===

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

Changes:

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

past code:

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

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

Result:

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

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

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

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

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

After:
app/models/team.rb

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

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

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

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

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

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

=====Implementation=====

=Test Plan=

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

Controllers

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

Models

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

Helpers

*rspec spec/heplers/grades_helper.rb

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

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

The UI workflow test are shown in this video:
https://www.youtube.com/watch?v=d0bukq6o2sc

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

==References==
Pull Request: https://github.com/expertiza/expertiza/pull/2152 /n
Github Repository: https://github.com/YiLi98317/expertiza /n
Deployment: http://152.7.176.63:8080/ /n

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

2021-12-09T15:52:39Z

Hchen63: /* References */

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

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

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

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

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

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

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

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

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

=Proposed Solution=

===Implementation===

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

Changes:

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

past code:

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

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

Result:

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

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

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

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

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

After:
app/models/team.rb

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

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

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

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

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

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

=====Implementation=====

=Test Plan=

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

Controllers

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

Models

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

Helpers

*rspec spec/heplers/grades_helper.rb

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

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

The UI workflow test are shown in this video:
https://www.youtube.com/watch?v=d0bukq6o2sc

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

==References==
Pull Request: https://github.com/expertiza/expertiza/pull/2152 \n
Github Repository: https://github.com/YiLi98317/expertiza \n
Deployment: http://152.7.176.63:8080/ \n

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

2021-12-09T15:52:02Z

Hchen63: /* References */

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

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

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

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

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

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

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

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

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

=Proposed Solution=

===Implementation===

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

Changes:

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

past code:

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

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

Result:

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

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

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

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

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

After:
app/models/team.rb

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

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

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

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

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

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

=====Implementation=====

=Test Plan=

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

Controllers

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

Models

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

Helpers

*rspec spec/heplers/grades_helper.rb

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

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

The UI workflow test are shown in this video:
https://www.youtube.com/watch?v=d0bukq6o2sc

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

==References==
Pull Request: https://github.com/expertiza/expertiza/pull/2152
Github Repository: https://github.com/YiLi98317/expertiza
Deployment: http://152.7.176.63:8080/

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

2021-12-09T15:50:44Z

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

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

=Proposed Solution=

===Implementation===

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

Changes:

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

past code:

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

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

Result:

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

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

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

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

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

After:
app/models/team.rb

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

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

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

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

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

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

=====Implementation=====

=Test Plan=

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

Controllers

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

Models

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

Helpers

*rspec spec/heplers/grades_helper.rb

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

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

The UI workflow test are shown in this video:
https://www.youtube.com/watch?v=d0bukq6o2sc

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

==References==

File:E2152 Rationale.png

2021-12-09T15:42:18Z

Hchen63: Hchen63 uploaded a new version of File:E2152 Rationale.png

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

2021-12-02T02:58:02Z

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

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

=Proposed Solution=

===Implementation===

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

Changes:

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

past code:

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

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

Result:

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

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

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

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

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

After:
app/models/team.rb

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

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

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

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

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

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

=====Implementation=====

=Test Plan=

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

Controllers

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

Models

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

Helpers

*rspec spec/heplers/grades_helper.rb

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

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

==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-09T22:53:49Z

Hchen63: /* Rationale */

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

=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-09T22:53:41Z

Hchen63: /* Rationale */

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

*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-09T22:53:33Z

Hchen63: /* Rationale */

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

=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-09T22:53:05Z

Hchen63: /* Rationale */

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

*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-09T22:52:56Z

Hchen63: /* Rationale */

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

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

=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-09T22:14:16Z

Hchen63: /* 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===
*Let the authors be able to edit the revision plan during the 1st 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: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

*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:E2152 Rationale.png

2021-11-09T22:13:03Z

Hchen63: Hchen63 uploaded a new version of File:E2152 Rationale.png

File:E2152 Revision Plan avaliable.png

2021-11-06T22:18:59Z

Hchen63: Hchen63 uploaded a new version of File:E2152 Revision Plan avaliable.png

File:E2152 Revision Plan avaliable.png

2021-11-06T22:16:51Z

Hchen63: Hchen63 uploaded a new version of File:E2152 Revision Plan avaliable.png

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

2021-11-06T22:16:32Z

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

=====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====
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:16:18Z

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

=====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====
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|400px|center]]
[[File:E2152_Revision_Plan_unavaliable.png|400px|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:E2152 Revision Plan unavaliable.png

2021-11-06T22:08:12Z

Hchen63:

File:E2152 Revision Plan avaliable.png

2021-11-06T22:07:59Z

Hchen63:

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

2021-11-06T22:07:50Z

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

=====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====
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|400px|center]]
[[File:E2152_Revision Plan unavaliable.png|400px|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:06:41Z

Hchen63: /* 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===
====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:ini1.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====
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.

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

Hchen63: /* Introduction */

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

2021-11-06T21:37:35Z

Hchen63: /* Rationale */

File:E2152 Rationale.png

2021-11-06T21:34:52Z

Hchen63:

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

2021-11-06T21:34:33Z

Hchen63: /* Rationale */

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

2021-11-06T21:33:31Z

Hchen63: /* Control Flow Diagram */

File:E2152 Problem Statement.png

2021-11-06T20:54:22Z

Hchen63: Hchen63 uploaded a new version of File:E2152 Problem Statement.png

File:E2152 Problem Statement.png

2021-11-06T20:53:56Z

Hchen63: Hchen63 uploaded a new version of File:E2152 Problem Statement.png

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

2021-11-06T20:35:32Z

Hchen63: /* Goals */

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

2021-11-06T20:24:24Z