CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing: Difference between revisions
| Line 54: | Line 54: | ||
... | ... | ||
</pre> | </pre> | ||
5. We will be adding the reviewer_is_team? to the Assignments model (assignment.rb) instead of the Response Map as suggested in the project requirements. This is because if the checking is done on the Response Map, then it will have to be updated for every response and round. Thus a column will have to added to multiple places unnecessarily which is not a good design decision. Hence our solution incorporates the addition of reviewer_is_team? to the Assignment model. | |||
<br> | <br> | ||
Revision as of 23:21, 1 December 2017
Introduction
Motivation
Traditionally, only individuals have been able to perform assignment reviews in Expertiza. Over the years, it has been observed that it would be more desirable if assignment setters could define how a specific assignment could be reviewed. One of the ways will be by an individual, and a new way of reviews will be by teams. The same teams formed for the assignment would be able to participate in reviewing peer assignments.
The benefits of peers review are numerous, and there is an additional benefit of reviews by teams. In general, we may be getting to a point where traditional individual reviews are becoming ineffective, often missing nuances in an assignments details and concepts. It is a general belief that team-based reviews will address this, often pooling together resources from multiple reviewers working as a team to form a one cohesive and often comprehensive review. On the flip-side, it may be difficult sometimes for all team members to meet to perform reviews, and this may either delay reviews or curtail them. Ultimately, it is felt that the advantages of team-based reviews far outweigh any inherent shortcomings.
Changes to be Implemented
1. A new button to select Reviewers as a team will be provided at the Assignments Edit page in the Review Strategy tab for the instructors.
2. Any member of a team should be able to select a review to be done by their team.
3. Team members should not be allowed to edit a review simultaneously. We can use ActiveRecord locking method to lock the current record being edited.
4. A new field reviewer_is_team? should be added to the Assignments table to record whether the reviewer is an AssignmentParticipant or an AssignmentTeam.
5. A new field team_id should be added to the ResponseMaps table which records the team_id when the reviewer_is_team? check-box is checked otherwise the default value is nil.
6. The reviews in the database should be deleted when the instructor decides to the change the 'Review Strategy' midway in the assignment.
In summary, functionality should be provided to allow Team reviews by connecting everything as mentioned above.
Approach
1. The first change is a simple view change. The checkbox will added in "assignments/edit/_review_strategy.html.erb". The checkbox value will be passed to the response_controller and depending on the value of the checkbox, the response_map will be created.
2. This change will be made in the "response_map.rb" model. This model creates all the mapping between the reviewers and reviewees. In Expertiza, all reviewees are AssignmentTeams, even in a non-team assignment where each team consists of a single participant. However, with this project, reviewers can be either participants or teams. Thus, we still need to create a proper mapping between reviewers and reviewees for our new feature.
3. When the first member of the team asks for a review, a ResponseMap is created with the team_id field populated by the team_id of this participant for that particular assignment. When other's member of the team login and go to 'other's work', they should be seeing the same ResponseMap as we will be checking the team_id field of the ResponseMap table instead of the reviewer_id.
...
if @reviewer_team_info[:reviewer_is_team_member]
@review_mappings = ReviewResponseMap.where(team_id: @reviewer_team_info[:team_id])
@team = Team.find(@reviewer_team_info[:team_id])
else
@review_mappings = ReviewResponseMap.where(reviewer_id: @participant.id)
end
...
If the assignment is not reviewed by teams, then that ResponseMap is fetched from the database where reviewer_id = particpant_id.
4. If a review is being is being edited, that review should not be edited by other team members. In case of individual reviewers, no other reviewer can be editing the same review. Thus, once a review is being edited, we can lock the record, irrespective of reviewers are teams or individual participants. We will use ActiveRecord::Base#lock! method to lock one record by id. In the "/app/view/student_review/_responses.html.erb" view, when the student clicks on "edit" button, the reviewer_id will be passed to the edit method in response_controller. Thus, in the "edit" method in response_controller, we find the response record being edited and then we can lock it using the following lines of code:
... @response = Response.find(params[:id]) @response.lock! ...
Once the record is locked, it can only be changed by the person who is currently working on it. Once the person "saves" the review, the record will be unlocked. This unlocking will be done in the "saving" method of the response_controller. We can unlock a ".lock!" record by using the ".save!" method. Once unlocked the other team members will be able to edit this record. Pseudocode:
... @response = Response.find(params[:id]) @response.save! ...
5. We will be adding the reviewer_is_team? to the Assignments model (assignment.rb) instead of the Response Map as suggested in the project requirements. This is because if the checking is done on the Response Map, then it will have to be updated for every response and round. Thus a column will have to added to multiple places unnecessarily which is not a good design decision. Hence our solution incorporates the addition of reviewer_is_team? to the Assignment model.
Files Involved
1. response_map.rb
2. assignment.rb
3. response_controller.rb
4. review_mapping_controller.rb
5. assignments/edit/_review_strategy.html.erb
Design Principles to be Followed
1. MVC - The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view, and controller, respectively).
2. DRY Principle - We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.
3. Polymorphism - We will use polymorphism to provide a single interface to entities of different types. In Expertiza, individual and team-based reviewers will share one single interface.
Use Case
1. Name: Teams submitting reviews for assignment or topic
2. Actor: Student (as member of a team)
3. Other Participants: Team Members
4. Precondition: Instructor has set up an assignment with review strategy as "Team Reviews". This assignment also has only teams. No students can participate as an individual. Thus, when a participant is added to the assignment, s/he will be added as a single member team. Thus, in the diagram above, the participant is a single member team.
5. Primary Sequence:
UI Changes
1. Currently there is no team reviewing in Expertiza. Thus, we will provide a check-box, in the review strategy tab of edit assignments, for the instructor. Checking this box will set the reviewers to teams, rather than individual participants.
Current Implementation is as follows:
New Implementation will be as shown below:
2. By default, the reviewers will be individual students. When they request reviews, they request reviews for themselves. If the instructor changes the reviewers to teams, then each participant (who is member of some team), will request reviews on behalf of the entire team.
If the assignment has individual reviews:
If the assignment has team reviews:
Select a new submission for your team to review.
Test Plan
The Assignments functions; including creation, updating, saving and modifying methods have already been tested, and our test plan will only deal with testing for the new team-based reviewing functionality we are adding. Our test plan will include the following test methods:
1. If the review for the Assignment will have team id instead of the participant id in Response Map.
2. If for an assignment the instructor can successfully apply the reviewer_is_team? attribute.
3. If while a review is being edited by a team member, the other team members should not be given access to edit the same review.
4. If the team based reviewing functionality works in flow with the student based reviewing.
Team Information
Aditya Shah
Amey Deshmukh
Deepak Kalro
Philip Musyoki