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.

Previous Implementations

Revision planning has been implemented twice before, once in E1875 and once in E2016. 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.

Goals

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

Team Members

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