CSC/ECE 517 Fall 2021 - E2152. Revision planning tool
This page provides a description of the Expertiza based OSS project.
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.
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 E1875, once in E2016 and another one in 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
team_id
field to each question is intuitive. However, they failed to come up with a clean implementation of this idea. Specifically, they had passed some trailing parameters several methods down before reaching the place that needs them.
Problems with Previous Implementation
- Students cannot edit the revision plan in the review phase so the review doesn't get changed while other students are reviewing. However, it assumes that reviews cannot be done during the submission phase. Code needs to be written to take care of this part.
- Set up an assignment with 2 rounds of review.
- Allow editing the revision-planning rubric just like editing a normal rubric, using a shared template.
- Instructors and students can view the review report with the revision plan placed in a separate section.
- In RevisionPlanQuestionnairesController, the method for determining who's on a team would be better located in team.rb.
- The current_round method duplicates a method elsewhere in the system.
- The generate_heatgrid has too many conditional statements. It would be better to split it into smaller methods.
- A lot of code deals with score calculations, which shouldn't be a concern for this project.
- Too many files are involved, although they seem to make reasonable decisions about their changes.
- The code should have more comments.
- The team had a good initial design but took as twice much as LoC compared to the previous teams.
Goals
- Force the student to add revision plan before submit their work at round 2 submission.
- Set up an assignment with 2 rounds of review.
- In the second round of review, the revision plan questionnaire can be seen in a separate section.
- Relocate the method for determining who's on a team in RevisionPlanQuestionnairesController to team.rb.
Rationale
The general workflow is shown bellow.
Proposed Solution
Implementation
- 1. Force the students to add revision plan before submit their work at round 2 submission
The revision plan cannot be operated in all of the phases but before round 2 submission. In the round 2 submission, the "Your Work" part cannot be chosen only if you finish to edit the "Revision Planning" part. By doing this, we can let students add revision plan before submit their work at round 2 submission.
Changes:
Change the logic, before the round 2 submission, there is no need to judge, directly let the "Revision planning" part invalid. And when it comes to the round 2 submission, the "Your Work" part is invalid, and the "Revision planning" part can be edited.
past code:
<% if @assignment.submission_allowed(@topic_id) %>
modified code:
<% if (!@can_submit_revision_plan && @assignment.submission_allowed(@topic_id)) || (@can_submit_revision_plan && @revision_plan_questionnaire_id && @assignment.submission_allowed(@topic_id)) %>
Result:
Firstly, before the round 2 submission, you can look into your work, but the revision plan.
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.
After editing the "Revision Planning", we can submit our work.
- 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.
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.
- 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.
- 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.
- 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.
Changes:
- In the assignment table we have added
is_revision_planning_enabled?
column to indicate whether the assignment accepts a revision plan along with review rubric. RevisionPlanTeamMap
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.RevisionPlanQuestionnaire
extendsQuestionnaire
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
Final UI
Implementation
- change the conditions for submission, which means the second round of assignment cannot be submitted without revision_plan being subbmited first
app/views/student_task/view.html.erb before <% if @assignment.submission_allowed(@topic_id) %> after <% if (!@can_submit_revision_plan && @assignment.submission_allowed(@topic_id)) || (@can_submit_revision_plan && @revision_plan_questionnaire_id && @assignment.submission_allowed(@topic_id)) %>
Test Plan
RSpec Testing
The RSpec tests are written to test both controller and models.
Controllers
- spec/controllers/response_controller_spec.rb: Updated spec by stubbing get_questions method to pass.
- spec/controllers/revision_plan_questionnaires_controller_spec.rb: Updated spec by adding four examples to test revision plan questionnaires controller
- spec/factories/revision_plan_factory.rb: Create a new factory.rb to create objects unique to revision plans, including RevisionPlanQuestionnaire RevisionPlanTeamMap
Models
- spec/models/response_spec.rb: Updated spec by updating expected html output to pass.
- spec/models/review_response_map_spec.rb: Updated spec by updating expected html output to pass.
Manual Testing
Manual testing aims to verify the following:
- Can an assignment with revision planning enabled be created?
- Can an assignment with 2 rounds of review be set up?
- If the revision-planning rubric can be edited or not?
- Is the revision plan a separate section?
- Does the method determining the members of a team existed in team.rb?
- Dose the system have redundant functions?
- Are participants allowed to create/edit revision plan when round 1+ (1 or greater than 1) reviews have finished?
- Is revision plan editing disabled when assignment is in review stage?
- Are reviewers shown questions created by reviewees?
- Does participants show summary of score for revision plan after review deadline has expired?
Since we are still working on our project, the following is part of our UI testing.
1. Go to the overview page of the assignment, the revision planning should only be available at 1st review phase.
Team Members
Kai Gao (kgao2@ncsu.edu)
Huangxing Chen (hchen63)
Yi Li (yli273)
Shengjie Guo (sguo25)
Mentor: Nicholas Himes (nnhimes@ncsu.edu)