CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

Introduction - Purpose & Problem

Currently, reviews of other student’s work can only be performed by individual students in Expertiza, not by groups of students. Since doing reviews together could help students learn more than by doing them alone, it has been requested that reviews must now have the option to be done by teams instead of individual participants. Therefore, there should be an option when creating assignments that allows the creator to select whether the assignment will use team reviewers or individual reviewers. For simplification, we were allowed to assume that the teams that worked on an assignment together would review together. Each participant should be able to make individual changes to the review (while logged in from their account), but these changes should apply to the team’s collective review. This creates an issue where teammates could accidentally overwrite each other’s work if they edit the review at once. Therefore, it has been decided that the review should be locked while one edits it so that only one participant can edit it at once. Locking the review presents its own challenges.

Proposed Solution

• Modification to Response Map Classes
  • A field should be added to ResponseMap which indicates whether responses are done by teams or by individuals.
• Modification to Assignment Class
  • A field indicating if the assignment is to be done with team or individuals. This is necessary because part of the suggested requirements is to add a drop down on the review strategy section of the assignment.
• Locking Solution
  • Research needs to be done as to whether a rails mechanism already exists to facilitate a lock on page edits
  • A solution can be implemented from scratch by storing a flag in the database on the review’s table entry. This would require an additional migration.
  • The ability to have a lock on a review requires the implementation of some kind of auto-unlock feature. If a user never unlocks a review, his/her teammates still need to be able to modify the review.
    • We should be able to use the “updated at” field to check if the lock has been held for too long and needs to be released.

Changes to Code

• review_response_map.rb (migration required)
  • Field - reviewer_is_team: boolean
• review_mapping_controller.rb - update the following methods to use AssignmentTeam as well as AssignmentParticipant as the reviewer
  • automatic_review_mapping()
  • add_calibration()
  • assign_reviewer_dynamically()
  • get_reviewer()
• assignment.rb (migration required)
  • Field - has_team_reviews: boolean
• assignment_controller.rb
  • update new() and create() methods to handle new field has_team_reviews
• assignment ui files - add check box for has_team_reviews

Changes Represented in UML

UI Changes

Assignment Review Strategy

Before

After

Assign Reviewers

Before

After

Test Plan

Rspec

Our primary purpose for rspec testing will involve ensuring that we haven't broken any existing functionality. Since our new functionality doesn't involve any model/view/controller additions, our tests will be appended to existing rspec tests inside of:

• assignments_controller_spec.rb
• response_controller_spec.rb
• review_mapping_controller_spec.rb

The new functionality we need to test should primarily ensure that:

• Students on the same team can see each other's review responses
• No two students can edit a review at the same time
• Reviews submitted by teams are treated identically to reviews submitted by individuals