Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-12-04T17:23:52Z

Adeshmu: /* Test Plan */

==='''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<br>

2. Any member of a team should be able to select a review to be done by their team.<br>

3. Team members should not be allowed to edit a review simultaneously.<br>

4. The responses as well as the response_maps in the database should be deleted when the instructor decides to the change the 'Review Strategy' after the reviews have already started. <br>

In summary, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

==Database Migrations==
We will add the following fields in existing models of the Expertiza.

1. To assign team based reviewing attribute to the assignemnts a new boolean field reviewer_is_team was added to the with the default set to false.

2. To create a common response for all the team members we added a team_id field to the ResponseMap model. This identifies the reviewer team.

3. To prevent concurrent editing of the reviews by the team members we lock the response in the ResponseMap. This is check is based on the new is_locked field.

4. To identify the user who has locked the review we have also added a locked_by field in the ResponseMap which carries the current_user.id.

[[File:Db_migr13.png|centre]]

==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. The default value for the checkbox is "false". Thus, it will not break any existing functionality.
<pre>
...

<tr id="reviewer_is_team">
<td>
<input name="assignment_form[assignment][reviewer_is_team]" type="hidden" value="false"/>
<%= check_box_tag('assignment_form[assignment][reviewer_is_team]', 'true', @assignment_form.assignment.reviewer_is_team) %>
<%= label_tag('assignment_form[assignment][reviewer_is_team]', 'Reviews are to be performed by teams.') %>
</td>
</tr>
...
</pre>
<br>

2. For this feature to work we must create correct mappings. 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. In our design we are creating only one ResponseMap per team, i.e if the "reviewer_is_team" is set by the instructor, the ResponseMap created will have the reviewer_id as the participant_id of the requesting student and the team_id as the id of requesting students team in that assignment. Now to map this single response to all students in a team, we changed the strategy which returns response_mappings, in the "student_review_controller", for a particular reviewer. If the assignment has team_reviewers, then we find the responses by "team_id", and if there are no team reviewers for the assignment then we return responses by matching the "reviewer_id". Thus, if our mappings are created correctly, then the entire team will be directed to a single response_map and thus a single response irrespective of who requests the review. Thus, any of the team members will be able to request reviews as as the mappings will created with the team_id. The reason for us to not set the "reviewer_id" null or 0 for team reviewers is that, some of the functionalities like number of reviews, scores are all mapped to a single participant. Thus, if that is set that to any value, we will have to define all new methods for team reviewers. But, now we can use all those functions on our response and then make that same response object available to all members of the team. By doing this, we are neither creating redundant maps and nor are we defining new methods for the same functions. The code snippet below shows our new strategy to find the responses for a particular reviewer.
<pre>
...
# E17A0 If an assignment is to be reviewed by a team, select it by team_id otherwise by 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
...
</pre>
<br>

3. This is an important feature since if we allow teammates to edit reviews concurrently, each of them will overwrite each other's changes. We have handled this by using the ''is_locked'' and ''locked_by'' field in the response_map table. Using these fields, we will lock the response for the current_user. Thus, when one teammate is editing, the response is locked and that members id is stored in the ''locked_by'' field. Now for other users we will check ''locked_by'' field. If it does not match their id and they click on the '''edit''' button, then a error message will be displayed which will inform the user that his/her teammate is already editing the same review.
This response is then unlocked when the current_user saves the response. The methods for locking and unlocking the response are defined in the
<pre>
...
#E17A0 Lock response
def lock_response_map response_id
review_response_map = ReviewResponseMap.find_by_id(Response.find(response_id).map_id)
unless review_response_map.nil?
ReviewResponseMap.update(review_response_map.id, :is_locked => true, :locked_by => current_user.id)
end
end

#E17A0 Unlock Response
def unlock_response_map response_id
review_response_map = ReviewResponseMap.find_by_id(response_id)
unless review_response_map.nil?
ReviewResponseMap.update(review_response_map.id, :is_locked => false, :locked_by => current_user.id)
end
end
...
</pre>

4/5. Changes 4 and 5 are both database migrations. Thus, we just add these fields in their respective tables.

6. This feature is provided to handle a rare edge case. Say that the instructor decides to change the review strategy after the reviews have already started. Now, the format of the response_maps already created will not match the response_maps that will be created after the strategy change. Thus, if the instructor wants to change the strategy, s/he can delete all reviews already done, and then instruct students to start over. The ''delete_reviews'' method is defined in the ''assignment'' model. Our method deletes all the response_maps as well as all the response objects created.
<pre>
...
def delete_reviews
responsemap = ResponseMap.where(reviewed_object_id: self.id, type: 'ReviewResponseMap')
response = Response.where(map_id: responsemap.ids)
response.each { |r| Answer.destroy_all(response_id: r.id)}
Response.destroy_all(map_id: responsemap.ids)
ResponseMap.destroy_all(id: responsemap.ids)
end
...
</pre>

==Files Involved==

{| class="wikitable" style="text-align: center; color: black;"
|response_map.rb
|assignment.rb
|response_controller.rb
|review_mapping_controller.rb
|-
|/edit/_review_strategy.html.erb
|student_review/_responses.html.erb
|review_mapping/select_reviewer.html.haml
|response_controller_spec.rb
|-
|assignment_controller.rb
|student_review_controller.rb
|application_helper.rb
|access_helper.rb
|-
|assignment_team.rb
|/response/response.html.erb
|/review_mapping/_list_review_mapping.html.erb
|/student_review/_set_dynamic_review.html.erb
|-
|/student_review/list.html.erb
|config/routes.rb
|assignment_controller_spec.rb
|}

==Design Principles 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).<br>

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

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

==Use Case==

<div style="padding: 0px 0px 0px 25px">
[[File:UC_new.png|none]]
</div>

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:
<li> Log in to Expertiza.
<li> Select an assignment.
<li> Select "other's work".
<li> The student can request a review for the team from here.
<li> Depending on the number of reviews allowed and the number of reviews already performed by the team, they will be allotted a new review
<li> Begin the review.
<li> Only one member of the team can edit the review at an given time.
<li> All restrictions that apply to individual reviewers, also apply to teams (e.g. like a individual reviewer, a team also cannot have more than 2 outstanding incomplete reviews).
<li> Complete the review and Click Submit.
<br>

===Edge Cases===
Apart from the case explained above we have handled two edge cases. These cases are as explained below:

'''Case 1:<br>'''
Scenario:<br>
We are not allowing concurrent editing of reviews for teams. We are doing this by locking the response_map. Thus, when a team member is editing a review we lock the response using that team member's id. It can only be unlocked when the review has been saved. When locked the other team members can only view the review.

'''Case 2:<br>'''
Scenario:<br>
The beginning of a review is a special case since when the begin button is clicked a review form is only rendered. Nothing is saved. Since there is no response object linked to the review, we cannot lock anything. Thus, if this case is not handled all the teammates will be able to begin the review concurrently and the person who saves last will overwrite changes of all teammates. Thus, we lock the respnse_map. Now when one of the teammate begins the review ,and the other teammates try to begin too, they will get an error saying that the review is already being edited by someone else.

'''Case 3:<br>'''
Scenario:<br>
If a team member forgets to save or submit a review and has not closed the browser window, then we automatically save the review after an inactivity timeout of 20 mins thus unlocking it for the other team members to edit.

'''Case 4:<br>'''
Scenario:<br>
At a critical time, if a team is unable to contact the team member who has locked the review by closing the browser window without saving the review, the other team members can contact the instructor who has been provided an unlock button for such emergency situations. The instructor can now unlock that review and then the other team members can edit it.

'''Case 5:<br>'''
Scenario:<br>
An instructor can delete completed review if he/she decides to change the switch strategy for an assignment between tema reviews and individual reviews. If a user is editing a review at the instant when instructor is deleting the reviews, upon pressing the save review or submit review button, the user is redirected to the student_review/list.html.erb page

==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.
<br>
'''Current Implementation is as follows:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Current_implementation1.png|none|frame]]
</div>

----

<br>
'''New Implementation will be as shown below:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:review_strategy.png|none|frame]]
</div>
----

<br>
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.
<br>
'''If the assignment has individual reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Student_review1.png|none|frame]]
</div>
----

<br>
'''If the assignment has team reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_review_req.png|none|frame]]
</div>
----

<br>
'''When Instructor assigns reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:instructor_assign_reviews.png|none|frame]]
</div>
----

<br>

==Test Plan==
The Assignments functions; including creation, updating, saving and modifying methods have already been tested, and our test plan includes testing for the new team-based reviewing functionality that we have added. Our test plan includes the following test methods:<br>
1. Test the delete_reviews method to check whether it displays a flash message when there are no reviews to be delete.<br>
2. Test the delete_reviews method to check whether it displays the success flash message on deletion of reviews.<br>
3. Test the action_allowed? method to check whether it denies certain action when the review is locked by a user other than current user.<br>
4. Test the action_allowed? method to check whether it allows certain action when the review is locked by current user.<br>
5. Test the reviewer_is_team_member method to check whether the current user is a member of the assignment review team.<br>

==Additional Links==
[https://github.com/ghnguye2/expertiza.git Github Project Repo]<br>
[https://github.com/expertiza/expertiza/pull/1118 Github Pull Request]<br>
[https://youtu.be/8vkHx3Hqm8g Project Demo]

==Team Information==
[mailto:ashah22@ncsu.edu Aditya Shah]<br>
[mailto:adeshmu@ncsu.edu Amey Deshmukh]<br>
[mailto:dkalro@ncsu.edu Deepak Kalro]<br>
[mailto:pmusyok@ncsu.edu Philip Musyoki]
----

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-12-04T17:13:57Z

Adeshmu:

==='''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<br>

2. Any member of a team should be able to select a review to be done by their team.<br>

3. Team members should not be allowed to edit a review simultaneously.<br>

4. The responses as well as the response_maps in the database should be deleted when the instructor decides to the change the 'Review Strategy' after the reviews have already started. <br>

In summary, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

==Database Migrations==
We will add the following fields in existing models of the Expertiza.

1. To assign team based reviewing attribute to the assignemnts a new boolean field reviewer_is_team was added to the with the default set to false.

2. To create a common response for all the team members we added a team_id field to the ResponseMap model. This identifies the reviewer team.

3. To prevent concurrent editing of the reviews by the team members we lock the response in the ResponseMap. This is check is based on the new is_locked field.

4. To identify the user who has locked the review we have also added a locked_by field in the ResponseMap which carries the current_user.id.

[[File:Db_migr13.png|centre]]

==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. The default value for the checkbox is "false". Thus, it will not break any existing functionality.
<pre>
...

<tr id="reviewer_is_team">
<td>
<input name="assignment_form[assignment][reviewer_is_team]" type="hidden" value="false"/>
<%= check_box_tag('assignment_form[assignment][reviewer_is_team]', 'true', @assignment_form.assignment.reviewer_is_team) %>
<%= label_tag('assignment_form[assignment][reviewer_is_team]', 'Reviews are to be performed by teams.') %>
</td>
</tr>
...
</pre>
<br>

2. For this feature to work we must create correct mappings. 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. In our design we are creating only one ResponseMap per team, i.e if the "reviewer_is_team" is set by the instructor, the ResponseMap created will have the reviewer_id as the participant_id of the requesting student and the team_id as the id of requesting students team in that assignment. Now to map this single response to all students in a team, we changed the strategy which returns response_mappings, in the "student_review_controller", for a particular reviewer. If the assignment has team_reviewers, then we find the responses by "team_id", and if there are no team reviewers for the assignment then we return responses by matching the "reviewer_id". Thus, if our mappings are created correctly, then the entire team will be directed to a single response_map and thus a single response irrespective of who requests the review. Thus, any of the team members will be able to request reviews as as the mappings will created with the team_id. The reason for us to not set the "reviewer_id" null or 0 for team reviewers is that, some of the functionalities like number of reviews, scores are all mapped to a single participant. Thus, if that is set that to any value, we will have to define all new methods for team reviewers. But, now we can use all those functions on our response and then make that same response object available to all members of the team. By doing this, we are neither creating redundant maps and nor are we defining new methods for the same functions. The code snippet below shows our new strategy to find the responses for a particular reviewer.
<pre>
...
# E17A0 If an assignment is to be reviewed by a team, select it by team_id otherwise by 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
...
</pre>
<br>

3. This is an important feature since if we allow teammates to edit reviews concurrently, each of them will overwrite each other's changes. We have handled this by using the ''is_locked'' and ''locked_by'' field in the response_map table. Using these fields, we will lock the response for the current_user. Thus, when one teammate is editing, the response is locked and that members id is stored in the ''locked_by'' field. Now for other users we will check ''locked_by'' field. If it does not match their id and they click on the '''edit''' button, then a error message will be displayed which will inform the user that his/her teammate is already editing the same review.
This response is then unlocked when the current_user saves the response. The methods for locking and unlocking the response are defined in the
<pre>
...
#E17A0 Lock response
def lock_response_map response_id
review_response_map = ReviewResponseMap.find_by_id(Response.find(response_id).map_id)
unless review_response_map.nil?
ReviewResponseMap.update(review_response_map.id, :is_locked => true, :locked_by => current_user.id)
end
end

#E17A0 Unlock Response
def unlock_response_map response_id
review_response_map = ReviewResponseMap.find_by_id(response_id)
unless review_response_map.nil?
ReviewResponseMap.update(review_response_map.id, :is_locked => false, :locked_by => current_user.id)
end
end
...
</pre>

4/5. Changes 4 and 5 are both database migrations. Thus, we just add these fields in their respective tables.

6. This feature is provided to handle a rare edge case. Say that the instructor decides to change the review strategy after the reviews have already started. Now, the format of the response_maps already created will not match the response_maps that will be created after the strategy change. Thus, if the instructor wants to change the strategy, s/he can delete all reviews already done, and then instruct students to start over. The ''delete_reviews'' method is defined in the ''assignment'' model. Our method deletes all the response_maps as well as all the response objects created.
<pre>
...
def delete_reviews
responsemap = ResponseMap.where(reviewed_object_id: self.id, type: 'ReviewResponseMap')
response = Response.where(map_id: responsemap.ids)
response.each { |r| Answer.destroy_all(response_id: r.id)}
Response.destroy_all(map_id: responsemap.ids)
ResponseMap.destroy_all(id: responsemap.ids)
end
...
</pre>

==Files Involved==

{| class="wikitable" style="text-align: center; color: black;"
|response_map.rb
|assignment.rb
|response_controller.rb
|review_mapping_controller.rb
|-
|/edit/_review_strategy.html.erb
|student_review/_responses.html.erb
|review_mapping/select_reviewer.html.haml
|response_controller_spec.rb
|-
|assignment_controller.rb
|student_review_controller.rb
|application_helper.rb
|access_helper.rb
|-
|assignment_team.rb
|/response/response.html.erb
|/review_mapping/_list_review_mapping.html.erb
|/student_review/_set_dynamic_review.html.erb
|-
|/student_review/list.html.erb
|config/routes.rb
|assignment_controller_spec.rb
|}

==Design Principles 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).<br>

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

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

==Use Case==

<div style="padding: 0px 0px 0px 25px">
[[File:UC_new.png|none]]
</div>

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:
<li> Log in to Expertiza.
<li> Select an assignment.
<li> Select "other's work".
<li> The student can request a review for the team from here.
<li> Depending on the number of reviews allowed and the number of reviews already performed by the team, they will be allotted a new review
<li> Begin the review.
<li> Only one member of the team can edit the review at an given time.
<li> All restrictions that apply to individual reviewers, also apply to teams (e.g. like a individual reviewer, a team also cannot have more than 2 outstanding incomplete reviews).
<li> Complete the review and Click Submit.
<br>

===Edge Cases===
Apart from the case explained above we have handled two edge cases. These cases are as explained below:

'''Case 1:<br>'''
Scenario:<br>
We are not allowing concurrent editing of reviews for teams. We are doing this by locking the response_map. Thus, when a team member is editing a review we lock the response using that team member's id. It can only be unlocked when the review has been saved. When locked the other team members can only view the review.

'''Case 2:<br>'''
Scenario:<br>
The beginning of a review is a special case since when the begin button is clicked a review form is only rendered. Nothing is saved. Since there is no response object linked to the review, we cannot lock anything. Thus, if this case is not handled all the teammates will be able to begin the review concurrently and the person who saves last will overwrite changes of all teammates. Thus, we lock the respnse_map. Now when one of the teammate begins the review ,and the other teammates try to begin too, they will get an error saying that the review is already being edited by someone else.

'''Case 3:<br>'''
Scenario:<br>
If a team member forgets to save or submit a review and has not closed the browser window, then we automatically save the review after an inactivity timeout of 20 mins thus unlocking it for the other team members to edit.

'''Case 4:<br>'''
Scenario:<br>
At a critical time, if a team is unable to contact the team member who has locked the review by closing the browser window without saving the review, the other team members can contact the instructor who has been provided an unlock button for such emergency situations. The instructor can now unlock that review and then the other team members can edit it.

'''Case 5:<br>'''
Scenario:<br>
An instructor can delete completed review if he/she decides to change the switch strategy for an assignment between tema reviews and individual reviews. If a user is editing a review at the instant when instructor is deleting the reviews, upon pressing the save review or submit review button, the user is redirected to the student_review/list.html.erb page

==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.
<br>
'''Current Implementation is as follows:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Current_implementation1.png|none|frame]]
</div>

----

<br>
'''New Implementation will be as shown below:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:review_strategy.png|none|frame]]
</div>
----

<br>
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.
<br>
'''If the assignment has individual reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Student_review1.png|none|frame]]
</div>
----

<br>
'''If the assignment has team reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_review_req.png|none|frame]]
</div>
----

<br>
'''When Instructor assigns reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:instructor_assign_reviews.png|none|frame]]
</div>
----

<br>

==Test Plan==
The Assignments functions; including creation, updating, saving and modifying methods have already been tested, and our test plan includes testing for the new team-based reviewing functionality that we have added. Our test plan includes the following test methods:<br>
1. Test the delete_reviews method to check whether it asks for a confirmation before deleting the reviews.<br>
2. Test the delete_reviews method to check whether it displays the success flash message on deletion of reviews.<br>
3. Test the action_allowed? method to check whether it denies certain action when the review is locked by a user other than current user.<br>
4. Test the action_allowed? method to check whether it allows certain action when the review is locked by current user.<br>
5. Test the reviewer_is_team_member method to check whether the current user is a member of the assignment review team.<br>

==Additional Links==
[https://github.com/ghnguye2/expertiza.git Github Project Repo]<br>
[https://github.com/expertiza/expertiza/pull/1118 Github Pull Request]<br>
[https://youtu.be/8vkHx3Hqm8g Project Demo]

==Team Information==
[mailto:ashah22@ncsu.edu Aditya Shah]<br>
[mailto:adeshmu@ncsu.edu Amey Deshmukh]<br>
[mailto:dkalro@ncsu.edu Deepak Kalro]<br>
[mailto:pmusyok@ncsu.edu Philip Musyoki]
----

CSC/ECE 517 Fall 2017/E1763 Fix Staggered-Deadline Assignments

2017-12-04T17:13:22Z

Adeshmu: /* Additional Links */

=='''Introduction'''==

Expertiza is a web application developed using Ruby on Rails that serves as a peer-review system. The application allows students to submit and peer-review learning objects (articles, code, web sites, etc). It is an open source project and it's codebase is maintained in GitHub. We are contributing to Expertiza as a part of our Object-Oriented Design and Development's Open-Source Software (OSS) Project. Our goal in this project is to fix various issues related to staggered deadlines for assignments. A staggered-deadline assignment is an assignment in which different topics have different deadlines. In this Wiki Page, we will explain the changes that we have made for the same.

=='''Changes To Be Implemented'''==

<li> Currently, the system requires the instructor to enter, manually, all submission and review deadlines for all topics. It would be better if the instructor could enter the deadlines once, and have them be applied to a specified set of topics.
<li> We were also asked to create a "Duplicate Topic" button for the instructor, to copy a particular topic within a assignment.
<li> Currently the assignment topics are displayed on the basis of "first created". Thus we have to sort the topics sorted based on the topic_identifiers.
<li>'''Testing is not a requirement of this project.'''

=='''Motivation'''==
<li> Currently when the instructor wants to assign the same deadlines to certain topics, s/he has to manually enter all deadline dates. Each deadline includes date and time. Now if there are review rounds (which we assume there are), the instructor will have to enter all dates manually. This task is time consuming and just wasted effort. It will be more efficient to have a method where the instructor can assign this deadline to certain selected topics from the assignment.
<li> In an assignment that has staggered deadlines, say a topic has 3 slots. For the first round only 1 slot was taken. Now in the second round, another team wants to sign-up for the topic. This team will not be allowed since the deadline has already passed, even though slots are available. The solution to this problem is to let the instructor duplicate a topic with remaining slots and set the duplicate topic deadline to the latest deadline of all topics(default) or any date that s/he wants.
<li> The current display of topics is not intuitive in the sense that say, topic 1.1.1 was created after topic 2.1. Now the newly created topic (1.1.1) will be displayed after 2.1. Thus, we will display the topics sorted according topic identifier. If a topic is created without identifier it will be displayed before all the topics with identifiers, on the basis of "first created".

=='''Modified Files'''==

1) app/controllers/sign_up_sheet_controller.rb

2) app/views/sign_up_sheet/_due_dates.html.erb

3) app/helpers/sign_up_sheet_helper.rb

4) app/views/layouts/application.html.erb

5) app/views/sign_up_sheet/_all_actions.html.erb

6) app/views/sign_up_sheet/_add_signup_topics_staggered.html.erb

7) app/views/sign_up_sheet/_add_signup_topics.html.erb

=='''Approach Taken To Implement Changes'''==

1) For the first issue where the instructor was forced to enter due dates manually for each topic, we have added a checkbox against each topic in the assignment. The code for this was added in the due_dates.html.erb file. We have also provided a text box at the end for the instructor to enter the due dates for the selected topics. This text box is auto-populated with the latest deadline of all topics in that assignment, thereby saving the instructor the hassle of having to enter all the fields from scratch.
Then we have updated the save_topic_deadlines method in the sign_up_sheet_controller. This is the method called when we want to save the new deadline entered.

The logic we have used to modify due_dates.html.erb:
<li>Add a checkbox tag before each topic.Also, if the checkbox is checked add the topic_id to an array "selected_ids[]"
[[File:Checkbox.png]]

<li>Provide a text box for the instructor to enter the new deadline for the selected topics.
[[File:Newdeadline.png]]

<li> The default deadline for the textbook is set to the latest deadline among all the topics under the assignment. This is achieved by a helper method
[[File:GetLastestDeadline.png]]
<br>

<li>Call the save_topic_deadlines controller method with this array and entered date as parameters
<br>
The logic used to modify save_topic_deadlines:
<li>Receive the array of selected topics and new deadline from the view
<li>Loop over each of the topic. Assign the new deadline from the text box to the topic that has a selected checkbox
[[File:SaveNewDeadline.png]]
<br><br>

2) Along with the check-boxes, we have also implemented shift+click for topic selection. Without it the instructor would have to select each topic individually. Thus with this, if the instructor selects a single topic, then presses shift and selects another topic, then all the intermediate topics will also be selected. This saves the instructor the hassle of going and explicitly selecting each topic.
<br>
This is achieved using a javascript written in the due_dates.html.erb.
<br>
The logic is:
<li> Get the checkbox selected by the instructor
<li> If shift key was pressed, get the last checked checkbox.
<li> Loop over each checkbox between the two checkboxes and change the status of each checkbox to selected.
[[File:Multiselect.png]]
<br><br>

3) We have also sorted the topics that are displayed for the assignment based on the topic_identifier. Managing a number of topics which are all out of order can be troublesome. Currently the topics are displayed in the order in which they were created which is not intuitive. Say the instructor first creates a topic with identifier "4.1". Second s/he creates another topic with identifier "1.2". Intuitively the newer topic must be displayed first. This is not the case in the current version. Thus we have added that.
<br>
This is achieved by adding a simple line to the views of the topics. (i.e add_signup_topics_staggered.html.erb and add_signup_topics.html.erb)
<pre><% @sign_up_topics = SignUpTopic.where(['assignment_id = ?', @assignment.id]).order(:topic_identifier) %></pre><br> We use the inbuilt method .order with the parameter :topic_identifier.
<br>

4) To implement "duplicate topic" button, we have added the button under the actions menu for each topic in the sign_up_sheet/_all_actions.html.erb view file.
<br>
We have taken the following design decisions regarding the duplication of topics:
<br>
-> If all the slots are available for the particular topic, then instead of duplicating a topic, the instructor can just extend the deadline and allow students to signup.
<br>
-> If no slots are available, then the instructor will first have to increase the number of slots and then try again.
<br><br>
To implement this logic we have added a new method in the sign_up_sheet_controller.<br>
The method duplicates the topic using the following logic:
<li> Find the topic using the topic_id that we sent from the view.
<li> Get the available slots fo the topic.
<li> Depending on the available slots, if topic is to be duplicated call assign_values method.
<li> In the assign_values method, we set the various parameters of the duplicate_topic (identifier, assignment_id, link, description etc) to their corresponding values from the original topic.
<li> The remaining parameters are assigned with some modifications. The name is saved with the word " copy" appended at the end. The number of max_choosers for this duplicate topic is equal to the available slots for the original topic.
<li> If the topic is not to be duplicated(if available_slots==0 or available_slots==max_choosers), error out and display appropriate error message.
<br>
[[File:Duplicate1.png]]
<br>
[[File:Duplicate2.png]]
<br><br>

==='''Screenshots Of The Implemented Features '''===
1) Log in as Instructor. On clicking on 'Manage Content' a screen is rendered which lists the existing assignments.
<br>
2) Click on the edit assignment button for any assignment. For the purposes of this screenshots we will select "Madeup problem".
<br>
3) For the first feature we can see that we have added a checkbox against each topic. We can also see the "New deadlines for selected topics" text box. This text box automatically fills the boxes with corresponding values of the topic with the latest deadlines of all topics. All these are clearly visible in the screenshot below.
<br>
----
[[File:Default_value_with_0_selections.png]]
----
<br>
4) Since multi-select cannot be shown with images, we have shown it in the screen-cast. In the following couple of screenshots we have selected various topics and entered a new date for all of them only once. When we press the save button the dates entered in the text-box is applied to all the selected topics.
<br>
----
[[File:Selected_topic_with_date_entered.png]]
----
[[File:Updated_duedates.png]]
----
<br>
5) Sorting. From the topics displayed in the image below we clearly see that they are sorted.
<br>
----
[[File:Sorting.png]]
----
<br>
6) The first case is when we try to duplicate a topic with zero slots available. In this case too it will not duplicate a topic and display an error message.
<br>
----
[[File:Dup_fail1.png]]
----
<br>
7) The second case is when we try to duplicate a topic with all slots available. It will not duplicate the topic and display an error message.
<br>
----
[[File:Dup_fail2.png]]
----
<br>
8) Success!!
<br>
----
[[File:Success.png]]
----
<br>

=='''Testing'''==
We have tested these features in the video using the following steps:<br>
*Login as an instructor since these features will not be available for other user roles.
*Go to assignments and for a random assignment press the edit button. We have selected "Madeup problem" for our screenshots and videos.
*Go to topics. You can see the "duplicate topic" button in the action column for all topics.
*To duplicate a topic press the button for any topic.
*Depending on the conditions mentions above it will successfully duplicate or it will error out with the appropriate message.
*For the second feature click on the "Show start/due dates" button at the bottom.
*Select check-boxes against topics whose deadlines you want to change.
*To check shift-click functionality select one topic. Press shift and select another topic. All topics in the middle will also be selected.
*The text box at the bottom has the latest values of all the topics by default.
*Change the deadlines and click on "Save" button.
*The entered deadlines are saved for all topics selected.
<br><br>

=='''Demo Video Link'''==
[https://youtu.be/2Y8LzHkhcJY Demo Video Link]<br>

=='''Additional Links'''==
[https://github.com/ghnguye2/expertiza.git Github Project Repo]<br>
[https://github.com/expertiza/expertiza/pull/1118 Github Pull Request]
[https://youtu.be/8vkHx3Hqm8g Project Demo]

=='''References'''==
[https://expertiza.ncsu.edu/ Expertiza NCSU]
=='''Team'''==
[mailto:ghnguye2@ncsu.edu Giang Nguyen]<br>
[mailto:dkalro@ncsu.edu Deepak Kalro]<br>
[mailto:ashah22@ncsu.edu Aditya Shah]

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-12-04T17:06:41Z

Adeshmu: /* UI Changes */

==='''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<br>

2. Any member of a team should be able to select a review to be done by their team.<br>

3. Team members should not be allowed to edit a review simultaneously.<br>

4. The responses as well as the response_maps in the database should be deleted when the instructor decides to the change the 'Review Strategy' after the reviews have already started. <br>

In summary, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

==Database Migrations==
We will add the following fields in existing models of the Expertiza.

1. To assign team based reviewing attribute to the assignemnts a new boolean field reviewer_is_team was added to the with the default set to false.

2. To create a common response for all the team members we added a team_id field to the ResponseMap model. This identifies the reviewer team.

3. To prevent concurrent editing of the reviews by the team members we lock the response in the ResponseMap. This is check is based on the new is_locked field.

4. To identify the user who has locked the review we have also added a locked_by field in the ResponseMap which carries the current_user.id.

[[File:Db_migr13.png|centre]]

==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. The default value for the checkbox is "false". Thus, it will not break any existing functionality.
<pre>
...

<tr id="reviewer_is_team">
<td>
<input name="assignment_form[assignment][reviewer_is_team]" type="hidden" value="false"/>
<%= check_box_tag('assignment_form[assignment][reviewer_is_team]', 'true', @assignment_form.assignment.reviewer_is_team) %>
<%= label_tag('assignment_form[assignment][reviewer_is_team]', 'Reviews are to be performed by teams.') %>
</td>
</tr>
...
</pre>
<br>

2. For this feature to work we must create correct mappings. 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. In our design we are creating only one ResponseMap per team, i.e if the "reviewer_is_team" is set by the instructor, the ResponseMap created will have the reviewer_id as the participant_id of the requesting student and the team_id as the id of requesting students team in that assignment. Now to map this single response to all students in a team, we changed the strategy which returns response_mappings, in the "student_review_controller", for a particular reviewer. If the assignment has team_reviewers, then we find the responses by "team_id", and if there are no team reviewers for the assignment then we return responses by matching the "reviewer_id". Thus, if our mappings are created correctly, then the entire team will be directed to a single response_map and thus a single response irrespective of who requests the review. Thus, any of the team members will be able to request reviews as as the mappings will created with the team_id. The reason for us to not set the "reviewer_id" null or 0 for team reviewers is that, some of the functionalities like number of reviews, scores are all mapped to a single participant. Thus, if that is set that to any value, we will have to define all new methods for team reviewers. But, now we can use all those functions on our response and then make that same response object available to all members of the team. By doing this, we are neither creating redundant maps and nor are we defining new methods for the same functions. The code snippet below shows our new strategy to find the responses for a particular reviewer.
<pre>
...
# E17A0 If an assignment is to be reviewed by a team, select it by team_id otherwise by 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
...
</pre>
<br>

3. This is an important feature since if we allow teammates to edit reviews concurrently, each of them will overwrite each other's changes. We have handled this by using the ''is_locked'' and ''locked_by'' field in the response_map table. Using these fields, we will lock the response for the current_user. Thus, when one teammate is editing, the response is locked and that members id is stored in the ''locked_by'' field. Now for other users we will check ''locked_by'' field. If it does not match their id and they click on the '''edit''' button, then a error message will be displayed which will inform the user that his/her teammate is already editing the same review.
This response is then unlocked when the current_user saves the response. The methods for locking and unlocking the response are defined in the
<pre>
...
#E17A0 Lock response
def lock_response_map response_id
review_response_map = ReviewResponseMap.find_by_id(Response.find(response_id).map_id)
unless review_response_map.nil?
ReviewResponseMap.update(review_response_map.id, :is_locked => true, :locked_by => current_user.id)
end
end

#E17A0 Unlock Response
def unlock_response_map response_id
review_response_map = ReviewResponseMap.find_by_id(response_id)
unless review_response_map.nil?
ReviewResponseMap.update(review_response_map.id, :is_locked => false, :locked_by => current_user.id)
end
end
...
</pre>

4/5. Changes 4 and 5 are both database migrations. Thus, we just add these fields in their respective tables.

6. This feature is provided to handle a rare edge case. Say that the instructor decides to change the review strategy after the reviews have already started. Now, the format of the response_maps already created will not match the response_maps that will be created after the strategy change. Thus, if the instructor wants to change the strategy, s/he can delete all reviews already done, and then instruct students to start over. The ''delete_reviews'' method is defined in the ''assignment'' model. Our method deletes all the response_maps as well as all the response objects created.
<pre>
...
def delete_reviews
responsemap = ResponseMap.where(reviewed_object_id: self.id, type: 'ReviewResponseMap')
response = Response.where(map_id: responsemap.ids)
response.each { |r| Answer.destroy_all(response_id: r.id)}
Response.destroy_all(map_id: responsemap.ids)
ResponseMap.destroy_all(id: responsemap.ids)
end
...
</pre>

==Files Involved==

{| class="wikitable" style="text-align: center; color: black;"
|response_map.rb
|assignment.rb
|response_controller.rb
|review_mapping_controller.rb
|-
|/edit/_review_strategy.html.erb
|student_review/_responses.html.erb
|review_mapping/select_reviewer.html.haml
|response_controller_spec.rb
|-
|assignment_controller.rb
|student_review_controller.rb
|application_helper.rb
|access_helper.rb
|-
|assignment_team.rb
|/response/response.html.erb
|/review_mapping/_list_review_mapping.html.erb
|/student_review/_set_dynamic_review.html.erb
|-
|/student_review/list.html.erb
|config/routes.rb
|assignment_controller_spec.rb
|}

==Design Principles 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).<br>

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

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

==Use Case==

<div style="padding: 0px 0px 0px 25px">
[[File:UC_new.png|none]]
</div>

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:
<li> Log in to Expertiza.
<li> Select an assignment.
<li> Select "other's work".
<li> The student can request a review for the team from here.
<li> Depending on the number of reviews allowed and the number of reviews already performed by the team, they will be allotted a new review
<li> Begin the review.
<li> Only one member of the team can edit the review at an given time.
<li> All restrictions that apply to individual reviewers, also apply to teams (e.g. like a individual reviewer, a team also cannot have more than 2 outstanding incomplete reviews).
<li> Complete the review and Click Submit.
<br>

===Edge Cases===
Apart from the case explained above we have handled two edge cases. These cases are as explained below:

'''Case 1:<br>'''
Scenario:<br>
We are not allowing concurrent editing of reviews for teams. We are doing this by locking the response_map. Thus, when a team member is editing a review we lock the response using that team member's id. It can only be unlocked when the review has been saved. When locked the other team members can only view the review.

'''Case 2:<br>'''
Scenario:<br>
The beginning of a review is a special case since when the begin button is clicked a review form is only rendered. Nothing is saved. Since there is no response object linked to the review, we cannot lock anything. Thus, if this case is not handled all the teammates will be able to begin the review concurrently and the person who saves last will overwrite changes of all teammates. Thus, we lock the respnse_map. Now when one of the teammate begins the review ,and the other teammates try to begin too, they will get an error saying that the review is already being edited by someone else.

'''Case 3:<br>'''
Scenario:<br>
If a team member forgets to save or submit a review and has not closed the browser window, then we automatically save the review after an inactivity timeout of 20 mins thus unlocking it for the other team members to edit.

'''Case 4:<br>'''
Scenario:<br>
At a critical time, if a team is unable to contact the team member who has locked the review by closing the browser window without saving the review, the other team members can contact the instructor who has been provided an unlock button for such emergency situations. The instructor can now unlock that review and then the other team members can edit it.

'''Case 5:<br>'''
Scenario:<br>
An instructor can delete completed review if he/she decides to change the switch strategy for an assignment between tema reviews and individual reviews. If a user is editing a review at the instant when instructor is deleting the reviews, upon pressing the save review or submit review button, the user is redirected to the student_review/list.html.erb page

==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.
<br>
'''Current Implementation is as follows:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Current_implementation1.png|none|frame]]
</div>

----

<br>
'''New Implementation will be as shown below:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:review_strategy.png|none|frame]]
</div>
----

<br>
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.
<br>
'''If the assignment has individual reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Student_review1.png|none|frame]]
</div>
----

<br>
'''If the assignment has team reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_review_req.png|none|frame]]
</div>
----

<br>
'''When Instructor assigns reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:instructor_assign_reviews.png|none|frame]]
</div>
----

<br>

==Test Plan==
The Assignments functions; including creation, updating, saving and modifying methods have already been tested, and our test plan includes testing for the new team-based reviewing functionality that we have added. Our test plan includes the following test methods:<br>
1. Test the delete_reviews method to check whether it asks for a confirmation before deleting the reviews.<br>
2. Test the delete_reviews method to check whether it displays the success flash message on deletion of reviews.<br>
3. Test the action_allowed? method to check whether it denies certain action when the review is locked by a user other than current user.<br>
4. Test the action_allowed? method to check whether it allows certain action when the review is locked by current user.<br>
5. Test the reviewer_is_team_member method to check whether the current user is a member of the assignment review team.<br>

==Team Information==
[mailto:ashah22@ncsu.edu Aditya Shah]<br>
[mailto:adeshmu@ncsu.edu Amey Deshmukh]<br>
[mailto:dkalro@ncsu.edu Deepak Kalro]<br>
[mailto:pmusyok@ncsu.edu Philip Musyoki]
----

File:Review strategy.png

2017-12-04T17:03:11Z

Adeshmu: uploaded a new version of "File:Review strategy.png"

File:Instructor assign reviews.png

2017-12-04T17:02:51Z

Adeshmu:

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-12-03T18:55:15Z

Adeshmu: /* Test Plan */

==='''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<br>

2. Any member of a team should be able to select a review to be done by their team.<br>

3. Team members should not be allowed to edit a review simultaneously.<br>

4. The responses as well as the response_maps in the database should be deleted when the instructor decides to the change the 'Review Strategy' after the reviews have already started. <br>

In summary, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

==Database Migrations==
We will add the following fields in existing models of the Expertiza.

1. To assign team based reviewing attribute to the assignemnts a new boolean field reviewer_is_team was added to the with the default set to false.

2. To create a common response for all the team members we added a team_id field to the ResponseMap model. This identifies the reviewer team.

3. To prevent concurrent editing of the reviews by the team members we lock the response in the ResponseMap. This is check is based on the new is_locked field.

4. To identify the user who has locked the review we have also added a locked_by field in the ResponseMap which carries the current_user.id.

[[File:Db_migr13.png|centre]]

==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. The default value for the checkbox is "false". Thus, it will not break any existing functionality.
<pre>
...

<tr id="reviewer_is_team">
<td>
<input name="assignment_form[assignment][reviewer_is_team]" type="hidden" value="false"/>
<%= check_box_tag('assignment_form[assignment][reviewer_is_team]', 'true', @assignment_form.assignment.reviewer_is_team) %>
<%= label_tag('assignment_form[assignment][reviewer_is_team]', 'Reviews are to be performed by teams.') %>
</td>
</tr>
...
</pre>
<br>

2. For this feature to work we must create correct mappings. 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. In our design we are creating only one ResponseMap per team, i.e if the "reviewer_is_team" is set by the instructor, the ResponseMap created will have the reviewer_id as the participant_id of the requesting student and the team_id as the id of requesting students team in that assignment. Now to map this single response to all students in a team, we changed the strategy which returns response_mappings, in the "student_review_controller", for a particular reviewer. If the assignment has team_reviewers, then we find the responses by "team_id", and if there are no team reviewers for the assignment then we return responses by matching the "reviewer_id". Thus, if our mappings are created correctly, then the entire team will be directed to a single response_map and thus a single response irrespective of who requests the review. Thus, any of the team members will be able to request reviews as as the mappings will created with the team_id. The reason for us to not set the "reviewer_id" null or 0 for team reviewers is that, some of the functionalities like number of reviews, scores are all mapped to a single participant. Thus, if that is set that to any value, we will have to define all new methods for team reviewers. But, now we can use all those functions on our response and then make that same response object available to all members of the team. By doing this, we are neither creating redundant maps and nor are we defining new methods for the same functions. The code snippet below shows our new strategy to find the responses for a particular reviewer.
<pre>
...
# E17A0 If an assignment is to be reviewed by a team, select it by team_id otherwise by 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
...
</pre>
<br>

3. This is an important feature since if we allow teammates to edit reviews concurrently, each of them will overwrite each other's changes. We have handled this by using the ''is_locked'' and ''locked_by'' field in the response_map table. Using these fields, we will lock the response for the current_user. Thus, when one teammate is editing, the response is locked and that members id is stored in the ''locked_by'' field. Now for other users we will check ''locked_by'' field. If it does not match their id and they click on the '''edit''' button, then a error message will be displayed which will inform the user that his/her teammate is already editing the same review.
This response is then unlocked when the current_user saves the response. The methods for locking and unlocking the response are defined in the
<pre>
...
#E17A0 Lock response
def lock_response_map response_id
review_response_map = ReviewResponseMap.find_by_id(Response.find(response_id).map_id)
unless review_response_map.nil?
ReviewResponseMap.update(review_response_map.id, :is_locked => true, :locked_by => current_user.id)
end
end

#E17A0 Unlock Response
def unlock_response_map response_id
review_response_map = ReviewResponseMap.find_by_id(response_id)
unless review_response_map.nil?
ReviewResponseMap.update(review_response_map.id, :is_locked => false, :locked_by => current_user.id)
end
end
...
</pre>

4/5. Changes 4 and 5 are both database migrations. Thus, we just add these fields in their respective tables.

6. This feature is provided to handle a rare edge case. Say that the instructor decides to change the review strategy after the reviews have already started. Now, the format of the response_maps already created will not match the response_maps that will be created after the strategy change. Thus, if the instructor wants to change the strategy, s/he can delete all reviews already done, and then instruct students to start over. The ''delete_reviews'' method is defined in the ''assignment'' model. Our method deletes all the response_maps as well as all the response objects created.
<pre>
...
def delete_reviews
responsemap = ResponseMap.where(reviewed_object_id: self.id, type: 'ReviewResponseMap')
response = Response.where(map_id: responsemap.ids)
response.each { |r| Answer.destroy_all(response_id: r.id)}
Response.destroy_all(map_id: responsemap.ids)
ResponseMap.destroy_all(id: responsemap.ids)
end
...
</pre>

==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

6. student_review/_responses.html.erb

7. review_mapping/select_reviewer.html.haml

8. response_controller_spec.rb

==Design Principles 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).<br>

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

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

==Use Case==

<div style="padding: 0px 0px 0px 25px">
[[File:UC_new.png|none]]
</div>

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:
<li> Log in to Expertiza.
<li> Select an assignment.
<li> Select "other's work".
<li> The student can request a review for the team from here.
<li> Depending on the number of reviews allowed and the number of reviews already performed by the team, they will be allotted a new review
<li> Begin the review.
<li> Only one member of the team can edit the review at an given time.
<li> All restrictions that apply to individual reviewers, also apply to teams (e.g. like a individual reviewer, a team also cannot have more than 2 outstanding incomplete reviews).
<li> Complete the review and Click Submit.
<br>

===Edge Cases===
Apart from the case explained above we have handled two edge cases. These cases are as explained below:

'''Case 1:<br>'''
Scenario:<br>
We are not allowing concurrent editing of reviews for teams. We are doing this by locking the response_map. Thus, when a team member is editing a review we do lock the response using that team member id

'''Case 2:<br>'''
Scenario:<br>
If a team member forgets to save or submit a review and has not closed the browser window, then we automatically save the review after a timeout of 20 mins thus unlocking it for the other team members to edit.

'''Case 3:<br>'''
Scenario:<br>
At a critical time, if a team is unable to contact the team member who has locked the review by closing the browser window without saving the review, the other team members can contact the instructor who has been provided an unlock button for such emergency situations. The instructor can now unlock that review and then the other team members can edit it.

'''Case 4:<br>'''
Scenario:<br>
An instructor can delete completed review if he/she decides to change the switch strategy for an assignment between tema reviews and individual reviews. If a user is editing a review at the instant when instructor is deleting the reviews, upon pressing the save review or submit review button, the user is redirected to the student_review/list.html.erb page

==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.
<br>
'''Current Implementation is as follows:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Current_implementation1.png|none|frame]]
</div>

----

<br>
'''New Implementation will be as shown below:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_syn_chkbox.png|none|frame]]
</div>
----

<br>
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.
<br>
'''If the assignment has individual reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Student_review1.png|none|frame]]
</div>
----

<br>
'''If the assignment has team reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_review_req.png|none|frame]]
</div>
----

<br>

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 includes testing for the new team-based reviewing functionality that we have added. Our test plan includes the following test methods:<br>
1. Test the delete_reviews method to check whether it asks for a confirmation before deleting the reviews.<br>
2. Test the delete_reviews method to check whether it displays the success flash message on deletion of reviews.<br>
3. Test the action_allowed? method to check whether it denies certain action when the review is locked by a user other than current user.<br>
4. Test the action_allowed? method to check whether it allows certain action when the review is locked by current user.<br>
5. Test the reviewer_is_team_member method to check whether the current user is a member of the assignment review team.<br>

==Team Information==
[mailto:ashah22@ncsu.edu Aditya Shah]<br>
[mailto:adeshmu@ncsu.edu Amey Deshmukh]<br>
[mailto:dkalro@ncsu.edu Deepak Kalro]<br>
[mailto:pmusyok@ncsu.edu Philip Musyoki]
----

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-12-03T18:53:41Z

Adeshmu: /* Edge Cases */

==='''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<br>

2. Any member of a team should be able to select a review to be done by their team.<br>

3. Team members should not be allowed to edit a review simultaneously.<br>

4. The responses as well as the response_maps in the database should be deleted when the instructor decides to the change the 'Review Strategy' after the reviews have already started. <br>

In summary, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

==Database Migrations==
We will add the following fields in existing models of the Expertiza.

1. To assign team based reviewing attribute to the assignemnts a new boolean field reviewer_is_team was added to the with the default set to false.

2. To create a common response for all the team members we added a team_id field to the ResponseMap model. This identifies the reviewer team.

3. To prevent concurrent editing of the reviews by the team members we lock the response in the ResponseMap. This is check is based on the new is_locked field.

4. To identify the user who has locked the review we have also added a locked_by field in the ResponseMap which carries the current_user.id.

[[File:Db_migr13.png|centre]]

==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. The default value for the checkbox is "false". Thus, it will not break any existing functionality.
<pre>
...

<tr id="reviewer_is_team">
<td>
<input name="assignment_form[assignment][reviewer_is_team]" type="hidden" value="false"/>
<%= check_box_tag('assignment_form[assignment][reviewer_is_team]', 'true', @assignment_form.assignment.reviewer_is_team) %>
<%= label_tag('assignment_form[assignment][reviewer_is_team]', 'Reviews are to be performed by teams.') %>
</td>
</tr>
...
</pre>
<br>

2. For this feature to work we must create correct mappings. 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. In our design we are creating only one ResponseMap per team, i.e if the "reviewer_is_team" is set by the instructor, the ResponseMap created will have the reviewer_id as the participant_id of the requesting student and the team_id as the id of requesting students team in that assignment. Now to map this single response to all students in a team, we changed the strategy which returns response_mappings, in the "student_review_controller", for a particular reviewer. If the assignment has team_reviewers, then we find the responses by "team_id", and if there are no team reviewers for the assignment then we return responses by matching the "reviewer_id". Thus, if our mappings are created correctly, then the entire team will be directed to a single response_map and thus a single response irrespective of who requests the review. Thus, any of the team members will be able to request reviews as as the mappings will created with the team_id. The reason for us to not set the "reviewer_id" null or 0 for team reviewers is that, some of the functionalities like number of reviews, scores are all mapped to a single participant. Thus, if that is set that to any value, we will have to define all new methods for team reviewers. But, now we can use all those functions on our response and then make that same response object available to all members of the team. By doing this, we are neither creating redundant maps and nor are we defining new methods for the same functions. The code snippet below shows our new strategy to find the responses for a particular reviewer.
<pre>
...
# E17A0 If an assignment is to be reviewed by a team, select it by team_id otherwise by 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
...
</pre>
<br>

3. This is an important feature since if we allow teammates to edit reviews concurrently, each of them will overwrite each other's changes. We have handled this by using the ''is_locked'' and ''locked_by'' field in the response_map table. Using these fields, we will lock the response for the current_user. Thus, when one teammate is editing, the response is locked and that members id is stored in the ''locked_by'' field. Now for other users we will check ''locked_by'' field. If it does not match their id and they click on the '''edit''' button, then a error message will be displayed which will inform the user that his/her teammate is already editing the same review.
This response is then unlocked when the current_user saves the response. The methods for locking and unlocking the response are defined in the
<pre>
...
#E17A0 Lock response
def lock_response_map response_id
review_response_map = ReviewResponseMap.find_by_id(Response.find(response_id).map_id)
unless review_response_map.nil?
ReviewResponseMap.update(review_response_map.id, :is_locked => true, :locked_by => current_user.id)
end
end

#E17A0 Unlock Response
def unlock_response_map response_id
review_response_map = ReviewResponseMap.find_by_id(response_id)
unless review_response_map.nil?
ReviewResponseMap.update(review_response_map.id, :is_locked => false, :locked_by => current_user.id)
end
end
...
</pre>

4/5. Changes 4 and 5 are both database migrations. Thus, we just add these fields in their respective tables.

6. This feature is provided to handle a rare edge case. Say that the instructor decides to change the review strategy after the reviews have already started. Now, the format of the response_maps already created will not match the response_maps that will be created after the strategy change. Thus, if the instructor wants to change the strategy, s/he can delete all reviews already done, and then instruct students to start over. The ''delete_reviews'' method is defined in the ''assignment'' model. Our method deletes all the response_maps as well as all the response objects created.
<pre>
...
def delete_reviews
responsemap = ResponseMap.where(reviewed_object_id: self.id, type: 'ReviewResponseMap')
response = Response.where(map_id: responsemap.ids)
response.each { |r| Answer.destroy_all(response_id: r.id)}
Response.destroy_all(map_id: responsemap.ids)
ResponseMap.destroy_all(id: responsemap.ids)
end
...
</pre>

==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

6. student_review/_responses.html.erb

7. review_mapping/select_reviewer.html.haml

8. response_controller_spec.rb

==Design Principles 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).<br>

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

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

==Use Case==

<div style="padding: 0px 0px 0px 25px">
[[File:UC_new.png|none]]
</div>

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:
<li> Log in to Expertiza.
<li> Select an assignment.
<li> Select "other's work".
<li> The student can request a review for the team from here.
<li> Depending on the number of reviews allowed and the number of reviews already performed by the team, they will be allotted a new review
<li> Begin the review.
<li> Only one member of the team can edit the review at an given time.
<li> All restrictions that apply to individual reviewers, also apply to teams (e.g. like a individual reviewer, a team also cannot have more than 2 outstanding incomplete reviews).
<li> Complete the review and Click Submit.
<br>

===Edge Cases===
Apart from the case explained above we have handled two edge cases. These cases are as explained below:

'''Case 1:<br>'''
Scenario:<br>
We are not allowing concurrent editing of reviews for teams. We are doing this by locking the response_map. Thus, when a team member is editing a review we do lock the response using that team member id

'''Case 2:<br>'''
Scenario:<br>
If a team member forgets to save or submit a review and has not closed the browser window, then we automatically save the review after a timeout of 20 mins thus unlocking it for the other team members to edit.

'''Case 3:<br>'''
Scenario:<br>
At a critical time, if a team is unable to contact the team member who has locked the review by closing the browser window without saving the review, the other team members can contact the instructor who has been provided an unlock button for such emergency situations. The instructor can now unlock that review and then the other team members can edit it.

'''Case 4:<br>'''
Scenario:<br>
An instructor can delete completed review if he/she decides to change the switch strategy for an assignment between tema reviews and individual reviews. If a user is editing a review at the instant when instructor is deleting the reviews, upon pressing the save review or submit review button, the user is redirected to the student_review/list.html.erb page

==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.
<br>
'''Current Implementation is as follows:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Current_implementation1.png|none|frame]]
</div>

----

<br>
'''New Implementation will be as shown below:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_syn_chkbox.png|none|frame]]
</div>
----

<br>
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.
<br>
'''If the assignment has individual reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Student_review1.png|none|frame]]
</div>
----

<br>
'''If the assignment has team reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_review_req.png|none|frame]]
</div>
----

<br>

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 includes testing for the new team-based reviewing functionality that we have added. Our test plan includes the following test methods:<br>

*new
1. Test the delete_reviews method to check whether it asks for a confirmation before deleting the reviews.<br>
2. Test the delete_reviews method to check whether it displays the success flash message on deletion of reviews.<br>
3. Test the action_allowed? method to check whether it denies certain action when the review is locked by a user other than current user.<br>
4. Test the action_allowed? method to check whether it allows certain action when the review is locked by current user.<br>
5. Test the reviewer_is_team_member method to check whether the current user is a member of the assignment review team.<br>

*old
1. If the review for the Assignment will have team id instead of the participant id in Response Map.<br>

2. If for an assignment the instructor can successfully apply the reviewer_is_team? attribute.<br>

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

4. If the team based reviewing functionality works in flow with the student based reviewing.<br>

==Team Information==
[mailto:ashah22@ncsu.edu Aditya Shah]<br>
[mailto:adeshmu@ncsu.edu Amey Deshmukh]<br>
[mailto:dkalro@ncsu.edu Deepak Kalro]<br>
[mailto:pmusyok@ncsu.edu Philip Musyoki]
----

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-12-02T07:40:33Z

Adeshmu: /* Test Plan */

==='''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<br>

2. Any member of a team should be able to select a review to be done by their team.<br>

3. Team members should not be allowed to edit a review simultaneously.<br>

4. The responses as well as the response_maps in the database should be deleted when the instructor decides to the change the 'Review Strategy' after the reviews have already started. <br>

In summary, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

==Database Migrations==
We will add the following fields in existing models of the Expertiza.

1. To assign team based reviewing attribute to the assignemnts a new boolean field reviewer_is_team was added to the with the default set to false.

2. To create a common response for all the team members we added a team_id field to the ResponseMap model. This identifies the reviewer team.

3. To prevent concurrent editing of the reviews by the team members we lock the response in the ResponseMap. This is check is based on the new is_locked field.

4. To identify the user who has locked the review we have also added a locked_by field in the ResponseMap which carries the current_user.id.

[[File:Db_migr13.png|centre]]

==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. The default value for the checkbox is "false". Thus, it will not break any existing functionality.
<pre>
...

<tr id="reviewer_is_team">
<td>
<input name="assignment_form[assignment][reviewer_is_team]" type="hidden" value="false"/>
<%= check_box_tag('assignment_form[assignment][reviewer_is_team]', 'true', @assignment_form.assignment.reviewer_is_team) %>
<%= label_tag('assignment_form[assignment][reviewer_is_team]', 'Reviews are to be performed by teams.') %>
</td>
</tr>
...
</pre>
<br>

2. For this feature to work we must create correct mappings. 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. In our design we are creating only one ResponseMap per team, i.e if the "reviewer_is_team" is set by the instructor, the ResponseMap created will have the reviewer_id as the participant_id of the requesting student and the team_id as the id of requesting students team in that assignment. Now to map this single response to all students in a team, we changed the strategy which returns response_mappings, in the "student_review_controller", for a particular reviewer. If the assignment has team_reviewers, then we find the responses by "team_id", and if there are no team reviewers for the assignment then we return responses by matching the "reviewer_id". Thus, if our mappings are created correctly, then the entire team will be directed to a single response_map and thus a single response irrespective of who requests the review. Thus, any of the team members will be able to request reviews as as the mappings will created with the team_id. The reason for us to not set the "reviewer_id" null or 0 for team reviewers is that, some of the functionalities like number of reviews, scores are all mapped to a single participant. Thus, if that is set that to any value, we will have to define all new methods for team reviewers. But, now we can use all those functions on our response and then make that same response object available to all members of the team. By doing this, we are neither creating redundant maps and nor are we defining new methods for the same functions. The code snippet below shows our new strategy to find the responses for a particular reviewer.
<pre>
...
# E17A0 If an assignment is to be reviewed by a team, select it by team_id otherwise by 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
...
</pre>
<br>

3. This is an important feature since if we allow teammates to edit reviews concurrently, each of them will overwrite each other's changes. We have handled this by using the ''is_locked'' and ''locked_by'' field in the response_map table. Using these fields, we will lock the response for the current_user. Thus, when one teammate is editing, the response is locked and that members id is stored in the ''locked_by'' field. Now for other users we will check ''locked_by'' field. If it does not match their id then they will not see the ''edit'' button on the reviews page.
This response is then unlocked when the current_user saves the response. The methods for locking and unlocking the response are defined in the
<pre>
...
#E17A0 Lock response
def lock_response_map response_id
review_response_map = ReviewResponseMap.find_by_id(Response.find(response_id).map_id)
unless review_response_map.nil?
ReviewResponseMap.update(review_response_map.id, :is_locked => true, :locked_by => current_user.id)
end
end

#E17A0 Unlock Response
def unlock_response_map response_id
review_response_map = ReviewResponseMap.find_by_id(response_id)
unless review_response_map.nil?
ReviewResponseMap.update(review_response_map.id, :is_locked => false, :locked_by => current_user.id)
end
end
...
</pre>

4/5. Changes 4 and 5 are both database migrations. Thus, we just add these fields in their respective tables.

6. This feature is provided to handle a rare edge case. Say that the instructor decides to change the review strategy after the reviews have already started. Now, the format of the response_maps already created will not match the response_maps that will be created after the strategy change. Thus, if the instructor wants to change the strategy, s/he can delete all reviews already done, and then instruct students to start over. The ''delete_reviews'' method is defined in the ''assignment'' model. Our method deletes all the response_maps as well as all the response objects created.
<pre>
...
def delete_reviews
responsemap = ResponseMap.where(reviewed_object_id: self.id, type: 'ReviewResponseMap')
response = Response.where(map_id: responsemap.ids)
response.each { |r| Answer.destroy_all(response_id: r.id)}
Response.destroy_all(map_id: responsemap.ids)
ResponseMap.destroy_all(id: responsemap.ids)
end
...
</pre>

==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

6. student_review/_responses.html.erb

7. review_mapping/select_reviewer.html.haml

8. response_controller_spec.rb

==Design Principles 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).<br>

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

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

==Use Case==

<div style="padding: 0px 0px 0px 25px">
[[File:UC_new.png|none]]
</div>

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:
<li> Log in to Expertiza.
<li> Select an assignment.
<li> Select "other's work".
<li> The student can request a review for the team from here.
<li> Depending on the number of reviews allowed and the number of reviews already performed by the team, they will be allotted a new review
<li> Begin the review.
<li> Only one member of the team can edit the review at an given time.
<li> All restrictions that apply to individual reviewers, also apply to teams (e.g. like a individual reviewer, a team also cannot have more than 2 outstanding incomplete reviews).
<li> Complete the review and Click Submit.
<br>

==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.
<br>
'''Current Implementation is as follows:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Current_implementation1.png|none|frame]]
</div>

----

<br>
'''New Implementation will be as shown below:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_syn_chkbox.png|none|frame]]
</div>
----

<br>
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.
<br>
'''If the assignment has individual reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Student_review1.png|none|frame]]
</div>
----

<br>
'''If the assignment has team reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_review_req.png|none|frame]]
</div>
----

<br>

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 includes testing for the new team-based reviewing functionality that we have added. Our test plan includes the following test methods:<br>

*new
1. Test the delete_reviews method to check whether it asks for a confirmation before deleting the reviews.<br>
2. Test the delete_reviews method to check whether it displays the success flash message on deletion of reviews.<br>
3. Test the action_allowed? method to check whether it denies certain action when the review is locked by a user other than current user.<br>
4. Test the action_allowed? method to check whether it allows certain action when the review is locked by current user.<br>
5. Test the reviewer_is_team_member method to check whether the current user is a member of the assignment review team.<br>

*old
1. If the review for the Assignment will have team id instead of the participant id in Response Map.<br>

2. If for an assignment the instructor can successfully apply the reviewer_is_team? attribute.<br>

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

4. If the team based reviewing functionality works in flow with the student based reviewing.<br>

==Team Information==
[mailto:ashah22@ncsu.edu Aditya Shah]<br>
[mailto:adeshmu@ncsu.edu Amey Deshmukh]<br>
[mailto:dkalro@ncsu.edu Deepak Kalro]<br>
[mailto:pmusyok@ncsu.edu Philip Musyoki]
----

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-12-02T07:39:32Z

Adeshmu: /* Test Plan */

==='''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<br>

2. Any member of a team should be able to select a review to be done by their team.<br>

3. Team members should not be allowed to edit a review simultaneously.<br>

4. The responses as well as the response_maps in the database should be deleted when the instructor decides to the change the 'Review Strategy' after the reviews have already started. <br>

In summary, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

==Database Migrations==
We will add the following fields in existing models of the Expertiza.

1. To assign team based reviewing attribute to the assignemnts a new boolean field reviewer_is_team was added to the with the default set to false.

2. To create a common response for all the team members we added a team_id field to the ResponseMap model. This identifies the reviewer team.

3. To prevent concurrent editing of the reviews by the team members we lock the response in the ResponseMap. This is check is based on the new is_locked field.

4. To identify the user who has locked the review we have also added a locked_by field in the ResponseMap which carries the current_user.id.

[[File:Db_migr13.png|centre]]

==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. The default value for the checkbox is "false". Thus, it will not break any existing functionality.
<pre>
...

<tr id="reviewer_is_team">
<td>
<input name="assignment_form[assignment][reviewer_is_team]" type="hidden" value="false"/>
<%= check_box_tag('assignment_form[assignment][reviewer_is_team]', 'true', @assignment_form.assignment.reviewer_is_team) %>
<%= label_tag('assignment_form[assignment][reviewer_is_team]', 'Reviews are to be performed by teams.') %>
</td>
</tr>
...
</pre>
<br>

2. For this feature to work we must create correct mappings. 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. In our design we are creating only one ResponseMap per team, i.e if the "reviewer_is_team" is set by the instructor, the ResponseMap created will have the reviewer_id as the participant_id of the requesting student and the team_id as the id of requesting students team in that assignment. Now to map this single response to all students in a team, we changed the strategy which returns response_mappings, in the "student_review_controller", for a particular reviewer. If the assignment has team_reviewers, then we find the responses by "team_id", and if there are no team reviewers for the assignment then we return responses by matching the "reviewer_id". Thus, if our mappings are created correctly, then the entire team will be directed to a single response_map and thus a single response irrespective of who requests the review. Thus, any of the team members will be able to request reviews as as the mappings will created with the team_id. The reason for us to not set the "reviewer_id" null or 0 for team reviewers is that, some of the functionalities like number of reviews, scores are all mapped to a single participant. Thus, if that is set that to any value, we will have to define all new methods for team reviewers. But, now we can use all those functions on our response and then make that same response object available to all members of the team. By doing this, we are neither creating redundant maps and nor are we defining new methods for the same functions. The code snippet below shows our new strategy to find the responses for a particular reviewer.
<pre>
...
# E17A0 If an assignment is to be reviewed by a team, select it by team_id otherwise by 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
...
</pre>
<br>

3. This is an important feature since if we allow teammates to edit reviews concurrently, each of them will overwrite each other's changes. We have handled this by using the ''is_locked'' and ''locked_by'' field in the response_map table. Using these fields, we will lock the response for the current_user. Thus, when one teammate is editing, the response is locked and that members id is stored in the ''locked_by'' field. Now for other users we will check ''locked_by'' field. If it does not match their id then they will not see the ''edit'' button on the reviews page.
This response is then unlocked when the current_user saves the response. The methods for locking and unlocking the response are defined in the
<pre>
...
#E17A0 Lock response
def lock_response_map response_id
review_response_map = ReviewResponseMap.find_by_id(Response.find(response_id).map_id)
unless review_response_map.nil?
ReviewResponseMap.update(review_response_map.id, :is_locked => true, :locked_by => current_user.id)
end
end

#E17A0 Unlock Response
def unlock_response_map response_id
review_response_map = ReviewResponseMap.find_by_id(response_id)
unless review_response_map.nil?
ReviewResponseMap.update(review_response_map.id, :is_locked => false, :locked_by => current_user.id)
end
end
...
</pre>

4/5. Changes 4 and 5 are both database migrations. Thus, we just add these fields in their respective tables.

6. This feature is provided to handle a rare edge case. Say that the instructor decides to change the review strategy after the reviews have already started. Now, the format of the response_maps already created will not match the response_maps that will be created after the strategy change. Thus, if the instructor wants to change the strategy, s/he can delete all reviews already done, and then instruct students to start over. The ''delete_reviews'' method is defined in the ''assignment'' model. Our method deletes all the response_maps as well as all the response objects created.
<pre>
...
def delete_reviews
responsemap = ResponseMap.where(reviewed_object_id: self.id, type: 'ReviewResponseMap')
response = Response.where(map_id: responsemap.ids)
response.each { |r| Answer.destroy_all(response_id: r.id)}
Response.destroy_all(map_id: responsemap.ids)
ResponseMap.destroy_all(id: responsemap.ids)
end
...
</pre>

==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

6. student_review/_responses.html.erb

7. review_mapping/select_reviewer.html.haml

8. response_controller_spec.rb

==Design Principles 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).<br>

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

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

==Use Case==

<div style="padding: 0px 0px 0px 25px">
[[File:UC_new.png|none]]
</div>

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:
<li> Log in to Expertiza.
<li> Select an assignment.
<li> Select "other's work".
<li> The student can request a review for the team from here.
<li> Depending on the number of reviews allowed and the number of reviews already performed by the team, they will be allotted a new review
<li> Begin the review.
<li> Only one member of the team can edit the review at an given time.
<li> All restrictions that apply to individual reviewers, also apply to teams (e.g. like a individual reviewer, a team also cannot have more than 2 outstanding incomplete reviews).
<li> Complete the review and Click Submit.
<br>

==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.
<br>
'''Current Implementation is as follows:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Current_implementation1.png|none|frame]]
</div>

----

<br>
'''New Implementation will be as shown below:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_syn_chkbox.png|none|frame]]
</div>
----

<br>
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.
<br>
'''If the assignment has individual reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Student_review1.png|none|frame]]
</div>
----

<br>
'''If the assignment has team reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_review_req.png|none|frame]]
</div>
----

<br>

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 includes testing for the new team-based reviewing functionality that we have added. Our test plan includes the following test methods:<br>

*new
1. Test the delete review method to check whether it asks for a confirmation before deleting the reviews.<br>
2. Test the delete review method to check whether it displays the success flash message on deletion of reviews.<br>
3. Test the action_allowed? method to check whether it denies certain action when the review is locked by a user other than current user.<br>
4. Test the action_allowed? method to check whether it allows certain action when the review is locked by current user.<br>
5. Test the reviewer_is_team_member method to check whether the current user is a member of the assignment review team.<br>

*old
1. If the review for the Assignment will have team id instead of the participant id in Response Map.<br>

2. If for an assignment the instructor can successfully apply the reviewer_is_team? attribute.<br>

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

4. If the team based reviewing functionality works in flow with the student based reviewing.<br>

==Team Information==
[mailto:ashah22@ncsu.edu Aditya Shah]<br>
[mailto:adeshmu@ncsu.edu Amey Deshmukh]<br>
[mailto:dkalro@ncsu.edu Deepak Kalro]<br>
[mailto:pmusyok@ncsu.edu Philip Musyoki]
----

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-12-02T07:34:15Z

Adeshmu: /* Test Plan */

==='''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<br>

2. Any member of a team should be able to select a review to be done by their team.<br>

3. Team members should not be allowed to edit a review simultaneously.<br>

4. The responses as well as the response_maps in the database should be deleted when the instructor decides to the change the 'Review Strategy' after the reviews have already started. <br>

In summary, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

==Database Migrations==
We will add the following fields in existing models of the Expertiza.

1. To assign team based reviewing attribute to the assignemnts a new boolean field reviewer_is_team was added to the with the default set to false.

2. To create a common response for all the team members we added a team_id field to the ResponseMap model. This identifies the reviewer team.

3. To prevent concurrent editing of the reviews by the team members we lock the response in the ResponseMap. This is check is based on the new is_locked field.

4. To identify the user who has locked the review we have also added a locked_by field in the ResponseMap which carries the current_user.id.

[[File:Db_migr13.png|centre]]

==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. The default value for the checkbox is "false". Thus, it will not break any existing functionality.
<pre>
...

<tr id="reviewer_is_team">
<td>
<input name="assignment_form[assignment][reviewer_is_team]" type="hidden" value="false"/>
<%= check_box_tag('assignment_form[assignment][reviewer_is_team]', 'true', @assignment_form.assignment.reviewer_is_team) %>
<%= label_tag('assignment_form[assignment][reviewer_is_team]', 'Reviews are to be performed by teams.') %>
</td>
</tr>
...
</pre>
<br>

2. For this feature to work we must create correct mappings. 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. In our design we are creating only one ResponseMap per team, i.e if the "reviewer_is_team" is set by the instructor, the ResponseMap created will have the reviewer_id as the participant_id of the requesting student and the team_id as the id of requesting students team in that assignment. Now to map this single response to all students in a team, we changed the strategy which returns response_mappings, in the "student_review_controller", for a particular reviewer. If the assignment has team_reviewers, then we find the responses by "team_id", and if there are no team reviewers for the assignment then we return responses by matching the "reviewer_id". Thus, if our mappings are created correctly, then the entire team will be directed to a single response_map and thus a single response irrespective of who requests the review. Thus, any of the team members will be able to request reviews as as the mappings will created with the team_id. The reason for us to not set the "reviewer_id" null or 0 for team reviewers is that, some of the functionalities like number of reviews, scores are all mapped to a single participant. Thus, if that is set that to any value, we will have to define all new methods for team reviewers. But, now we can use all those functions on our response and then make that same response object available to all members of the team. By doing this, we are neither creating redundant maps and nor are we defining new methods for the same functions. The code snippet below shows our new strategy to find the responses for a particular reviewer.
<pre>
...
# E17A0 If an assignment is to be reviewed by a team, select it by team_id otherwise by 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
...
</pre>
<br>

3. This is an important feature since if we allow teammates to edit reviews concurrently, each of them will overwrite each other's changes. We have handled this by using the ''is_locked'' and ''locked_by'' field in the response_map table. Using these fields, we will lock the response for the current_user. Thus, when one teammate is editing, the response is locked and that members id is stored in the ''locked_by'' field. Now for other users we will check ''locked_by'' field. If it does not match their id then they will not see the ''edit'' button on the reviews page.
This response is then unlocked when the current_user saves the response. The methods for locking and unlocking the response are defined in the
<pre>
...
#E17A0 Lock response
def lock_response_map response_id
review_response_map = ReviewResponseMap.find_by_id(Response.find(response_id).map_id)
unless review_response_map.nil?
ReviewResponseMap.update(review_response_map.id, :is_locked => true, :locked_by => current_user.id)
end
end

#E17A0 Unlock Response
def unlock_response_map response_id
review_response_map = ReviewResponseMap.find_by_id(response_id)
unless review_response_map.nil?
ReviewResponseMap.update(review_response_map.id, :is_locked => false, :locked_by => current_user.id)
end
end
...
</pre>

4/5. Changes 4 and 5 are both database migrations. Thus, we just add these fields in their respective tables.

6. This feature is provided to handle a rare edge case. Say that the instructor decides to change the review strategy after the reviews have already started. Now, the format of the response_maps already created will not match the response_maps that will be created after the strategy change. Thus, if the instructor wants to change the strategy, s/he can delete all reviews already done, and then instruct students to start over. The ''delete_reviews'' method is defined in the ''assignment'' model. Our method deletes all the response_maps as well as all the response objects created.
<pre>
...
def delete_reviews
responsemap = ResponseMap.where(reviewed_object_id: self.id, type: 'ReviewResponseMap')
response = Response.where(map_id: responsemap.ids)
response.each { |r| Answer.destroy_all(response_id: r.id)}
Response.destroy_all(map_id: responsemap.ids)
ResponseMap.destroy_all(id: responsemap.ids)
end
...
</pre>

==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

6. student_review/_responses.html.erb

7. review_mapping/select_reviewer.html.haml

8. response_controller_spec.rb

==Design Principles 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).<br>

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

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

==Use Case==

<div style="padding: 0px 0px 0px 25px">
[[File:UC_new.png|none]]
</div>

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:
<li> Log in to Expertiza.
<li> Select an assignment.
<li> Select "other's work".
<li> The student can request a review for the team from here.
<li> Depending on the number of reviews allowed and the number of reviews already performed by the team, they will be allotted a new review
<li> Begin the review.
<li> Only one member of the team can edit the review at an given time.
<li> All restrictions that apply to individual reviewers, also apply to teams (e.g. like a individual reviewer, a team also cannot have more than 2 outstanding incomplete reviews).
<li> Complete the review and Click Submit.
<br>

==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.
<br>
'''Current Implementation is as follows:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Current_implementation1.png|none|frame]]
</div>

----

<br>
'''New Implementation will be as shown below:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_syn_chkbox.png|none|frame]]
</div>
----

<br>
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.
<br>
'''If the assignment has individual reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Student_review1.png|none|frame]]
</div>
----

<br>
'''If the assignment has team reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_review_req.png|none|frame]]
</div>
----

<br>

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 includes testing for the new team-based reviewing functionality that we have added. Our test plan includes the following test methods:<br>

*new
1. Test the delete review method to check whether it asks for a confirmation before deleting the reviews.<br>
2. Test the delete review method to check whether it displays the success flash message on deletion of reviews.<br>
3. Test the action_allowed? method to check whether it denies any action when the review is locked.<br>
4. 3. Test the action_allowed? method to check whether the current user is a member of the assignment review team.<br>

*old
1. If the review for the Assignment will have team id instead of the participant id in Response Map.<br>

2. If for an assignment the instructor can successfully apply the reviewer_is_team? attribute.<br>

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

4. If the team based reviewing functionality works in flow with the student based reviewing.<br>

==Team Information==
[mailto:ashah22@ncsu.edu Aditya Shah]<br>
[mailto:adeshmu@ncsu.edu Amey Deshmukh]<br>
[mailto:dkalro@ncsu.edu Deepak Kalro]<br>
[mailto:pmusyok@ncsu.edu Philip Musyoki]
----

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-12-02T02:26:33Z

Adeshmu: /* Files Involved */

==='''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<br>

2. Any member of a team should be able to select a review to be done by their team.<br>

3. Team members should not be allowed to edit a review simultaneously.<br>

4. The responses as well as the response_maps in the database should be deleted when the instructor decides to the change the 'Review Strategy' after the reviews have already started. <br>

In summary, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

==Database Migrations==
We will add the following fields in existing models of the Expertiza.

1. To assign team based reviewing attribute to the assignemnts a new boolean field reviewer_is_team was added to the with the default set to false.

2. To create a common response for all the team members we added a team_id field to the ResponseMap model. This identifies the reviewer team.

3. To prevent concurrent editing of the reviews by the team members we lock the response in the ResponseMap. This is check is based on the new is_locked field.

4. To identify the user who has locked the review we have also added a locked_by field in the ResponseMap which carries the current_user.id.

[[File:Db_migr13.png|centre]]

==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. The default value for the checkbox is "false". Thus, it will not break any existing functionality.
<pre>
...

<tr id="reviewer_is_team">
<td>
<input name="assignment_form[assignment][reviewer_is_team]" type="hidden" value="false"/>
<%= check_box_tag('assignment_form[assignment][reviewer_is_team]', 'true', @assignment_form.assignment.reviewer_is_team) %>
<%= label_tag('assignment_form[assignment][reviewer_is_team]', 'Reviews are to be performed by teams.') %>
</td>
</tr>
...
</pre>
<br>

2. For this feature to work we must create correct mappings. 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. In our design we are creating only one ResponseMap per team, i.e if the "reviewer_is_team" is set by the instructor, the ResponseMap created will have the reviewer_id as the participant_id of the requesting student and the team_id as the id of requesting students team in that assignment. Now to map this single response to all students in a team, we changed the strategy which returns response_mappings, in the "student_review_controller", for a particular reviewer. If the assignment has team_reviewers, then we find the responses by "team_id", and if there are no team reviewers for the assignment then we return responses by matching the "reviewer_id". Thus, if our mappings are created correctly, then the entire team will be directed to a single response_map and thus a single response irrespective of who requests the review. Thus, any of the team members will be able to request reviews as as the mappings will created with the team_id. The reason for us to not set the "reviewer_id" null or 0 for team reviewers is that, some of the functionalities like number of reviews, scores are all mapped to a single participant. Thus, if that is set that to any value, we will have to define all new methods for team reviewers. But, now we can use all those functions on our response and then make that same response object available to all members of the team. By doing this, we are neither creating redundant maps and nor are we defining new methods for the same functions. The code snippet below shows our new strategy to find the responses for a particular reviewer.
<pre>
...
# E17A0 If an assignment is to be reviewed by a team, select it by team_id otherwise by 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
...
</pre>
<br>

3. This is an important feature since if we allow teammates to edit reviews concurrently, each of them will overwrite each other's changes. We have handled this by using the ''is_locked'' and ''locked_by'' field in the response_map table. Using these fields, we will lock the response for the current_user. Thus, when one teammate is editing, the response is locked and that members id is stored in the ''locked_by'' field. Now for other users we will check ''locked_by'' field. If it does not match their id then they will not see the ''edit'' button on the reviews page.
This response is then unlocked when the current_user saves the response. The methods for locking and unlocking the response are defined in the
<pre>
...
#E17A0 Lock response
def lock_response_map response_id
review_response_map = ReviewResponseMap.find_by_id(Response.find(response_id).map_id)
unless review_response_map.nil?
ReviewResponseMap.update(review_response_map.id, :is_locked => true, :locked_by => current_user.id)
end
end

#E17A0 Unlock Response
def unlock_response_map response_id
review_response_map = ReviewResponseMap.find_by_id(response_id)
unless review_response_map.nil?
ReviewResponseMap.update(review_response_map.id, :is_locked => false, :locked_by => current_user.id)
end
end
...
</pre>

4/5. Changes 4 and 5 are both database migrations. Thus, we just add these fields in their respective tables.

6. This feature is provided to handle a rare edge case. Say that the instructor decides to change the review strategy after the reviews have already started. Now, the format of the response_maps already created will not match the response_maps that will be created after the strategy change. Thus, if the instructor wants to change the strategy, s/he can delete all reviews already done, and then instruct students to start over. The ''delete_reviews'' method is defined in the ''assignment'' model. Our method deletes all the response_maps as well as all the response objects created.
<pre>
...
def delete_reviews
responsemap = ResponseMap.where(reviewed_object_id: self.id, type: 'ReviewResponseMap')
response = Response.where(map_id: responsemap.ids)
response.each { |r| Answer.destroy_all(response_id: r.id)}
Response.destroy_all(map_id: responsemap.ids)
ResponseMap.destroy_all(id: responsemap.ids)
end
...
</pre>

==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

6. student_review/_responses.html.erb

7. review_mapping/select_reviewer.html.haml

8. response_controller_spec.rb

==Design Principles 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).<br>

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

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

==Use Case==

<div style="padding: 0px 0px 0px 25px">
[[File:UC_new.png|none]]
</div>

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:
<li> Log in to Expertiza.
<li> Select an assignment.
<li> Select "other's work".
<li> The student can request a review for the team from here.
<li> Depending on the number of reviews allowed and the number of reviews already performed by the team, they will be allotted a new review
<li> Begin the review.
<li> Only one member of the team can edit the review at an given time.
<li> All restrictions that apply to individual reviewers, also apply to teams (e.g. like a individual reviewer, a team also cannot have more than 2 outstanding incomplete reviews).
<li> Complete the review and Click Submit.
<br>

==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.
<br>
'''Current Implementation is as follows:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Current_implementation1.png|none|frame]]
</div>

----

<br>
'''New Implementation will be as shown below:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_syn_chkbox.png|none|frame]]
</div>
----

<br>
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.
<br>
'''If the assignment has individual reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Student_review1.png|none|frame]]
</div>
----

<br>
'''If the assignment has team reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_review_req.png|none|frame]]
</div>
----

<br>

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:<br>

1. If the review for the Assignment will have team id instead of the participant id in Response Map.<br>

2. If for an assignment the instructor can successfully apply the reviewer_is_team? attribute.<br>

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

4. If the team based reviewing functionality works in flow with the student based reviewing.<br>

==Team Information==
[mailto:ashah22@ncsu.edu Aditya Shah]<br>
[mailto:adeshmu@ncsu.edu Amey Deshmukh]<br>
[mailto:dkalro@ncsu.edu Deepak Kalro]<br>
[mailto:pmusyok@ncsu.edu Philip Musyoki]
----

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-12-02T01:58:55Z

Adeshmu: /* Design Principles to be Followed */

==='''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<br>

2. Any member of a team should be able to select a review to be done by their team.<br>

3. Team members should not be allowed to edit a review simultaneously.<br>

4. The responses as well as the response_maps in the database should be deleted when the instructor decides to the change the 'Review Strategy' after the reviews have already started. <br>

In summary, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

==Database Migrations==
We will add the following fields in existing models of the Expertiza.

1. To assign team based reviewing attribute to the assignemnts a new boolean field reviewer_is_team was added to the with the default set to false.

2. To create a common response for all the team members we added a team_id field to the ResponseMap model. This identifies the reviewer team.

3. To prevent concurrent editing of the reviews by the team members we lock the response in the ResponseMap. This is check is based on the new is_locked field.

4. To identify the user who has locked the review we have also added a locked_by field in the ResponseMap which carries the current_user.id.

[[File:Db_migr13.png|centre]]

==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. The default value for the checkbox is "false". Thus, it will not break any existing functionality.
<pre>
...

<tr id="reviewer_is_team">
<td>
<input name="assignment_form[assignment][reviewer_is_team]" type="hidden" value="false"/>
<%= check_box_tag('assignment_form[assignment][reviewer_is_team]', 'true', @assignment_form.assignment.reviewer_is_team) %>
<%= label_tag('assignment_form[assignment][reviewer_is_team]', 'Reviews are to be performed by teams.') %>
</td>
</tr>
...
</pre>
<br>

2. For this feature to work we must create correct mappings. 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. In our design we are creating only one ResponseMap per team, i.e if the "reviewer_is_team" is set by the instructor, the ResponseMap created will have the reviewer_id as the participant_id of the requesting student and the team_id as the id of requesting students team in that assignment. Now to map this single response to all students in a team, we changed the strategy which returns response_mappings, in the "student_review_controller", for a particular reviewer. If the assignment has team_reviewers, then we find the responses by "team_id", and if there are no team reviewers for the assignment then we return responses by matching the "reviewer_id". Thus, if our mappings are created correctly, then the entire team will be directed to a single response_map and thus a single response irrespective of who requests the review. Thus, any of the team members will be able to request reviews as as the mappings will created with the team_id. The reason for us to not set the "reviewer_id" null or 0 for team reviewers is that, some of the functionalities like number of reviews, scores are all mapped to a single participant. Thus, if that is set that to any value, we will have to define all new methods for team reviewers. But, now we can use all those functions on our response and then make that same response object available to all members of the team. By doing this, we are neither creating redundant maps and nor are we defining new methods for the same functions. The code snippet below shows our new strategy to find the responses for a particular reviewer.
<pre>
...
# E17A0 If an assignment is to be reviewed by a team, select it by team_id otherwise by 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
...
</pre>
<br>

3. This is an important feature since if we allow teammates to edit reviews concurrently, each of them will overwrite each other's changes. We have handled this by using the ''is_locked'' and ''locked_by'' field in the response_map table. Using these fields, we will lock the response for the current_user. Thus, when one teammate is editing, the response is locked and that members id is stored in the ''locked_by'' field. Now for other users we will check ''locked_by'' field. If it does not match their id then they will not see the ''edit'' button on the reviews page.
This response is then unlocked when the current_user saves the response. The methods for locking and unlocking the response are defined in the
<pre>
...
#E17A0 Lock response
def lock_response_map response_id
review_response_map = ReviewResponseMap.find_by_id(Response.find(response_id).map_id)
unless review_response_map.nil?
ReviewResponseMap.update(review_response_map.id, :is_locked => true, :locked_by => current_user.id)
end
end

#E17A0 Unlock Response
def unlock_response_map response_id
review_response_map = ReviewResponseMap.find_by_id(response_id)
unless review_response_map.nil?
ReviewResponseMap.update(review_response_map.id, :is_locked => false, :locked_by => current_user.id)
end
end
...
</pre>

4/5. Changes 4 and 5 are both database migrations. Thus, we just add these fields in their respective tables.

6. This feature is provided to handle a rare edge case. Say that the instructor decides to change the review strategy after the reviews have already started. Now, the format of the response_maps already created will not match the response_maps that will be created after the strategy change. Thus, if the instructor wants to change the strategy, s/he can delete all reviews already done, and then instruct students to start over. The ''delete_reviews'' method is defined in the ''assignment'' model. Our method deletes all the response_maps as well as all the response objects created.
<pre>
...
def delete_reviews
responsemap = ResponseMap.where(reviewed_object_id: self.id, type: 'ReviewResponseMap')
response = Response.where(map_id: responsemap.ids)
response.each { |r| Answer.destroy_all(response_id: r.id)}
Response.destroy_all(map_id: responsemap.ids)
ResponseMap.destroy_all(id: responsemap.ids)
end
...
</pre>

==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 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).<br>

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

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

==Use Case==

<div style="padding: 0px 0px 0px 25px">
[[File:UC_new.png|none]]
</div>

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:
<li> Log in to Expertiza.
<li> Select an assignment.
<li> Select "other's work".
<li> The student can request a review for the team from here.
<li> Depending on the number of reviews allowed and the number of reviews already performed by the team, they will be allotted a new review
<li> Begin the review.
<li> Only one member of the team can edit the review at an given time.
<li> All restrictions that apply to individual reviewers, also apply to teams (e.g. like a individual reviewer, a team also cannot have more than 2 outstanding incomplete reviews).
<li> Complete the review and Click Submit.
<br>

==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.
<br>
'''Current Implementation is as follows:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Current_implementation1.png|none|frame]]
</div>

----

<br>
'''New Implementation will be as shown below:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_syn_chkbox.png|none|frame]]
</div>
----

<br>
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.
<br>
'''If the assignment has individual reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Student_review1.png|none|frame]]
</div>
----

<br>
'''If the assignment has team reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_review_req.png|none|frame]]
</div>
----

<br>

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:<br>

1. If the review for the Assignment will have team id instead of the participant id in Response Map.<br>

2. If for an assignment the instructor can successfully apply the reviewer_is_team? attribute.<br>

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

4. If the team based reviewing functionality works in flow with the student based reviewing.<br>

==Team Information==
[mailto:ashah22@ncsu.edu Aditya Shah]<br>
[mailto:adeshmu@ncsu.edu Amey Deshmukh]<br>
[mailto:dkalro@ncsu.edu Deepak Kalro]<br>
[mailto:pmusyok@ncsu.edu Philip Musyoki]
----

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-12-02T01:58:34Z

Adeshmu:

==='''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<br>

2. Any member of a team should be able to select a review to be done by their team.<br>

3. Team members should not be allowed to edit a review simultaneously.<br>

4. The responses as well as the response_maps in the database should be deleted when the instructor decides to the change the 'Review Strategy' after the reviews have already started. <br>

In summary, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

==Database Migrations==
We will add the following fields in existing models of the Expertiza.

1. To assign team based reviewing attribute to the assignemnts a new boolean field reviewer_is_team was added to the with the default set to false.

2. To create a common response for all the team members we added a team_id field to the ResponseMap model. This identifies the reviewer team.

3. To prevent concurrent editing of the reviews by the team members we lock the response in the ResponseMap. This is check is based on the new is_locked field.

4. To identify the user who has locked the review we have also added a locked_by field in the ResponseMap which carries the current_user.id.

[[File:Db_migr13.png|centre]]

==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. The default value for the checkbox is "false". Thus, it will not break any existing functionality.
<pre>
...

<tr id="reviewer_is_team">
<td>
<input name="assignment_form[assignment][reviewer_is_team]" type="hidden" value="false"/>
<%= check_box_tag('assignment_form[assignment][reviewer_is_team]', 'true', @assignment_form.assignment.reviewer_is_team) %>
<%= label_tag('assignment_form[assignment][reviewer_is_team]', 'Reviews are to be performed by teams.') %>
</td>
</tr>
...
</pre>
<br>

2. For this feature to work we must create correct mappings. 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. In our design we are creating only one ResponseMap per team, i.e if the "reviewer_is_team" is set by the instructor, the ResponseMap created will have the reviewer_id as the participant_id of the requesting student and the team_id as the id of requesting students team in that assignment. Now to map this single response to all students in a team, we changed the strategy which returns response_mappings, in the "student_review_controller", for a particular reviewer. If the assignment has team_reviewers, then we find the responses by "team_id", and if there are no team reviewers for the assignment then we return responses by matching the "reviewer_id". Thus, if our mappings are created correctly, then the entire team will be directed to a single response_map and thus a single response irrespective of who requests the review. Thus, any of the team members will be able to request reviews as as the mappings will created with the team_id. The reason for us to not set the "reviewer_id" null or 0 for team reviewers is that, some of the functionalities like number of reviews, scores are all mapped to a single participant. Thus, if that is set that to any value, we will have to define all new methods for team reviewers. But, now we can use all those functions on our response and then make that same response object available to all members of the team. By doing this, we are neither creating redundant maps and nor are we defining new methods for the same functions. The code snippet below shows our new strategy to find the responses for a particular reviewer.
<pre>
...
# E17A0 If an assignment is to be reviewed by a team, select it by team_id otherwise by 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
...
</pre>
<br>

3. This is an important feature since if we allow teammates to edit reviews concurrently, each of them will overwrite each other's changes. We have handled this by using the ''is_locked'' and ''locked_by'' field in the response_map table. Using these fields, we will lock the response for the current_user. Thus, when one teammate is editing, the response is locked and that members id is stored in the ''locked_by'' field. Now for other users we will check ''locked_by'' field. If it does not match their id then they will not see the ''edit'' button on the reviews page.
This response is then unlocked when the current_user saves the response. The methods for locking and unlocking the response are defined in the
<pre>
...
#E17A0 Lock response
def lock_response_map response_id
review_response_map = ReviewResponseMap.find_by_id(Response.find(response_id).map_id)
unless review_response_map.nil?
ReviewResponseMap.update(review_response_map.id, :is_locked => true, :locked_by => current_user.id)
end
end

#E17A0 Unlock Response
def unlock_response_map response_id
review_response_map = ReviewResponseMap.find_by_id(response_id)
unless review_response_map.nil?
ReviewResponseMap.update(review_response_map.id, :is_locked => false, :locked_by => current_user.id)
end
end
...
</pre>

4/5. Changes 4 and 5 are both database migrations. Thus, we just add these fields in their respective tables.

6. This feature is provided to handle a rare edge case. Say that the instructor decides to change the review strategy after the reviews have already started. Now, the format of the response_maps already created will not match the response_maps that will be created after the strategy change. Thus, if the instructor wants to change the strategy, s/he can delete all reviews already done, and then instruct students to start over. The ''delete_reviews'' method is defined in the ''assignment'' model. Our method deletes all the response_maps as well as all the response objects created.
<pre>
...
def delete_reviews
responsemap = ResponseMap.where(reviewed_object_id: self.id, type: 'ReviewResponseMap')
response = Response.where(map_id: responsemap.ids)
response.each { |r| Answer.destroy_all(response_id: r.id)}
Response.destroy_all(map_id: responsemap.ids)
ResponseMap.destroy_all(id: responsemap.ids)
end
...
</pre>

==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).<br>

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

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

==Use Case==

<div style="padding: 0px 0px 0px 25px">
[[File:UC_new.png|none]]
</div>

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:
<li> Log in to Expertiza.
<li> Select an assignment.
<li> Select "other's work".
<li> The student can request a review for the team from here.
<li> Depending on the number of reviews allowed and the number of reviews already performed by the team, they will be allotted a new review
<li> Begin the review.
<li> Only one member of the team can edit the review at an given time.
<li> All restrictions that apply to individual reviewers, also apply to teams (e.g. like a individual reviewer, a team also cannot have more than 2 outstanding incomplete reviews).
<li> Complete the review and Click Submit.
<br>

==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.
<br>
'''Current Implementation is as follows:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Current_implementation1.png|none|frame]]
</div>

----

<br>
'''New Implementation will be as shown below:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_syn_chkbox.png|none|frame]]
</div>
----

<br>
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.
<br>
'''If the assignment has individual reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Student_review1.png|none|frame]]
</div>
----

<br>
'''If the assignment has team reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_review_req.png|none|frame]]
</div>
----

<br>

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:<br>

1. If the review for the Assignment will have team id instead of the participant id in Response Map.<br>

2. If for an assignment the instructor can successfully apply the reviewer_is_team? attribute.<br>

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

4. If the team based reviewing functionality works in flow with the student based reviewing.<br>

==Team Information==
[mailto:ashah22@ncsu.edu Aditya Shah]<br>
[mailto:adeshmu@ncsu.edu Amey Deshmukh]<br>
[mailto:dkalro@ncsu.edu Deepak Kalro]<br>
[mailto:pmusyok@ncsu.edu Philip Musyoki]
----

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-11-12T23:33:33Z

Adeshmu: /* Test Plan */

==='''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.<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. We can use ActiveRecord record locking method to lock the current record being edited.<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.<br>
5. Finally, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

==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.<br>
2. This change will be made in the "response_map.rb" model. This model creates all the mapping between the reviewers and reviewees. In the new implementation of expertiza, the "reviewees" can no longer be participants. All reviewees will be teams, although the team can have a single participant. Still, "reviewers" can still be either participants or teams. Thus, we still need to create a proper mapping between reviewers and reviewees for our new feature.
<br>
3. If a review is being is being edited, that review should not be edited by other team members. In case of individual reviewers, there won't be any other reviewers. 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:
<pre>
...
@response = Response.find(params[:id])
@response.lock!
...
</pre>
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:
<pre>
...
@response = Response.find(params[:id])
@response.save!
...
</pre>
4. 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>

==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).<br>

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

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

==Use Case==

<div style="padding: 0px 0px 0px 25px">
[[File:UC_new.png|none]]
</div>

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

5. Primary Sequence:
<li> Log in to Expertiza.
<li> Select an assignment.
<li> Select "other's work".
<li> The student can request a review for the team from here.
<li> Depending on the number of reviews allowed and the number of reviews already performed by the team, they will be allotted a new review
<li> Begin the review.
<li> Only one member of the team can edit the review at an given time.
<li> All restrictions that apply to individual reviewers, also apply to teams (e.g. like a individual reviewer, a team also cannot have more than 2 outstanding incomplete reviews).
<li> Complete the review and Click Submit.
<br>

==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.
<br>
'''Current Implementation is as follows:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Current_implementation1.png|none|frame]]
</div>

----

<br>
'''New Implementation will be as shown below:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_syn_chkbox.png|none|frame]]
</div>
----

<br>
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.
<br>
'''If the assignment has individual reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Student_review1.png|none|frame]]
</div>
----

<br>
'''If the assignment has team reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_review_req.png|none|frame]]
</div>
----

<br>

==Test Plan==
For the complete testing of the new controller methods to check the functionality of reviewing as a team we have to test:<br>
1. If the review for the Assignment will have team id instead of the participant id in Response Map.<br>

2. If for an assignment the instructor can successfully apply the reviewer_is_team? attribute.<br>

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

4. If the team based reviewing functionality works in flow with the student based reviewing.<br>

==Team Information==
[mailto:ashah22@ncsu.edu Aditya Shah]<br>
[mailto:adeshmu@ncsu.edu Amey Deshmukh]<br>
[mailto:dkalro@ncsu.edu Deepak Kalro]<br>
[mailto:pmusyok@ncsu.edu Philip Musyoki]
----

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-11-12T23:33:14Z

Adeshmu: /* Test Plan */

==='''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.<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. We can use ActiveRecord record locking method to lock the current record being edited.<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.<br>
5. Finally, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

==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.<br>
2. This change will be made in the "response_map.rb" model. This model creates all the mapping between the reviewers and reviewees. In the new implementation of expertiza, the "reviewees" can no longer be participants. All reviewees will be teams, although the team can have a single participant. Still, "reviewers" can still be either participants or teams. Thus, we still need to create a proper mapping between reviewers and reviewees for our new feature.
<br>
3. If a review is being is being edited, that review should not be edited by other team members. In case of individual reviewers, there won't be any other reviewers. 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:
<pre>
...
@response = Response.find(params[:id])
@response.lock!
...
</pre>
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:
<pre>
...
@response = Response.find(params[:id])
@response.save!
...
</pre>
4. 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>

==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).<br>

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

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

==Use Case==

<div style="padding: 0px 0px 0px 25px">
[[File:UC_new.png|none]]
</div>

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

5. Primary Sequence:
<li> Log in to Expertiza.
<li> Select an assignment.
<li> Select "other's work".
<li> The student can request a review for the team from here.
<li> Depending on the number of reviews allowed and the number of reviews already performed by the team, they will be allotted a new review
<li> Begin the review.
<li> Only one member of the team can edit the review at an given time.
<li> All restrictions that apply to individual reviewers, also apply to teams (e.g. like a individual reviewer, a team also cannot have more than 2 outstanding incomplete reviews).
<li> Complete the review and Click Submit.
<br>

==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.
<br>
'''Current Implementation is as follows:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Current_implementation1.png|none|frame]]
</div>

----

<br>
'''New Implementation will be as shown below:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_syn_chkbox.png|none|frame]]
</div>
----

<br>
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.
<br>
'''If the assignment has individual reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Student_review1.png|none|frame]]
</div>
----

<br>
'''If the assignment has team reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_review_req.png|none|frame]]
</div>
----

<br>

==Test Plan==
For the complete testing of the new controller methods to check the functionality of reviewing as a team we have to test:
1. If the review for the Assignment will have team id instead of the participant id in Response Map.<br>

2. If for an assignment the instructor can successfully apply the reviewer_is_team? attribute.<br>

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

4. If the team based reviewing functionality works in flow with the student based reviewing.<br>

==Team Information==
[mailto:ashah22@ncsu.edu Aditya Shah]<br>
[mailto:adeshmu@ncsu.edu Amey Deshmukh]<br>
[mailto:dkalro@ncsu.edu Deepak Kalro]<br>
[mailto:pmusyok@ncsu.edu Philip Musyoki]
----

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-11-12T22:44:17Z

Adeshmu: /* Use Case */

==='''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.<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. 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>
<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. Thus a column will have to added to multiple places unncessarily which is not a good design decision. Hence our solution incorporates the addition of reviewer_is_team? to the Assignments table.<br>

5. Finally, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

==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).<br>

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

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

==Use Case==

<div style="padding: 0px 0px 0px 25px">
[[File:UML_new.png|none|frame]]
</div>

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

5. Primary Sequence:
<li> Log in to Expertiza.
<li> Select an assignment.
<li> Select "other's work".
<li> The student can request a review for the team from here.
<li> Depending on the number of reviews allowed and the number of reviews already performed by the team, they will be allotted a new review
<li> Begin the review.
<li> Only one member of the team can edit the review at an given time.
<li> All restrictions that apply to individual reviewers, also apply to teams (e.g. like a individual reviewer, a team also cannot have more than 2 outstanding incomplete reviews).
<li> Complete the review and Click Submit.
<br>

==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.
<br>
'''Current Implementation is as follows:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Current_implementation1.png|none|frame]]
</div>

----

<br>
'''New Implementation will be as shown below:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_syn_chkbox.png|none|frame]]
</div>
----

<br>
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.
<br>
'''If the assignment has individual reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Student_review1.png|none|frame]]
</div>
----

<br>
'''If the assignment has team reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_review_req.png|none|frame]]
</div>
----

<br>

==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==
[mailto:ashah22@ncsu.edu Aditya Shah]<br>
[mailto:adeshmu@ncsu.edu Amey Deshmukh]<br>
[mailto:dkalro@ncsu.edu Deepak Kalro]<br>
[mailto:pmusyok@ncsu.edu Philip Musyoki]
----

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-11-12T22:43:14Z

Adeshmu: /* Use Case */

==='''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.<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. 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>
<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. Thus a column will have to added to multiple places unncessarily which is not a good design decision. Hence our solution incorporates the addition of reviewer_is_team? to the Assignments table.<br>

5. Finally, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

==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).<br>

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

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

==Use Case==

<div style="padding: 0px 0px 0px 25px">
[[File:UML_new.png|none|frame]]
</div>

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:
<li> Log in to Expertiza.
<li> Select an assignment.
<li> Select "other's work".
<li> The student can request a review for the team from here.
<li> Depending on the number of reviews allowed and number of reviews already performed by the team, they will be allotted a new review
<li> Begin the review.
<li> Only one member of the team can edit the review at an given time.
<li> All restrictions that apply to individual reviewers, also apply to teams (e.g. like a individual reviewer, a team also cannot have more than 2 outstanding incomplete reviews).
<li> Complete the review and Click Submit.
<br>

==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.
<br>
'''Current Implementation is as follows:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Current_implementation1.png|none|frame]]
</div>

----

<br>
'''New Implementation will be as shown below:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_syn_chkbox.png|none|frame]]
</div>
----

<br>
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.
<br>
'''If the assignment has individual reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Student_review1.png|none|frame]]
</div>
----

<br>
'''If the assignment has team reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_review_req.png|none|frame]]
</div>
----

<br>

==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==
[mailto:ashah22@ncsu.edu Aditya Shah]<br>
[mailto:adeshmu@ncsu.edu Amey Deshmukh]<br>
[mailto:dkalro@ncsu.edu Deepak Kalro]<br>
[mailto:pmusyok@ncsu.edu Philip Musyoki]
----

File:UML new.png

2017-11-12T22:41:40Z

Adeshmu:

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-11-12T22:38:31Z

Adeshmu: /* Design Principles to be Followed */

==='''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.<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. 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>
<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. Thus a column will have to added to multiple places unncessarily which is not a good design decision. Hence our solution incorporates the addition of reviewer_is_team? to the Assignments table.<br>

5. Finally, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

==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).<br>

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

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

==Use Case==

<div style="padding: 0px 0px 0px 25px">
[[File:Use_Case_(1).jpg|none|frame]]
</div>

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:
<li> Log in to Expertiza.
<li> Select an assignment.
<li> Select "other's work".
<li> The student can request a review for the team from here.
<li> Depending on the number of reviews allowed and number of reviews already performed by the team, they will be allotted a new review
<li> Begin the review.
<li> Only one member of the team can edit the review at an given time.
<li> All restrictions that apply to individual reviewers, also apply to teams (e.g. like a individual reviewer, a team also cannot have more than 2 outstanding incomplete reviews).
<li> Complete the review and Click Submit.
<br>

==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.
<br>
'''Current Implementation is as follows:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Current_implementation1.png|none|frame]]
</div>

----

<br>
'''New Implementation will be as shown below:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_syn_chkbox.png|none|frame]]
</div>
----

<br>
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.
<br>
'''If the assignment has individual reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Student_review1.png|none|frame]]
</div>
----

<br>
'''If the assignment has team reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_review_req.png|none|frame]]
</div>
----

<br>

==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==
[mailto:ashah22@ncsu.edu Aditya Shah]<br>
[mailto:adeshmu@ncsu.edu Amey Deshmukh]<br>
[mailto:dkalro@ncsu.edu Deepak Kalro]<br>
[mailto:pmusyok@ncsu.edu Philip Musyoki]
----

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-11-12T22:38:06Z

Adeshmu: /* Changes to be Implemented */

==='''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.<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. 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>
<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. Thus a column will have to added to multiple places unncessarily which is not a good design decision. Hence our solution incorporates the addition of reviewer_is_team? to the Assignments table.<br>

5. Finally, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

==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).<br>
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.<br>
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.<br>

==Use Case==

<div style="padding: 0px 0px 0px 25px">
[[File:Use_Case_(1).jpg|none|frame]]
</div>

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:
<li> Log in to Expertiza.
<li> Select an assignment.
<li> Select "other's work".
<li> The student can request a review for the team from here.
<li> Depending on the number of reviews allowed and number of reviews already performed by the team, they will be allotted a new review
<li> Begin the review.
<li> Only one member of the team can edit the review at an given time.
<li> All restrictions that apply to individual reviewers, also apply to teams (e.g. like a individual reviewer, a team also cannot have more than 2 outstanding incomplete reviews).
<li> Complete the review and Click Submit.
<br>

==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.
<br>
'''Current Implementation is as follows:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Current_implementation1.png|none|frame]]
</div>

----

<br>
'''New Implementation will be as shown below:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_syn_chkbox.png|none|frame]]
</div>
----

<br>
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.
<br>
'''If the assignment has individual reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Student_review1.png|none|frame]]
</div>
----

<br>
'''If the assignment has team reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_review_req.png|none|frame]]
</div>
----

<br>

==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==
[mailto:ashah22@ncsu.edu Aditya Shah]<br>
[mailto:adeshmu@ncsu.edu Amey Deshmukh]<br>
[mailto:dkalro@ncsu.edu Deepak Kalro]<br>
[mailto:pmusyok@ncsu.edu Philip Musyoki]
----

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-11-12T22:37:09Z

Adeshmu: /* Changes to be Implemented */

==='''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.<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. 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>
<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. Thus a column will have to added to multiple places unncessarily which is not a good design decision. Hence our solution incorporates the addition of reviewer_is_team? to the Assignments table.<br>
5. Finally, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

==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).<br>
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.<br>
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.<br>

==Use Case==

<div style="padding: 0px 0px 0px 25px">
[[File:Use_Case_(1).jpg|none|frame]]
</div>

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:
<li> Log in to Expertiza.
<li> Select an assignment.
<li> Select "other's work".
<li> The student can request a review for the team from here.
<li> Depending on the number of reviews allowed and number of reviews already performed by the team, they will be allotted a new review
<li> Begin the review.
<li> Only one member of the team can edit the review at an given time.
<li> All restrictions that apply to individual reviewers, also apply to teams (e.g. like a individual reviewer, a team also cannot have more than 2 outstanding incomplete reviews).
<li> Complete the review and Click Submit.
<br>

==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.
<br>
'''Current Implementation is as follows:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Current_implementation1.png|none|frame]]
</div>

----

<br>
'''New Implementation will be as shown below:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_syn_chkbox.png|none|frame]]
</div>
----

<br>
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.
<br>
'''If the assignment has individual reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Student_review1.png|none|frame]]
</div>
----

<br>
'''If the assignment has team reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_review_req.png|none|frame]]
</div>
----

<br>

==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==
[mailto:ashah22@ncsu.edu Aditya Shah]<br>
[mailto:adeshmu@ncsu.edu Amey Deshmukh]<br>
[mailto:dkalro@ncsu.edu Deepak Kalro]<br>
[mailto:pmusyok@ncsu.edu Philip Musyoki]
----

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-11-12T22:30:40Z

Adeshmu: /* Changes to be Implemented */

==='''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.<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. 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>
<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>

==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).<br>
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.<br>
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.<br>

==Use Case==

<div style="padding: 0px 0px 0px 25px">
[[File:Use_Case_(1).jpg|none|frame]]
</div>

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:
<li> Log in to Expertiza.
<li> Select an assignment.
<li> Select "other's work".
<li> The student can request a review for the team from here.
<li> Depending on the number of reviews allowed and number of reviews already performed by the team, they will be allotted a new review
<li> Begin the review.
<li> Only one member of the team can edit the review at an given time.
<li> All restrictions that apply to individual reviewers, also apply to teams (e.g. like a individual reviewer, a team also cannot have more than 2 outstanding incomplete reviews).
<li> Complete the review and Click Submit.
<br>

==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.
<br>
'''Current Implementation is as follows:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Current_implementation1.png|none|frame]]
</div>

----

<br>
'''New Implementation will be as shown below:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_syn_chkbox.png|none|frame]]
</div>
----

<br>
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.
<br>
'''If the assignment has individual reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Student_review1.png|none|frame]]
</div>
----

<br>
'''If the assignment has team reviews:'''
<br>
<div style="padding: 0px 0px 0px 25px">
[[File:Improved_review_req.png|none|frame]]
</div>
----

<br>

==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==
[mailto:ashah22@ncsu.edu Aditya Shah]<br>
[mailto:adeshmu@ncsu.edu Amey Deshmukh]<br>
[mailto:dkalro@ncsu.edu Deepak Kalro]<br>
[mailto:pmusyok@ncsu.edu Philip Musyoki]
----

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-11-12T22:22:42Z

Adeshmu: /* Changes to be Implemented */

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-11-06T01:47:24Z

Adeshmu:

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-11-06T01:47:08Z

Adeshmu:

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-11-06T01:39:41Z

Adeshmu:

==='''Introduction'''===
==Purpose==
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.

==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.<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>
4. A new field reviewer_is_team? should be added in the Response Map to determine whether the reviewer is an AssignmentParticipant or an AssignmentTeam.<br>
5. Finally, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

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

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-11-06T01:39:20Z

Adeshmu: /* Changes to be Implemented */

==='''Introduction'''===
==Purpose==
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.

----

==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.<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>
4. A new field reviewer_is_team? should be added in the Response Map to determine whether the reviewer is an AssignmentParticipant or an AssignmentTeam.<br>
5. Finally, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

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

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-11-06T01:38:53Z

Adeshmu: /* Details to changed */

==='''Introduction'''===
==Purpose==
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.

----

==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.<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>
4. A new field reviewer_is_team should be added in the Response Map to determine whether the reviewer is an AssignmentParticipant or an AssignmentTeam.<br>
5. Finally, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

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

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-11-06T01:32:42Z

Adeshmu:

==='''Introduction'''===
==Purpose==
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.

----

==Details to changed==
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>
3. Participants of the team should not be allowed to edit a review simultaneously.<br>
4. A new field reviewer_is_team should be added in the Response Map to determine whether the reviewer is an AssignmentParticipant or an AssignmentTeam.<br>
5. Finally, functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

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

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-11-06T01:31:51Z

Adeshmu: /* Details to changed= */

===Introduction===
=='''Purpose'''==
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.

----

=='''Issues to be fixed'''==
=='''Details to changed'''==
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>
3. Participants of the team should not be allowed to edit a review simultaneously.<br>
4. A new field reviewer_is_team should be added in the Response Map to determine whether the reviewer is a AssignmentParticipant or an AssignmentTeam.<br>
5. Finally functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

=='''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.

CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing

2017-11-06T01:31:35Z

Adeshmu:

===Introduction===
=='''Purpose'''==
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.

----

=='''Issues to be fixed'''==
=='''Details to changed'''===
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>
3. Participants of the team should not be allowed to edit a review simultaneously.<br>
4. A new field reviewer_is_team should be added in the Response Map to determine whether the reviewer is a AssignmentParticipant or an AssignmentTeam.<br>
5. Finally functionality should be provided to allow Team reviews by connecting everything as mentioned above.<br>

=='''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.

CSC/ECE 517 Fall 2017/E1752 Refactor assignments controller

2017-11-02T20:47:16Z

Adeshmu: /* Testing results */

==Introduction==
Expertiza is an open source webapp built on Ruby on Rails stack. It provides a platform to students with various features like peer-reviewing projects, submitting work, form teams, viewing grades etc. The project is being built and maintained by students and faculty at NCSU.

==About Assignments Controller==
The file assignments_controller.rb handles the logic behind Expertiza assignments and enables the creation and managements of assignments by instructional staff. Besides regular CRUD operations, it also integrates multiple parts of the expertiza components, such as users of different authorizations and priorities, corresponding courses associated with the assignment, due date and so on. Therefore, further unit and integration tests are required to guarantee that these operations work as expected. And also refactoring on the code in this controller is needed to make it more readable and reduce the complexity at the same time. Our tasks are based on the motivations above.

==About Software Testing==
Software testing is a process of examining a program or application with the intent of finding the software bugs. In software developemnt, it is usually defined as the process of validating and verifying that a software program or application or product meets the specified business and technical requirements.

Additionaly, software is tested to:
* Detect and rectify and errors made during the development phase,
* Ensure customer satisfaction in the application,
* Ensure the quality of the software product and
* Optimize the performance of the system.

Our project is guided by the Test-First Development principle. We write passing and failing tests for use cases of the assignment controller, and then turn to refactor the code. During the project, we implement the tests and refactor in Agile methodology with our mentor Zhewei through weekly delivery.

===RSpec Testing===
RSpec is a 'Domain Specific Language' (DSL) testing tool written in Ruby to test Ruby code. It is a behavior-driven development (BDD) framework which is extensively used in the production applications. The basic idea behind this concept is that of Test Driven Development(TDD) where the tests are written first and the development is based on writing just enough code that will fulfill those tests followed by refactoring.

The Expertiza project makes extensive use of RSpec to test the various components of the application. Tests of our tasks are in the code file: spec/controllers/assignments_controller_spec.rb

===Testing actions perfomed===
* Creating new tests for each method,
* Testing the each method and making sure the tests pass.

===Testing results===
All 22 tests were passed with zero failure on the final version of project code. Please refer to our detail project demo to see the testing in action.

==About Refactoring==
Refactoring of computer software or code is the process of restructuring existing software code without changing its external behavior or performance of the software application. Refactoring improves nonfunctional attributes of the software. Refactoring aids in code readability and keeps the code well maintained and easy to understand.

===Refactoring actions perfomed===
* Replace magic numbers in deadline_type_id by constants with reasonable names;
* Formatting the code for readability and convention;
* Split large chunks of code in to smaller manageable chunks;
* Extract simpler and specific methods out of blocks of codes to remove code duplications using DRY principle;
* Rename existing methods with meaningful names for better readability without change on external functionality.

===Refactor edit method===
Actions: code block split, method extraction and add meaningful constants

Original
<pre>
def edit
# give an error message is instructor have not set the time zone.
if current_user.timezonepref.nil?
flash.now[:error] = "You have not specified your preferred timezone yet. Please do this before you set up the deadlines."
end
@topics = SignUpTopic.where(assignment_id: params[:id])
@assignment_form = AssignmentForm.create_form_object(params[:id])
@user = current_user

@assignment_questionnaires = AssignmentQuestionnaire.where(assignment_id: params[:id])
@due_date_all = AssignmentDueDate.where(parent_id: params[:id])
@reviewvarycheck = false
@due_date_nameurl_notempty = false
@due_date_nameurl_notempty_checkbox = false
@metareview_allowed = false
@metareview_allowed_checkbox = false
@signup_allowed = false
@signup_allowed_checkbox = false
@drop_topic_allowed = false
@drop_topic_allowed_checkbox = false
@team_formation_allowed = false
@team_formation_allowed_checkbox = false
@participants_count = @assignment_form.assignment.participants.size
@teams_count = @assignment_form.assignment.teams.size

if @assignment_form.assignment.staggered_deadline == true
@review_rounds = @assignment_form.assignment.num_review_rounds
@assignment_submission_due_dates = @due_date_all.select {|due_date| due_date.deadline_type_id == 1 }
@assignment_review_due_dates = @due_date_all.select {|due_date| due_date.deadline_type_id == 2 }
end

# Check if name and url in database is empty before webpage displays
@due_date_all.each do |dd|
@due_date_nameurl_notempty = is_due_date_nameurl_notempty(dd)
@due_date_nameurl_notempty_checkbox = @due_date_nameurl_notempty
@metareview_allowed = is_meta_review_allowed?(dd)
@drop_topic_allowed = is_drop_topic_allowed?(dd)
@signup_allowed = is_signup_allowed?(dd)
@team_formation_allowed = is_team_formation_allowed?(dd)

if dd.due_at.present?
dd.due_at = dd.due_at.to_s.in_time_zone(current_user.timezonepref)
end
if @due_date_nameurl_notempty && @due_date_nameurl_notempty_checkbox &&
(@metareview_allowed || @drop_topic_allowed || @signup_allowed || @team_formation_allowed)
break
end
end

@assignment_questionnaires.each do |aq|
unless aq.used_in_round.nil?
@reviewvarycheck = 1
break
end
end
@due_date_all = update_nil_dd_deadline_name(@due_date_all)
@due_date_all = update_nil_dd_description_url(@due_date_all)

# only when instructor does not assign rubrics and in assignment edit page will show this error message.
if !empty_rubrics_list.empty? && request.original_fullpath == "/assignments/#{@assignment_form.assignment.id}/edit"
rubrics_needed = needed_rubrics(empty_rubrics_list)
flash.now[:error] = "You did not specify all the necessary rubrics. You need " + rubrics_needed +
" of assignment <b>#{@assignment_form.assignment.name}</b> before saving the assignment. You can assign rubrics <a id='go_to_tabs2' style='color: blue;'>here</a>."
end

if @assignment_form.assignment.directory_path.nil? || @assignment_form.assignment.directory_path.empty?
flash.now[:error] = "You did not specify your submission directory."
end
end
</pre>

After refactoring
<pre>
def edit
handle_current_user_timezonepref_nil

edit_params_setting

assignment_form_assignment_staggered_deadline?

@due_date_all.each do |dd|
check_due_date_nameurl_notempty(dd)

adjust_timezone_when_due_date_present(dd)

break if validate_due_date
end

check_assignment_questionnaires_usage

@due_date_all = update_nil_dd_deadline_name(@due_date_all)
@due_date_all = update_nil_dd_description_url(@due_date_all)

# only when instructor does not assign rubrics and in assignment edit page will show this error message.
handle_rubrics_not_assigned_case

handle_assignment_directory_path_nonexist_case
end
</pre>
Here we first grouped the blocks of code according to their similarity of functions. Then we extracted simpler methods from each code block to make it more readable and reduce the complexity and coupling. It is obvious that after refactoring, this part is simpler and easier to maintain. In addition, we also replaced the magic numbers by constants according to the deadline type.

===Refactor update method===
Actions: split long code block and extract specific methods

Original
<pre>
def update
unless params.key?(:assignment_form)
@assignment = Assignment.find(params[:id])
@assignment.course_id = params[:course_id]
if @assignment.save
flash[:note] = 'The assignment was successfully saved.'
redirect_to list_tree_display_index_path
else
flash[:error] = "Failed to save the assignment: #{@assignment.errors.full_messages.join(' ')}"
redirect_to edit_assignment_path @assignment.id
end
return
end

@assignment_form = AssignmentForm.create_form_object(params[:id])
@assignment_form.assignment.instructor ||= current_user
params[:assignment_form][:assignment_questionnaire].reject! do |q|
q[:questionnaire_id].empty?
end

if current_user.timezonepref.nil?
parent_id = current_user.parent_id
parent_timezone = User.find(parent_id).timezonepref
flash[:error] = "We strongly suggest that instructors specify their preferred timezone to guarantee the correct display time. For now we assume you are in " + parent_timezone
current_user.timezonepref = parent_timezone
end
if @assignment_form.update_attributes(assignment_form_params, current_user)
flash[:note] = 'The assignment was successfully saved....'
else
flash[:error] = "Failed to save the assignment: #{@assignment_form.errors.get(:message)}"
end
redirect_to edit_assignment_path @assignment_form.assignment.id
end
</pre>

After refactoring
<pre>
def update
unless params.key?(:assignment_form)
assignment_form_key_nonexist_case_handler
return
end

retrieve_assignment_form

handle_current_user_timezonepref_nil

feedback_assignment_form_attributes_update

redirect_to edit_assignment_path @assignment_form.assignment.id
end
</pre>
The update method was refactored in the similar way to reduce the size of codes and improve readability. The definitions of those helper methods were placed at the bottom of the assignments_controller.rb.

===Rename existing helper methods===
Actions: rename for consistent Ruby code style

<pre>
is_due_date_nameurl_notempty → due_date_nameurl_notempty?
is_meta_review_allowed? → meta_review_allowed?
is_drop_topic_allowed? → drop_topic_allowed?
is_signup_allowed? → signup_allowed?
is_team_formation_allowed? → team_formation_allowed?
</pre>

After each refactoring procedure, we perform the testing to ensure the expected functionality in Rspec. For more cases, please check our GitHub project repo. The files we make change on are: app/controllers/assignments_controller.rb and app/helpers/deadline_helper.rb

==Additional Links==
[https://github.com/jerry-shijieli/expertiza Github project repo]<br>
[https://www.youtube.com/playlist?list=PLUHiK0P0uQKLvW-_hBDdRK3x4cFn6BJ4C Project Video Demo]<br>
[https://github.com/expertiza/expertiza/pull/1024 Pull request]

==References==
[http://rspec.info/documentation/ Rspec Documentation]<br>
[http://www.betterspecs.org/ Better Specs]<br>
[http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation#Welcome_to_the_Expertiza_project.21 Expertiza Wiki]<br>
[https://expertiza.ncsu.edu/ Expertiza NCSU]

==Team==
[mailto:sli41@ncsu.edu Shijie Li]<br>
[mailto:adeshmu@ncsu.edu Amey Deshmukh]<br>
[mailto:pmusyok@ncsu.edu Philip Musyoki]

CSC/ECE 517 Fall 2017/E1752 Refactor assignments controller

2017-11-02T20:45:38Z

Adeshmu: /* Additional Links */

==Introduction==
Expertiza is an open source webapp built on Ruby on Rails stack. It provides a platform to students with various features like peer-reviewing projects, submitting work, form teams, viewing grades etc. The project is being built and maintained by students and faculty at NCSU.

==About Assignments Controller==
The file assignments_controller.rb handles the logic behind Expertiza assignments and enables the creation and managements of assignments by instructional staff. Besides regular CRUD operations, it also integrates multiple parts of the expertiza components, such as users of different authorizations and priorities, corresponding courses associated with the assignment, due date and so on. Therefore, further unit and integration tests are required to guarantee that these operations work as expected. And also refactoring on the code in this controller is needed to make it more readable and reduce the complexity at the same time. Our tasks are based on the motivations above.

==About Software Testing==
Software testing is a process of examining a program or application with the intent of finding the software bugs. In software developemnt, it is usually defined as the process of validating and verifying that a software program or application or product meets the specified business and technical requirements.

Additionaly, software is tested to:
* Detect and rectify and errors made during the development phase,
* Ensure customer satisfaction in the application,
* Ensure the quality of the software product and
* Optimize the performance of the system.

Our project is guided by the Test-First Development principle. We write passing and failing tests for use cases of the assignment controller, and then turn to refactor the code. During the project, we implement the tests and refactor in Agile methodology with our mentor Zhewei through weekly delivery.

===RSpec Testing===
RSpec is a 'Domain Specific Language' (DSL) testing tool written in Ruby to test Ruby code. It is a behavior-driven development (BDD) framework which is extensively used in the production applications. The basic idea behind this concept is that of Test Driven Development(TDD) where the tests are written first and the development is based on writing just enough code that will fulfill those tests followed by refactoring.

The Expertiza project makes extensive use of RSpec to test the various components of the application. Tests of our tasks are in the code file: spec/controllers/assignments_controller_spec.rb

===Testing actions perfomed===
* Creating new tests for each method,
* Testing the each method and making sure the tests pass.

===Testing results===
All 22 tests were passed with zero failure on the final version of project code.

==About Refactoring==
Refactoring of computer software or code is the process of restructuring existing software code without changing its external behavior or performance of the software application. Refactoring improves nonfunctional attributes of the software. Refactoring aids in code readability and keeps the code well maintained and easy to understand.

===Refactoring actions perfomed===
* Replace magic numbers in deadline_type_id by constants with reasonable names;
* Formatting the code for readability and convention;
* Split large chunks of code in to smaller manageable chunks;
* Extract simpler and specific methods out of blocks of codes to remove code duplications using DRY principle;
* Rename existing methods with meaningful names for better readability without change on external functionality.

===Refactor edit method===
Actions: code block split, method extraction and add meaningful constants

Original
<pre>
def edit
# give an error message is instructor have not set the time zone.
if current_user.timezonepref.nil?
flash.now[:error] = "You have not specified your preferred timezone yet. Please do this before you set up the deadlines."
end
@topics = SignUpTopic.where(assignment_id: params[:id])
@assignment_form = AssignmentForm.create_form_object(params[:id])
@user = current_user

@assignment_questionnaires = AssignmentQuestionnaire.where(assignment_id: params[:id])
@due_date_all = AssignmentDueDate.where(parent_id: params[:id])
@reviewvarycheck = false
@due_date_nameurl_notempty = false
@due_date_nameurl_notempty_checkbox = false
@metareview_allowed = false
@metareview_allowed_checkbox = false
@signup_allowed = false
@signup_allowed_checkbox = false
@drop_topic_allowed = false
@drop_topic_allowed_checkbox = false
@team_formation_allowed = false
@team_formation_allowed_checkbox = false
@participants_count = @assignment_form.assignment.participants.size
@teams_count = @assignment_form.assignment.teams.size

if @assignment_form.assignment.staggered_deadline == true
@review_rounds = @assignment_form.assignment.num_review_rounds
@assignment_submission_due_dates = @due_date_all.select {|due_date| due_date.deadline_type_id == 1 }
@assignment_review_due_dates = @due_date_all.select {|due_date| due_date.deadline_type_id == 2 }
end

# Check if name and url in database is empty before webpage displays
@due_date_all.each do |dd|
@due_date_nameurl_notempty = is_due_date_nameurl_notempty(dd)
@due_date_nameurl_notempty_checkbox = @due_date_nameurl_notempty
@metareview_allowed = is_meta_review_allowed?(dd)
@drop_topic_allowed = is_drop_topic_allowed?(dd)
@signup_allowed = is_signup_allowed?(dd)
@team_formation_allowed = is_team_formation_allowed?(dd)

if dd.due_at.present?
dd.due_at = dd.due_at.to_s.in_time_zone(current_user.timezonepref)
end
if @due_date_nameurl_notempty && @due_date_nameurl_notempty_checkbox &&
(@metareview_allowed || @drop_topic_allowed || @signup_allowed || @team_formation_allowed)
break
end
end

@assignment_questionnaires.each do |aq|
unless aq.used_in_round.nil?
@reviewvarycheck = 1
break
end
end
@due_date_all = update_nil_dd_deadline_name(@due_date_all)
@due_date_all = update_nil_dd_description_url(@due_date_all)

# only when instructor does not assign rubrics and in assignment edit page will show this error message.
if !empty_rubrics_list.empty? && request.original_fullpath == "/assignments/#{@assignment_form.assignment.id}/edit"
rubrics_needed = needed_rubrics(empty_rubrics_list)
flash.now[:error] = "You did not specify all the necessary rubrics. You need " + rubrics_needed +
" of assignment <b>#{@assignment_form.assignment.name}</b> before saving the assignment. You can assign rubrics <a id='go_to_tabs2' style='color: blue;'>here</a>."
end

if @assignment_form.assignment.directory_path.nil? || @assignment_form.assignment.directory_path.empty?
flash.now[:error] = "You did not specify your submission directory."
end
end
</pre>

After refactoring
<pre>
def edit
handle_current_user_timezonepref_nil

edit_params_setting

assignment_form_assignment_staggered_deadline?

@due_date_all.each do |dd|
check_due_date_nameurl_notempty(dd)

adjust_timezone_when_due_date_present(dd)

break if validate_due_date
end

check_assignment_questionnaires_usage

@due_date_all = update_nil_dd_deadline_name(@due_date_all)
@due_date_all = update_nil_dd_description_url(@due_date_all)

# only when instructor does not assign rubrics and in assignment edit page will show this error message.
handle_rubrics_not_assigned_case

handle_assignment_directory_path_nonexist_case
end
</pre>
Here we first grouped the blocks of code according to their similarity of functions. Then we extracted simpler methods from each code block to make it more readable and reduce the complexity and coupling. It is obvious that after refactoring, this part is simpler and easier to maintain. In addition, we also replaced the magic numbers by constants according to the deadline type.

===Refactor update method===
Actions: split long code block and extract specific methods

Original
<pre>
def update
unless params.key?(:assignment_form)
@assignment = Assignment.find(params[:id])
@assignment.course_id = params[:course_id]
if @assignment.save
flash[:note] = 'The assignment was successfully saved.'
redirect_to list_tree_display_index_path
else
flash[:error] = "Failed to save the assignment: #{@assignment.errors.full_messages.join(' ')}"
redirect_to edit_assignment_path @assignment.id
end
return
end

@assignment_form = AssignmentForm.create_form_object(params[:id])
@assignment_form.assignment.instructor ||= current_user
params[:assignment_form][:assignment_questionnaire].reject! do |q|
q[:questionnaire_id].empty?
end

if current_user.timezonepref.nil?
parent_id = current_user.parent_id
parent_timezone = User.find(parent_id).timezonepref
flash[:error] = "We strongly suggest that instructors specify their preferred timezone to guarantee the correct display time. For now we assume you are in " + parent_timezone
current_user.timezonepref = parent_timezone
end
if @assignment_form.update_attributes(assignment_form_params, current_user)
flash[:note] = 'The assignment was successfully saved....'
else
flash[:error] = "Failed to save the assignment: #{@assignment_form.errors.get(:message)}"
end
redirect_to edit_assignment_path @assignment_form.assignment.id
end
</pre>

After refactoring
<pre>
def update
unless params.key?(:assignment_form)
assignment_form_key_nonexist_case_handler
return
end

retrieve_assignment_form

handle_current_user_timezonepref_nil

feedback_assignment_form_attributes_update

redirect_to edit_assignment_path @assignment_form.assignment.id
end
</pre>
The update method was refactored in the similar way to reduce the size of codes and improve readability. The definitions of those helper methods were placed at the bottom of the assignments_controller.rb.

===Rename existing helper methods===
Actions: rename for consistent Ruby code style

<pre>
is_due_date_nameurl_notempty → due_date_nameurl_notempty?
is_meta_review_allowed? → meta_review_allowed?
is_drop_topic_allowed? → drop_topic_allowed?
is_signup_allowed? → signup_allowed?
is_team_formation_allowed? → team_formation_allowed?
</pre>

After each refactoring procedure, we perform the testing to ensure the expected functionality in Rspec. For more cases, please check our GitHub project repo. The files we make change on are: app/controllers/assignments_controller.rb and app/helpers/deadline_helper.rb

==Additional Links==
[https://github.com/jerry-shijieli/expertiza Github project repo]<br>
[https://www.youtube.com/playlist?list=PLUHiK0P0uQKLvW-_hBDdRK3x4cFn6BJ4C Project Video Demo]<br>
[https://github.com/expertiza/expertiza/pull/1024 Pull request]

==References==
[http://rspec.info/documentation/ Rspec Documentation]<br>
[http://www.betterspecs.org/ Better Specs]<br>
[http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation#Welcome_to_the_Expertiza_project.21 Expertiza Wiki]<br>
[https://expertiza.ncsu.edu/ Expertiza NCSU]

==Team==
[mailto:sli41@ncsu.edu Shijie Li]<br>
[mailto:adeshmu@ncsu.edu Amey Deshmukh]<br>
[mailto:pmusyok@ncsu.edu Philip Musyoki]

CSC/ECE 517 Fall 2017/E1752 Refactor assignments controller

2017-11-02T20:45:22Z

Adeshmu: /* Additional Links */

==Introduction==
Expertiza is an open source webapp built on Ruby on Rails stack. It provides a platform to students with various features like peer-reviewing projects, submitting work, form teams, viewing grades etc. The project is being built and maintained by students and faculty at NCSU.

==About Assignments Controller==
The file assignments_controller.rb handles the logic behind Expertiza assignments and enables the creation and managements of assignments by instructional staff. Besides regular CRUD operations, it also integrates multiple parts of the expertiza components, such as users of different authorizations and priorities, corresponding courses associated with the assignment, due date and so on. Therefore, further unit and integration tests are required to guarantee that these operations work as expected. And also refactoring on the code in this controller is needed to make it more readable and reduce the complexity at the same time. Our tasks are based on the motivations above.

==About Software Testing==
Software testing is a process of examining a program or application with the intent of finding the software bugs. In software developemnt, it is usually defined as the process of validating and verifying that a software program or application or product meets the specified business and technical requirements.

Additionaly, software is tested to:
* Detect and rectify and errors made during the development phase,
* Ensure customer satisfaction in the application,
* Ensure the quality of the software product and
* Optimize the performance of the system.

Our project is guided by the Test-First Development principle. We write passing and failing tests for use cases of the assignment controller, and then turn to refactor the code. During the project, we implement the tests and refactor in Agile methodology with our mentor Zhewei through weekly delivery.

===RSpec Testing===
RSpec is a 'Domain Specific Language' (DSL) testing tool written in Ruby to test Ruby code. It is a behavior-driven development (BDD) framework which is extensively used in the production applications. The basic idea behind this concept is that of Test Driven Development(TDD) where the tests are written first and the development is based on writing just enough code that will fulfill those tests followed by refactoring.

The Expertiza project makes extensive use of RSpec to test the various components of the application. Tests of our tasks are in the code file: spec/controllers/assignments_controller_spec.rb

===Testing actions perfomed===
* Creating new tests for each method,
* Testing the each method and making sure the tests pass.

===Testing results===
All 22 tests were passed with zero failure on the final version of project code.

==About Refactoring==
Refactoring of computer software or code is the process of restructuring existing software code without changing its external behavior or performance of the software application. Refactoring improves nonfunctional attributes of the software. Refactoring aids in code readability and keeps the code well maintained and easy to understand.

===Refactoring actions perfomed===
* Replace magic numbers in deadline_type_id by constants with reasonable names;
* Formatting the code for readability and convention;
* Split large chunks of code in to smaller manageable chunks;
* Extract simpler and specific methods out of blocks of codes to remove code duplications using DRY principle;
* Rename existing methods with meaningful names for better readability without change on external functionality.

===Refactor edit method===
Actions: code block split, method extraction and add meaningful constants

Original
<pre>
def edit
# give an error message is instructor have not set the time zone.
if current_user.timezonepref.nil?
flash.now[:error] = "You have not specified your preferred timezone yet. Please do this before you set up the deadlines."
end
@topics = SignUpTopic.where(assignment_id: params[:id])
@assignment_form = AssignmentForm.create_form_object(params[:id])
@user = current_user

@assignment_questionnaires = AssignmentQuestionnaire.where(assignment_id: params[:id])
@due_date_all = AssignmentDueDate.where(parent_id: params[:id])
@reviewvarycheck = false
@due_date_nameurl_notempty = false
@due_date_nameurl_notempty_checkbox = false
@metareview_allowed = false
@metareview_allowed_checkbox = false
@signup_allowed = false
@signup_allowed_checkbox = false
@drop_topic_allowed = false
@drop_topic_allowed_checkbox = false
@team_formation_allowed = false
@team_formation_allowed_checkbox = false
@participants_count = @assignment_form.assignment.participants.size
@teams_count = @assignment_form.assignment.teams.size

if @assignment_form.assignment.staggered_deadline == true
@review_rounds = @assignment_form.assignment.num_review_rounds
@assignment_submission_due_dates = @due_date_all.select {|due_date| due_date.deadline_type_id == 1 }
@assignment_review_due_dates = @due_date_all.select {|due_date| due_date.deadline_type_id == 2 }
end

# Check if name and url in database is empty before webpage displays
@due_date_all.each do |dd|
@due_date_nameurl_notempty = is_due_date_nameurl_notempty(dd)
@due_date_nameurl_notempty_checkbox = @due_date_nameurl_notempty
@metareview_allowed = is_meta_review_allowed?(dd)
@drop_topic_allowed = is_drop_topic_allowed?(dd)
@signup_allowed = is_signup_allowed?(dd)
@team_formation_allowed = is_team_formation_allowed?(dd)

if dd.due_at.present?
dd.due_at = dd.due_at.to_s.in_time_zone(current_user.timezonepref)
end
if @due_date_nameurl_notempty && @due_date_nameurl_notempty_checkbox &&
(@metareview_allowed || @drop_topic_allowed || @signup_allowed || @team_formation_allowed)
break
end
end

@assignment_questionnaires.each do |aq|
unless aq.used_in_round.nil?
@reviewvarycheck = 1
break
end
end
@due_date_all = update_nil_dd_deadline_name(@due_date_all)
@due_date_all = update_nil_dd_description_url(@due_date_all)

# only when instructor does not assign rubrics and in assignment edit page will show this error message.
if !empty_rubrics_list.empty? && request.original_fullpath == "/assignments/#{@assignment_form.assignment.id}/edit"
rubrics_needed = needed_rubrics(empty_rubrics_list)
flash.now[:error] = "You did not specify all the necessary rubrics. You need " + rubrics_needed +
" of assignment <b>#{@assignment_form.assignment.name}</b> before saving the assignment. You can assign rubrics <a id='go_to_tabs2' style='color: blue;'>here</a>."
end

if @assignment_form.assignment.directory_path.nil? || @assignment_form.assignment.directory_path.empty?
flash.now[:error] = "You did not specify your submission directory."
end
end
</pre>

After refactoring
<pre>
def edit
handle_current_user_timezonepref_nil

edit_params_setting

assignment_form_assignment_staggered_deadline?

@due_date_all.each do |dd|
check_due_date_nameurl_notempty(dd)

adjust_timezone_when_due_date_present(dd)

break if validate_due_date
end

check_assignment_questionnaires_usage

@due_date_all = update_nil_dd_deadline_name(@due_date_all)
@due_date_all = update_nil_dd_description_url(@due_date_all)

# only when instructor does not assign rubrics and in assignment edit page will show this error message.
handle_rubrics_not_assigned_case

handle_assignment_directory_path_nonexist_case
end
</pre>
Here we first grouped the blocks of code according to their similarity of functions. Then we extracted simpler methods from each code block to make it more readable and reduce the complexity and coupling. It is obvious that after refactoring, this part is simpler and easier to maintain. In addition, we also replaced the magic numbers by constants according to the deadline type.

===Refactor update method===
Actions: split long code block and extract specific methods

Original
<pre>
def update
unless params.key?(:assignment_form)
@assignment = Assignment.find(params[:id])
@assignment.course_id = params[:course_id]
if @assignment.save
flash[:note] = 'The assignment was successfully saved.'
redirect_to list_tree_display_index_path
else
flash[:error] = "Failed to save the assignment: #{@assignment.errors.full_messages.join(' ')}"
redirect_to edit_assignment_path @assignment.id
end
return
end

@assignment_form = AssignmentForm.create_form_object(params[:id])
@assignment_form.assignment.instructor ||= current_user
params[:assignment_form][:assignment_questionnaire].reject! do |q|
q[:questionnaire_id].empty?
end

if current_user.timezonepref.nil?
parent_id = current_user.parent_id
parent_timezone = User.find(parent_id).timezonepref
flash[:error] = "We strongly suggest that instructors specify their preferred timezone to guarantee the correct display time. For now we assume you are in " + parent_timezone
current_user.timezonepref = parent_timezone
end
if @assignment_form.update_attributes(assignment_form_params, current_user)
flash[:note] = 'The assignment was successfully saved....'
else
flash[:error] = "Failed to save the assignment: #{@assignment_form.errors.get(:message)}"
end
redirect_to edit_assignment_path @assignment_form.assignment.id
end
</pre>

After refactoring
<pre>
def update
unless params.key?(:assignment_form)
assignment_form_key_nonexist_case_handler
return
end

retrieve_assignment_form

handle_current_user_timezonepref_nil

feedback_assignment_form_attributes_update

redirect_to edit_assignment_path @assignment_form.assignment.id
end
</pre>
The update method was refactored in the similar way to reduce the size of codes and improve readability. The definitions of those helper methods were placed at the bottom of the assignments_controller.rb.

===Rename existing helper methods===
Actions: rename for consistent Ruby code style

<pre>
is_due_date_nameurl_notempty → due_date_nameurl_notempty?
is_meta_review_allowed? → meta_review_allowed?
is_drop_topic_allowed? → drop_topic_allowed?
is_signup_allowed? → signup_allowed?
is_team_formation_allowed? → team_formation_allowed?
</pre>

After each refactoring procedure, we perform the testing to ensure the expected functionality in Rspec. For more cases, please check our GitHub project repo. The files we make change on are: app/controllers/assignments_controller.rb and app/helpers/deadline_helper.rb

==Additional Links==
[https://github.com/jerry-shijieli/expertiza Github project repo]<br>
[https://www.youtube.com/playlist?list=PLUHiK0P0uQKLvW-_hBDdRK3x4cFn6BJ4C Project Video Demo]
[https://github.com/expertiza/expertiza/pull/1024 Pull request]

==References==
[http://rspec.info/documentation/ Rspec Documentation]<br>
[http://www.betterspecs.org/ Better Specs]<br>
[http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation#Welcome_to_the_Expertiza_project.21 Expertiza Wiki]<br>
[https://expertiza.ncsu.edu/ Expertiza NCSU]

==Team==
[mailto:sli41@ncsu.edu Shijie Li]<br>
[mailto:adeshmu@ncsu.edu Amey Deshmukh]<br>
[mailto:pmusyok@ncsu.edu Philip Musyoki]