CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing: Difference between revisions
Line 8: | Line 8: | ||
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.<br> | 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.<br> | ||
2. Student participants of the assignment should be able to ask for a review for their team.<br> | 2. Student participants of the assignment should be able to ask for a review for their team.<br> | ||
3. Participants of the team should not be allowed to edit a review simultaneously.<br> | 3. Participants of the team should not be allowed to edit a review simultaneously. We can use ActiveRecord record locking method to lock the current record being edited. This will work the same way in individual and team reviews. One can also use ActiveRecord::Base#lock! method to lock one record by id. This may be better if you don't need to lock every row. Example:<br> | ||
4. A new field reviewer_is_team? should be added to the Assignments table to determine whether the reviewer is an AssignmentParticipant or an AssignmentTeam. | <pre> | ||
Account.transaction do | |||
# select * from accounts where ... | |||
accounts = Account.where(...) | |||
account1 = accounts.detect { |account| ... } | |||
account2 = accounts.detect { |account| ... } | |||
# select * from accounts where id=? for update | |||
account1.lock! | |||
account2.lock! | |||
account1.balance -= 100 | |||
account1.save! | |||
account2.balance += 100 | |||
account2.save! | |||
end | |||
</pre> | |||
4. A new field reviewer_is_team? should be added to the Assignments table to determine whether the reviewer is an AssignmentParticipant or an AssignmentTeam. We will be adding the reviewer_is_team? to the Assignments table 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.<br> | |||
5. Finally, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br> | 5. Finally, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br> | ||
Revision as of 22:30, 12 November 2017
Introduction
Motivation
Traditionally, only single 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 reviews 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. Student participants of the assignment should be able to ask for a review for their team.
3. Participants of the team should not be allowed to edit a review simultaneously. We can use ActiveRecord record locking method to lock the current record being edited. This will work the same way in individual and team reviews. One can also use ActiveRecord::Base#lock! method to lock one record by id. This may be better if you don't need to lock every row. Example:
Account.transaction do # select * from accounts where ... accounts = Account.where(...) account1 = accounts.detect { |account| ... } account2 = accounts.detect { |account| ... } # select * from accounts where id=? for update account1.lock! account2.lock! account1.balance -= 100 account1.save! account2.balance += 100 account2.save! end
4. A new field reviewer_is_team? should be added to the Assignments table to determine whether the reviewer is an AssignmentParticipant or an AssignmentTeam. We will be adding the reviewer_is_team? to the Assignments table 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.
5. Finally, functionality should be provided to allow Team reviews by connecting everything as mentioned above.
Files Involved
1. response_map.rb
2. response_controller.rb
3. review_mapping_controller.rb
4. 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 of 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 assignment with review strategy as "Team Reviews".
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:
Test Plan
Testing of the new controller methods to check whether all the functionality of reviewing as a participant is also working for the scenario when reviewing is done by a team.
Team Information
Aditya Shah
Amey Deshmukh
Deepak Kalro
Philip Musyoki