CSC/ECE 517 Spring 2016 E1631 Team-based reviewing: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 1: Line 1:
== Purpose ==
== Purpose ==
When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.


*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .  
*Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .  

Revision as of 00:18, 3 April 2016

Purpose

When a participant of a team reviewed an assignment, his/her review is independent of his teammate’s reviews. To allow teammates to discuss and review together, allowing teams to submit reviews for the team as a whole should be allowed ideally. We intend to do this in our project.

  • Currently all reviews in Expertiza are done by individuals. This is true regardless of whether the assignment is done by individuals or teams .
  • There are occasions when it's advantageous to review projects as a team .
  • It helps foster discussion and thereby improves the process of learning.

Task Description

This project comprises of the following steps :

  1. Add fields to the ResponseMap model to record who reviews whom. The field reviewee_id refers to the team who is being reviewed. The field reviewer_id refers to the individual/team performing the review.
  2. Add a boolean field reviewer_is_team to identify if the review is performed by a team or an individual.
  3. If reviewer_is_team is true, the reviewer_id will be a reference to the Teams table. Else, it will be a reference to the Participants table.
  4. For an Instructor to specify whether the review is a Team/Individual based review, provide a checkbox on the Review Strategy tab of assignment creation.

Design

Use Case Diagram

Name: Specify review type on Review Strategy tab.

Actor: Instructor.

Description: The instructor specifies whether this review is an individual review or a team based review on the Review Strategy tab.


Name: Perform Review.

Actor: Individual Student/Team.

Description: The individual/team will perform a review for the Assignment.

Database Design

ResponseMap in essence, records who reviews whom. Schema of ResponseMap:

Field Data type
id int(11)
reviewed_object_id int(11)
reviewer_id int(11)
reviewee_id int(11)
type varchar(255)
created_at datetime
updated_at datetime
caliberate_to boolean
reviewer_is_team boolean

The description of the fields of the database for ResponseMap:

1. id: The unique record identifier.

2. reviewed_object_id: The id of the object that is reviewed. Assignments or ReviewMaps could be reviewed.

3. reviewer_id: The reviewer can either be an “AssignmentTeam” or “AssignmentParticipant”, which is indicated by the field reviwer_is_team.

4. reviewee_id: The id “AssignmentTeam” who is getting the “Response” i.e., the one whose work is being reviewed.

5. type : Indicates the type of the ResponseMap.

6. created_at: The timestamp when the Response was created.

7. updated_at: The timestamp when the Response was updated.

8. calibrate_to: A field of boolean data type.

9. reviewer_is_team: If this field is ‘true’, the reviewer_id refers to the id of the “AssignmentTeam” to which the participant belongs. Else, it refers to the id of the “Participant” itself.

Key files to be modified

Models

  • review_response_map.rb
  • participant.rb
  • response_map.rb
  • response.rb
  • assignment_team.rb
  • assignment_participant.rb
  • assignment.rb

Views

  • review_mapping/_review_report.html.erb

Controllers

  • review_mapping_controller.rb
  • participants_controller.rb