<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Xli56</id>
	<title>Expertiza_Wiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Xli56"/>
	<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Special:Contributions/Xli56"/>
	<updated>2026-06-29T13:41:52Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.41.0</generator>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137171</id>
		<title>CSC/ECE 517 Fall 2020 - E2087. Conflict notification. Improve Search Facility In Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137171"/>
		<updated>2020-11-17T04:05:16Z</updated>

		<summary type="html">&lt;p&gt;Xli56: /* New Implementation */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Expertiza includes the functionality of notifying instructors when a conflict occurs in review scores for a submission. Currently, when two reviews for the same submission differ significantly, an email is sent to the instructor of the course, but there is no link to the review that caused the conflict. This improvement will allow the professor to have links to the reviews that caused the conflict and will be formatted better to help the instructor understand the conflict.&lt;br /&gt;
&lt;br /&gt;
=== Issues with previous submission ===&lt;br /&gt;
&lt;br /&gt;
# The functionality is good but the UI of conflict report needs work. &lt;br /&gt;
# The UI needs to be cleaned up a little. When charts have only one or two bars, the chart can be compressed. The reviewer whose scores deviate from the threshold can be displayed in a different colored bar.&lt;br /&gt;
# Tests need to be refactored.&lt;br /&gt;
# They included their debug code in their pull request. &lt;br /&gt;
# They have included a lot of logic in the views. &lt;br /&gt;
# Shallow tests: one or more of their test expectations only focus on the return value not being `nil`, `empty` or not equal to `0` without testing the `real` value.&lt;br /&gt;
&lt;br /&gt;
== Proposed Solution ==&lt;br /&gt;
&lt;br /&gt;
The previous team implemented new logic to determine if a review is in conflict with another and created a new page to link the instructors to in the email. Because their functionality was good, we will mainly be focused on improving the UI of the conflict reports. Furthermore, there is a lot of logic that lives in the views that can be refactored and moved to controllers. Additionally, there is debug code that can be removed and tests that can be fleshed out.&lt;br /&gt;
&lt;br /&gt;
=== UI Imporvements ===&lt;br /&gt;
&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb&lt;br /&gt;
&lt;br /&gt;
The UI can be improved for the conflict metric to give more information on the conflicted reviews.&lt;br /&gt;
&lt;br /&gt;
=== Logic in Views ===&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb &lt;br /&gt;
&lt;br /&gt;
The logic to determine if answers are within or outside of the tolerance limits can be moved to functions outside of the .erb file.&lt;br /&gt;
&lt;br /&gt;
== UML Activity Diagram ==&lt;br /&gt;
[[File:517 Final Project Student UML.jpg]]&lt;br /&gt;
[[File:517 Final Project Instructor UML.jpg]]&lt;br /&gt;
&lt;br /&gt;
== UI Changes ==&lt;br /&gt;
&lt;br /&gt;
Based on the previous changes from last group, the notification email triggered will send to the instructor whenever two reviews for the same submission differ &amp;quot;significantly&amp;quot; on their scoring (the threshold is specified in the &amp;quot;Notification limit&amp;quot; on the Rubric tab of assignment creation).&lt;br /&gt;
&lt;br /&gt;
[[File:afteremail.JPG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the email notification, the formatting can be improved to make it more readable and clear as to which links relate to what actions and what caused the conflict to trigger.&lt;br /&gt;
&lt;br /&gt;
The previous group of snapshot for the view which the instructor receives&lt;br /&gt;
&lt;br /&gt;
[[File:afterfix.PNG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the 'review for mail check' page, more information can be added to indicate if a review has a conflict. We will add indicators beside each review that have conflicts.&lt;br /&gt;
&lt;br /&gt;
[[File:E2087 Score Report.png|1000px]]&lt;br /&gt;
[[File:E2087 Conflict Notification.png|1000px]]&lt;br /&gt;
&lt;br /&gt;
== Test Plan==&lt;br /&gt;
&lt;br /&gt;
=== Manual Test Plan ===&lt;br /&gt;
&lt;br /&gt;
To verify the conflict notification is working correctly, a mock assignment will be created and two reviews will be entered that should trigger a conflict. Successful retrieval of the email and verification of the links included in the email will provide sufficient verification that the changes were successful.&lt;br /&gt;
&lt;br /&gt;
=== File Changes ===&lt;br /&gt;
File: spec/models/answer_spec.rb&lt;br /&gt;
&lt;br /&gt;
Currently, tests only check if the values are not empty. More tests can be written to make sure the actual value is being returned correctly.&lt;br /&gt;
&lt;br /&gt;
File: spec/controllers/reports_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
More tests can be written to ensure correct names and values are written.&lt;br /&gt;
&lt;br /&gt;
== Implemented Solution ==&lt;br /&gt;
&lt;br /&gt;
=== Refactoring ===&lt;br /&gt;
&lt;br /&gt;
Moved following methods from review_mapping_helper.rb to report_formatter_helper.rb&lt;br /&gt;
&lt;br /&gt;
* average_of_round&lt;br /&gt;
* std_of_round&lt;br /&gt;
* review_score_helper_for_team&lt;br /&gt;
* review_score_for_team&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== New Implementation   ===&lt;br /&gt;
Adding base_url from the controller as this method is not accessible from model&lt;br /&gt;
&amp;lt;pre&amp;gt; @response.notify_instructor_on_difference(request.base_url) if (@map.is_a? ReviewResponseMap) &lt;br /&gt;
                       &amp;amp;&amp;amp; @response.is_submitted &amp;amp;&amp;amp; @response.significant_difference?&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;     if (@map.is_a? ReviewResponseMap) &amp;amp;&amp;amp; (was_submitted == false &amp;amp;&amp;amp; @response.is_submitted) &amp;amp;&amp;amp; @response.significant_difference?&lt;br /&gt;
       @response.notify_instructor_on_difference&lt;br /&gt;
       @response.notify_instructor_on_difference(request.base_url)&lt;br /&gt;
       @response.email&lt;br /&gt;
     end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
This method generates statistics (average, standard deviation, tolerance limits) for each round. This method was created to move logic that was previously contained in a view to a helper class.&lt;br /&gt;
&amp;lt;pre&amp;gt;def review_statistics(id, team_name)&lt;br /&gt;
     res = []&lt;br /&gt;
     question_answers = review_score_for_team(id, team_name)&lt;br /&gt;
     question_answers.each do |question_answer|&lt;br /&gt;
       round = {}&lt;br /&gt;
       round[:question_answer] = question_answer&lt;br /&gt;
       round[:average] = average_of_round(question_answer)&lt;br /&gt;
       round[:std] = std_of_round(round[:average], question_answer)&lt;br /&gt;
       round[:upper_tolerance_limit] = (round[:average]+(2*round[:std])).round(2)&lt;br /&gt;
       round[:lower_tolerance_limit] = (round[:average]-(2*round[:std])).round(2)&lt;br /&gt;
       res.push(round)&lt;br /&gt;
     end&lt;br /&gt;
     res&lt;br /&gt;
   end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
This logic highlights all reviews' score in red which is out of limit range.&lt;br /&gt;
&amp;lt;pre&amp;gt;      if answer &amp;gt; upper_tolerance_limit or answer &amp;lt; lower_tolerance_limit&lt;br /&gt;
         colors &amp;lt;&amp;lt; &amp;quot;rgba(255,99,132,0.8)&amp;quot; # red&lt;br /&gt;
        end&lt;br /&gt;
       else&lt;br /&gt;
         colors &amp;lt;&amp;lt; &amp;quot;rgba(77, 175, 124, 1)&amp;quot; # green       &lt;br /&gt;
     end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Passing the colors to bar background.&lt;br /&gt;
&amp;lt;pre&amp;gt;backgroundColor: colors&amp;lt;/pre&amp;gt;&lt;br /&gt;
comprising the chart height for how much it need to clearly display all data.&lt;br /&gt;
&amp;lt;pre&amp;gt; height: 4*question_answer.size() + 14 &amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== UI Improvements ===&lt;br /&gt;
&lt;br /&gt;
[[File:Chart before.png|1000px]]&lt;br /&gt;
&lt;br /&gt;
UI before improvements.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
[[File:Chart after.png|1000px]]&lt;br /&gt;
&lt;br /&gt;
UI after improvements.&lt;br /&gt;
&lt;br /&gt;
== Relevant Links ==&lt;br /&gt;
GitHub - https://github.com/salmonandrew/expertiza &amp;lt;br&amp;gt;&lt;br /&gt;
Pull Request - https://github.com/expertiza/expertiza/pull/1840 &amp;lt;br&amp;gt;&lt;br /&gt;
Demo Video - https://youtu.be/D_e80coRkLk&lt;br /&gt;
&lt;br /&gt;
== Team ==&lt;br /&gt;
'''Mentor: '''Sanket Pai (sgpai2@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
*Yen-An Jou (yjou@ncsu.edu)&lt;br /&gt;
*Xiwen Chen (xchen33@ncsu.edu)&lt;br /&gt;
*Andrew Hirasawa (achirasa@ncsu.edu)&lt;br /&gt;
*Derrick Li (xli56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== References / Previous Implementation ==&lt;br /&gt;
&lt;br /&gt;
*Previous Wikipedia page - [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1865._Conflict_Notification E1865 Conflict Notification Fall 2018]&lt;br /&gt;
&lt;br /&gt;
*Previous Final Video - [https://drive.google.com/drive/folders/1Z8rqRxdmXJYbOZzoptmBLP0kM7Bdul2Q Final Video]&lt;br /&gt;
&lt;br /&gt;
*Previous Pull Request -[https://github.com/expertiza/expertiza/pull/1445 Pull Request 1445]&lt;br /&gt;
&lt;br /&gt;
*Previous Github Repo - [https://github.com/cshinde57/expertiza Github Repo]&lt;br /&gt;
{{reflist}}&lt;/div&gt;</summary>
		<author><name>Xli56</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137160</id>
		<title>CSC/ECE 517 Fall 2020 - E2087. Conflict notification. Improve Search Facility In Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137160"/>
		<updated>2020-11-17T03:29:19Z</updated>

		<summary type="html">&lt;p&gt;Xli56: /* New Implementation */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Expertiza includes the functionality of notifying instructors when a conflict occurs in review scores for a submission. Currently, when two reviews for the same submission differ significantly, an email is sent to the instructor of the course, but there is no link to the review that caused the conflict. This improvement will allow the professor to have links to the reviews that caused the conflict and will be formatted better to help the instructor understand the conflict.&lt;br /&gt;
&lt;br /&gt;
=== Issues with previous submission ===&lt;br /&gt;
&lt;br /&gt;
# The functionality is good but the UI of conflict report needs work. &lt;br /&gt;
# The UI needs to be cleaned up a little. When charts have only one or two bars, the chart can be compressed. The reviewer whose scores deviate from the threshold can be displayed in a different colored bar.&lt;br /&gt;
# Tests need to be refactored.&lt;br /&gt;
# They included their debug code in their pull request. &lt;br /&gt;
# They have included a lot of logic in the views. &lt;br /&gt;
# Shallow tests: one or more of their test expectations only focus on the return value not being `nil`, `empty` or not equal to `0` without testing the `real` value.&lt;br /&gt;
&lt;br /&gt;
== Proposed Solution ==&lt;br /&gt;
&lt;br /&gt;
The previous team implemented new logic to determine if a review is in conflict with another and created a new page to link the instructors to in the email. Because their functionality was good, we will mainly be focused on improving the UI of the conflict reports. Furthermore, there is a lot of logic that lives in the views that can be refactored and moved to controllers. Additionally, there is debug code that can be removed and tests that can be fleshed out.&lt;br /&gt;
&lt;br /&gt;
=== UI Imporvements ===&lt;br /&gt;
&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb&lt;br /&gt;
&lt;br /&gt;
The UI can be improved for the conflict metric to give more information on the conflicted reviews.&lt;br /&gt;
&lt;br /&gt;
=== Logic in Views ===&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb &lt;br /&gt;
&lt;br /&gt;
The logic to determine if answers are within or outside of the tolerance limits can be moved to functions outside of the .erb file.&lt;br /&gt;
&lt;br /&gt;
== UML Activity Diagram ==&lt;br /&gt;
[[File:517 Final Project Student UML.jpg]]&lt;br /&gt;
[[File:517 Final Project Instructor UML.jpg]]&lt;br /&gt;
&lt;br /&gt;
== UI Changes ==&lt;br /&gt;
&lt;br /&gt;
Based on the previous changes from last group, the notification email triggered will send to the instructor whenever two reviews for the same submission differ &amp;quot;significantly&amp;quot; on their scoring (the threshold is specified in the &amp;quot;Notification limit&amp;quot; on the Rubric tab of assignment creation).&lt;br /&gt;
&lt;br /&gt;
[[File:afteremail.JPG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the email notification, the formatting can be improved to make it more readable and clear as to which links relate to what actions and what caused the conflict to trigger.&lt;br /&gt;
&lt;br /&gt;
The previous group of snapshot for the view which the instructor receives&lt;br /&gt;
&lt;br /&gt;
[[File:afterfix.PNG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the 'review for mail check' page, more information can be added to indicate if a review has a conflict. We will add indicators beside each review that have conflicts.&lt;br /&gt;
&lt;br /&gt;
== Test Plan==&lt;br /&gt;
&lt;br /&gt;
=== Manual Test Plan ===&lt;br /&gt;
&lt;br /&gt;
To verify the conflict notification is working correctly, a mock assignment will be created and two reviews will be entered that should trigger a conflict. Successful retrieval of the email and verification of the links included in the email will provide sufficient verification that the changes were successful.&lt;br /&gt;
&lt;br /&gt;
=== File Changes ===&lt;br /&gt;
File: spec/models/answer_spec.rb&lt;br /&gt;
&lt;br /&gt;
Currently, tests only check if the values are not empty. More tests can be written to make sure the actual value is being returned correctly.&lt;br /&gt;
&lt;br /&gt;
File: spec/controllers/reports_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
More tests can be written to ensure correct names and values are written.&lt;br /&gt;
&lt;br /&gt;
== Implemented Solution ==&lt;br /&gt;
&lt;br /&gt;
=== Refactoring ===&lt;br /&gt;
&lt;br /&gt;
Moved following methods from review_mapping_helper.rb to report_formatter_helper.rb&lt;br /&gt;
&lt;br /&gt;
* average_of_round&lt;br /&gt;
* std_of_round&lt;br /&gt;
* review_score_helper_for_team&lt;br /&gt;
* review_score_for_team&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== New Implementation   ===&lt;br /&gt;
Adding base_url from the controller as this method is not accessible from model&lt;br /&gt;
&amp;lt;pre&amp;gt; @response.notify_instructor_on_difference(request.base_url) if (@map.is_a? ReviewResponseMap) &lt;br /&gt;
                       &amp;amp;&amp;amp; @response.is_submitted &amp;amp;&amp;amp; @response.significant_difference?&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt; @response.notify_instructor_on_difference(request.base_url)&amp;lt;/pre&amp;gt;&lt;br /&gt;
This method generates statistics (average, standard deviation, tolerance limits) for each round. This method was created to move logic that was previously contained in a view to a helper class.&lt;br /&gt;
&amp;lt;pre&amp;gt;def review_statistics(id, team_name)&lt;br /&gt;
     res = []&lt;br /&gt;
     question_answers = review_score_for_team(id, team_name)&lt;br /&gt;
     question_answers.each do |question_answer|&lt;br /&gt;
       round = {}&lt;br /&gt;
       round[:question_answer] = question_answer&lt;br /&gt;
       round[:average] = average_of_round(question_answer)&lt;br /&gt;
       round[:std] = std_of_round(round[:average], question_answer)&lt;br /&gt;
       round[:upper_tolerance_limit] = (round[:average]+(2*round[:std])).round(2)&lt;br /&gt;
       round[:lower_tolerance_limit] = (round[:average]-(2*round[:std])).round(2)&lt;br /&gt;
       res.push(round)&lt;br /&gt;
     end&lt;br /&gt;
     res&lt;br /&gt;
   end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
This logic highlights all reviews' score in red which is out of limit range.&lt;br /&gt;
&amp;lt;pre&amp;gt;      if answer &amp;gt; upper_tolerance_limit or answer &amp;lt; lower_tolerance_limit&lt;br /&gt;
         colors &amp;lt;&amp;lt; &amp;quot;rgba(255,99,132,0.8)&amp;quot; # red&lt;br /&gt;
        end&lt;br /&gt;
       else&lt;br /&gt;
         colors &amp;lt;&amp;lt; &amp;quot;rgba(77, 175, 124, 1)&amp;quot; # green       &lt;br /&gt;
     end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Passing the colors to bar background.&lt;br /&gt;
&amp;lt;pre&amp;gt;backgroundColor: colors&amp;lt;/pre&amp;gt;&lt;br /&gt;
comprising the chart height for how much it need to clearly display all data.&lt;br /&gt;
&amp;lt;pre&amp;gt; height: 4*question_answer.size() + 14 &amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Relevant Links ==&lt;br /&gt;
GitHub - https://github.com/salmonandrew/expertiza &amp;lt;br&amp;gt;&lt;br /&gt;
Pull Request - https://github.com/expertiza/expertiza/pull/1840 &amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Team ==&lt;br /&gt;
'''Mentor: '''Sanket Pai (sgpai2@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
*Yen-An Jou (yjou@ncsu.edu)&lt;br /&gt;
*Xiwen Chen (xchen33@ncsu.edu)&lt;br /&gt;
*Andrew Hirasawa (achirasa@ncsu.edu)&lt;br /&gt;
*Derrick Li (xli56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== References / Previous Implementation ==&lt;br /&gt;
&lt;br /&gt;
*Previous Wikipedia page - [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1865._Conflict_Notification E1865 Conflict Notification Fall 2018]&lt;br /&gt;
&lt;br /&gt;
*Previous Final Video - [https://drive.google.com/drive/folders/1Z8rqRxdmXJYbOZzoptmBLP0kM7Bdul2Q Final Video]&lt;br /&gt;
&lt;br /&gt;
*Previous Pull Request -[https://github.com/expertiza/expertiza/pull/1445 Pull Request 1445]&lt;br /&gt;
&lt;br /&gt;
*Previous Github Repo - [https://github.com/cshinde57/expertiza Github Repo]&lt;br /&gt;
{{reflist}}&lt;/div&gt;</summary>
		<author><name>Xli56</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137158</id>
		<title>CSC/ECE 517 Fall 2020 - E2087. Conflict notification. Improve Search Facility In Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137158"/>
		<updated>2020-11-17T03:10:27Z</updated>

		<summary type="html">&lt;p&gt;Xli56: /* New Implementation */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Expertiza includes the functionality of notifying instructors when a conflict occurs in review scores for a submission. Currently, when two reviews for the same submission differ significantly, an email is sent to the instructor of the course, but there is no link to the review that caused the conflict. This improvement will allow the professor to have links to the reviews that caused the conflict and will be formatted better to help the instructor understand the conflict.&lt;br /&gt;
&lt;br /&gt;
=== Issues with previous submission ===&lt;br /&gt;
&lt;br /&gt;
# The functionality is good but the UI of conflict report needs work. &lt;br /&gt;
# The UI needs to be cleaned up a little. When charts have only one or two bars, the chart can be compressed. The reviewer whose scores deviate from the threshold can be displayed in a different colored bar.&lt;br /&gt;
# Tests need to be refactored.&lt;br /&gt;
# They included their debug code in their pull request. &lt;br /&gt;
# They have included a lot of logic in the views. &lt;br /&gt;
# Shallow tests: one or more of their test expectations only focus on the return value not being `nil`, `empty` or not equal to `0` without testing the `real` value.&lt;br /&gt;
&lt;br /&gt;
== Proposed Solution ==&lt;br /&gt;
&lt;br /&gt;
The previous team implemented new logic to determine if a review is in conflict with another and created a new page to link the instructors to in the email. Because their functionality was good, we will mainly be focused on improving the UI of the conflict reports. Furthermore, there is a lot of logic that lives in the views that can be refactored and moved to controllers. Additionally, there is debug code that can be removed and tests that can be fleshed out.&lt;br /&gt;
&lt;br /&gt;
=== UI Imporvements ===&lt;br /&gt;
&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb&lt;br /&gt;
&lt;br /&gt;
The UI can be improved for the conflict metric to give more information on the conflicted reviews.&lt;br /&gt;
&lt;br /&gt;
=== Logic in Views ===&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb &lt;br /&gt;
&lt;br /&gt;
The logic to determine if answers are within or outside of the tolerance limits can be moved to functions outside of the .erb file.&lt;br /&gt;
&lt;br /&gt;
== UML Activity Diagram ==&lt;br /&gt;
[[File:517 Final Project Student UML.jpg]]&lt;br /&gt;
[[File:517 Final Project Instructor UML.jpg]]&lt;br /&gt;
&lt;br /&gt;
== UI Changes ==&lt;br /&gt;
&lt;br /&gt;
Based on the previous changes from last group, the notification email triggered will send to the instructor whenever two reviews for the same submission differ &amp;quot;significantly&amp;quot; on their scoring (the threshold is specified in the &amp;quot;Notification limit&amp;quot; on the Rubric tab of assignment creation).&lt;br /&gt;
&lt;br /&gt;
[[File:afteremail.JPG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the email notification, the formatting can be improved to make it more readable and clear as to which links relate to what actions and what caused the conflict to trigger.&lt;br /&gt;
&lt;br /&gt;
The previous group of snapshot for the view which the instructor receives&lt;br /&gt;
&lt;br /&gt;
[[File:afterfix.PNG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the 'review for mail check' page, more information can be added to indicate if a review has a conflict. We will add indicators beside each review that have conflicts.&lt;br /&gt;
&lt;br /&gt;
== Test Plan==&lt;br /&gt;
&lt;br /&gt;
=== Manual Test Plan ===&lt;br /&gt;
&lt;br /&gt;
To verify the conflict notification is working correctly, a mock assignment will be created and two reviews will be entered that should trigger a conflict. Successful retrieval of the email and verification of the links included in the email will provide sufficient verification that the changes were successful.&lt;br /&gt;
&lt;br /&gt;
=== File Changes ===&lt;br /&gt;
File: spec/models/answer_spec.rb&lt;br /&gt;
&lt;br /&gt;
Currently, tests only check if the values are not empty. More tests can be written to make sure the actual value is being returned correctly.&lt;br /&gt;
&lt;br /&gt;
File: spec/controllers/reports_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
More tests can be written to ensure correct names and values are written.&lt;br /&gt;
&lt;br /&gt;
== Implemented Solution ==&lt;br /&gt;
&lt;br /&gt;
=== Refactoring ===&lt;br /&gt;
&lt;br /&gt;
Moved following methods from review_mapping_helper.rb to report_formatter_helper.rb&lt;br /&gt;
&lt;br /&gt;
* average_of_round&lt;br /&gt;
* std_of_round&lt;br /&gt;
* review_score_helper_for_team&lt;br /&gt;
* review_score_for_team&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== New Implementation   ===&lt;br /&gt;
Adding base_url from the controller as this method is not accessible from model&lt;br /&gt;
&amp;lt;pre&amp;gt; @response.notify_instructor_on_difference(request.base_url) if (@map.is_a? ReviewResponseMap) &lt;br /&gt;
                       &amp;amp;&amp;amp; @response.is_submitted &amp;amp;&amp;amp; @response.significant_difference?&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt; @response.notify_instructor_on_difference(request.base_url)&amp;lt;/pre&amp;gt;&lt;br /&gt;
This method generates statistics for each round&lt;br /&gt;
&amp;lt;pre&amp;gt;def review_statistics(id, team_name)&lt;br /&gt;
     res = []&lt;br /&gt;
     question_answers = review_score_for_team(id, team_name)&lt;br /&gt;
     question_answers.each do |question_answer|&lt;br /&gt;
       round = {}&lt;br /&gt;
       round[:question_answer] = question_answer&lt;br /&gt;
       round[:average] = average_of_round(question_answer)&lt;br /&gt;
       round[:std] = std_of_round(round[:average], question_answer)&lt;br /&gt;
       round[:upper_tolerance_limit] = (round[:average]+(2*round[:std])).round(2)&lt;br /&gt;
       round[:lower_tolerance_limit] = (round[:average]-(2*round[:std])).round(2)&lt;br /&gt;
       res.push(round)&lt;br /&gt;
     end&lt;br /&gt;
     res&lt;br /&gt;
   end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
This logic highlights all reviews' score which is out of acceptable range.&lt;br /&gt;
&amp;lt;pre&amp;gt;      if answer &amp;gt; upper_tolerance_limit or answer &amp;lt; lower_tolerance_limit&lt;br /&gt;
         colors &amp;lt;&amp;lt; &amp;quot;rgba(255,99,132,0.8)&amp;quot; # red&lt;br /&gt;
        end&lt;br /&gt;
       else&lt;br /&gt;
         colors &amp;lt;&amp;lt; &amp;quot;rgba(77, 175, 124, 1)&amp;quot; # green       &lt;br /&gt;
     end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;backgroundColor: colors&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt; height: 4*question_answer.size() + 14 &amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Relevant Links ==&lt;br /&gt;
GitHub - https://github.com/salmonandrew/expertiza &amp;lt;br&amp;gt;&lt;br /&gt;
Pull Request - https://github.com/expertiza/expertiza/pull/1840 &amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Team ==&lt;br /&gt;
'''Mentor: '''Sanket Pai (sgpai2@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
*Yen-An Jou (yjou@ncsu.edu)&lt;br /&gt;
*Xiwen Chen (xchen33@ncsu.edu)&lt;br /&gt;
*Andrew Hirasawa (achirasa@ncsu.edu)&lt;br /&gt;
*Derrick Li (xli56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== References / Previous Implementation ==&lt;br /&gt;
&lt;br /&gt;
*Previous Wikipedia page - [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1865._Conflict_Notification E1865 Conflict Notification Fall 2018]&lt;br /&gt;
&lt;br /&gt;
*Previous Final Video - [https://drive.google.com/drive/folders/1Z8rqRxdmXJYbOZzoptmBLP0kM7Bdul2Q Final Video]&lt;br /&gt;
&lt;br /&gt;
*Previous Pull Request -[https://github.com/expertiza/expertiza/pull/1445 Pull Request 1445]&lt;br /&gt;
&lt;br /&gt;
*Previous Github Repo - [https://github.com/cshinde57/expertiza Github Repo]&lt;br /&gt;
{{reflist}}&lt;/div&gt;</summary>
		<author><name>Xli56</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137157</id>
		<title>CSC/ECE 517 Fall 2020 - E2087. Conflict notification. Improve Search Facility In Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137157"/>
		<updated>2020-11-17T03:00:31Z</updated>

		<summary type="html">&lt;p&gt;Xli56: /* New Implementation */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Expertiza includes the functionality of notifying instructors when a conflict occurs in review scores for a submission. Currently, when two reviews for the same submission differ significantly, an email is sent to the instructor of the course, but there is no link to the review that caused the conflict. This improvement will allow the professor to have links to the reviews that caused the conflict and will be formatted better to help the instructor understand the conflict.&lt;br /&gt;
&lt;br /&gt;
=== Issues with previous submission ===&lt;br /&gt;
&lt;br /&gt;
# The functionality is good but the UI of conflict report needs work. &lt;br /&gt;
# The UI needs to be cleaned up a little. When charts have only one or two bars, the chart can be compressed. The reviewer whose scores deviate from the threshold can be displayed in a different colored bar.&lt;br /&gt;
# Tests need to be refactored.&lt;br /&gt;
# They included their debug code in their pull request. &lt;br /&gt;
# They have included a lot of logic in the views. &lt;br /&gt;
# Shallow tests: one or more of their test expectations only focus on the return value not being `nil`, `empty` or not equal to `0` without testing the `real` value.&lt;br /&gt;
&lt;br /&gt;
== Proposed Solution ==&lt;br /&gt;
&lt;br /&gt;
The previous team implemented new logic to determine if a review is in conflict with another and created a new page to link the instructors to in the email. Because their functionality was good, we will mainly be focused on improving the UI of the conflict reports. Furthermore, there is a lot of logic that lives in the views that can be refactored and moved to controllers. Additionally, there is debug code that can be removed and tests that can be fleshed out.&lt;br /&gt;
&lt;br /&gt;
=== UI Imporvements ===&lt;br /&gt;
&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb&lt;br /&gt;
&lt;br /&gt;
The UI can be improved for the conflict metric to give more information on the conflicted reviews.&lt;br /&gt;
&lt;br /&gt;
=== Logic in Views ===&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb &lt;br /&gt;
&lt;br /&gt;
The logic to determine if answers are within or outside of the tolerance limits can be moved to functions outside of the .erb file.&lt;br /&gt;
&lt;br /&gt;
== UML Activity Diagram ==&lt;br /&gt;
[[File:517 Final Project Student UML.jpg]]&lt;br /&gt;
[[File:517 Final Project Instructor UML.jpg]]&lt;br /&gt;
&lt;br /&gt;
== UI Changes ==&lt;br /&gt;
&lt;br /&gt;
Based on the previous changes from last group, the notification email triggered will send to the instructor whenever two reviews for the same submission differ &amp;quot;significantly&amp;quot; on their scoring (the threshold is specified in the &amp;quot;Notification limit&amp;quot; on the Rubric tab of assignment creation).&lt;br /&gt;
&lt;br /&gt;
[[File:afteremail.JPG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the email notification, the formatting can be improved to make it more readable and clear as to which links relate to what actions and what caused the conflict to trigger.&lt;br /&gt;
&lt;br /&gt;
The previous group of snapshot for the view which the instructor receives&lt;br /&gt;
&lt;br /&gt;
[[File:afterfix.PNG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the 'review for mail check' page, more information can be added to indicate if a review has a conflict. We will add indicators beside each review that have conflicts.&lt;br /&gt;
&lt;br /&gt;
== Test Plan==&lt;br /&gt;
&lt;br /&gt;
=== Manual Test Plan ===&lt;br /&gt;
&lt;br /&gt;
To verify the conflict notification is working correctly, a mock assignment will be created and two reviews will be entered that should trigger a conflict. Successful retrieval of the email and verification of the links included in the email will provide sufficient verification that the changes were successful.&lt;br /&gt;
&lt;br /&gt;
=== File Changes ===&lt;br /&gt;
File: spec/models/answer_spec.rb&lt;br /&gt;
&lt;br /&gt;
Currently, tests only check if the values are not empty. More tests can be written to make sure the actual value is being returned correctly.&lt;br /&gt;
&lt;br /&gt;
File: spec/controllers/reports_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
More tests can be written to ensure correct names and values are written.&lt;br /&gt;
&lt;br /&gt;
== Implemented Solution ==&lt;br /&gt;
&lt;br /&gt;
=== Refactoring ===&lt;br /&gt;
&lt;br /&gt;
Moved following methods from review_mapping_helper.rb to report_formatter_helper.rb&lt;br /&gt;
&lt;br /&gt;
* average_of_round&lt;br /&gt;
* std_of_round&lt;br /&gt;
* review_score_helper_for_team&lt;br /&gt;
* review_score_for_team&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== New Implementation   ===&lt;br /&gt;
Adding base_url from the controller as this method is not accessible from model&lt;br /&gt;
&amp;lt;pre&amp;gt; @response.notify_instructor_on_difference(request.base_url) if (@map.is_a? ReviewResponseMap) &lt;br /&gt;
                       &amp;amp;&amp;amp; @response.is_submitted &amp;amp;&amp;amp; @response.significant_difference?&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt; @response.notify_instructor_on_difference(request.base_url)&amp;lt;/pre&amp;gt;&lt;br /&gt;
This method generates statistics for each round&lt;br /&gt;
&amp;lt;pre&amp;gt;def review_statistics(id, team_name)&lt;br /&gt;
     res = []&lt;br /&gt;
     question_answers = review_score_for_team(id, team_name)&lt;br /&gt;
     question_answers.each do |question_answer|&lt;br /&gt;
       round = {}&lt;br /&gt;
       round[:question_answer] = question_answer&lt;br /&gt;
       round[:average] = average_of_round(question_answer)&lt;br /&gt;
       round[:std] = std_of_round(round[:average], question_answer)&lt;br /&gt;
       round[:upper_tolerance_limit] = (round[:average]+(2*round[:std])).round(2)&lt;br /&gt;
       round[:lower_tolerance_limit] = (round[:average]-(2*round[:std])).round(2)&lt;br /&gt;
       res.push(round)&lt;br /&gt;
     end&lt;br /&gt;
     res&lt;br /&gt;
   end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Relevant Links ==&lt;br /&gt;
GitHub - https://github.com/salmonandrew/expertiza &amp;lt;br&amp;gt;&lt;br /&gt;
Pull Request - https://github.com/expertiza/expertiza/pull/1840 &amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Team ==&lt;br /&gt;
'''Mentor: '''Sanket Pai (sgpai2@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
*Yen-An Jou (yjou@ncsu.edu)&lt;br /&gt;
*Xiwen Chen (xchen33@ncsu.edu)&lt;br /&gt;
*Andrew Hirasawa (achirasa@ncsu.edu)&lt;br /&gt;
*Derrick Li (xli56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== References / Previous Implementation ==&lt;br /&gt;
&lt;br /&gt;
*Previous Wikipedia page - [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1865._Conflict_Notification E1865 Conflict Notification Fall 2018]&lt;br /&gt;
&lt;br /&gt;
*Previous Final Video - [https://drive.google.com/drive/folders/1Z8rqRxdmXJYbOZzoptmBLP0kM7Bdul2Q Final Video]&lt;br /&gt;
&lt;br /&gt;
*Previous Pull Request -[https://github.com/expertiza/expertiza/pull/1445 Pull Request 1445]&lt;br /&gt;
&lt;br /&gt;
*Previous Github Repo - [https://github.com/cshinde57/expertiza Github Repo]&lt;br /&gt;
{{reflist}}&lt;/div&gt;</summary>
		<author><name>Xli56</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137155</id>
		<title>CSC/ECE 517 Fall 2020 - E2087. Conflict notification. Improve Search Facility In Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137155"/>
		<updated>2020-11-17T02:57:02Z</updated>

		<summary type="html">&lt;p&gt;Xli56: /* New Implementation */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Expertiza includes the functionality of notifying instructors when a conflict occurs in review scores for a submission. Currently, when two reviews for the same submission differ significantly, an email is sent to the instructor of the course, but there is no link to the review that caused the conflict. This improvement will allow the professor to have links to the reviews that caused the conflict and will be formatted better to help the instructor understand the conflict.&lt;br /&gt;
&lt;br /&gt;
=== Issues with previous submission ===&lt;br /&gt;
&lt;br /&gt;
# The functionality is good but the UI of conflict report needs work. &lt;br /&gt;
# The UI needs to be cleaned up a little. When charts have only one or two bars, the chart can be compressed. The reviewer whose scores deviate from the threshold can be displayed in a different colored bar.&lt;br /&gt;
# Tests need to be refactored.&lt;br /&gt;
# They included their debug code in their pull request. &lt;br /&gt;
# They have included a lot of logic in the views. &lt;br /&gt;
# Shallow tests: one or more of their test expectations only focus on the return value not being `nil`, `empty` or not equal to `0` without testing the `real` value.&lt;br /&gt;
&lt;br /&gt;
== Proposed Solution ==&lt;br /&gt;
&lt;br /&gt;
The previous team implemented new logic to determine if a review is in conflict with another and created a new page to link the instructors to in the email. Because their functionality was good, we will mainly be focused on improving the UI of the conflict reports. Furthermore, there is a lot of logic that lives in the views that can be refactored and moved to controllers. Additionally, there is debug code that can be removed and tests that can be fleshed out.&lt;br /&gt;
&lt;br /&gt;
=== UI Imporvements ===&lt;br /&gt;
&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb&lt;br /&gt;
&lt;br /&gt;
The UI can be improved for the conflict metric to give more information on the conflicted reviews.&lt;br /&gt;
&lt;br /&gt;
=== Logic in Views ===&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb &lt;br /&gt;
&lt;br /&gt;
The logic to determine if answers are within or outside of the tolerance limits can be moved to functions outside of the .erb file.&lt;br /&gt;
&lt;br /&gt;
== UML Activity Diagram ==&lt;br /&gt;
[[File:517 Final Project Student UML.jpg]]&lt;br /&gt;
[[File:517 Final Project Instructor UML.jpg]]&lt;br /&gt;
&lt;br /&gt;
== UI Changes ==&lt;br /&gt;
&lt;br /&gt;
Based on the previous changes from last group, the notification email triggered will send to the instructor whenever two reviews for the same submission differ &amp;quot;significantly&amp;quot; on their scoring (the threshold is specified in the &amp;quot;Notification limit&amp;quot; on the Rubric tab of assignment creation).&lt;br /&gt;
&lt;br /&gt;
[[File:afteremail.JPG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the email notification, the formatting can be improved to make it more readable and clear as to which links relate to what actions and what caused the conflict to trigger.&lt;br /&gt;
&lt;br /&gt;
The previous group of snapshot for the view which the instructor receives&lt;br /&gt;
&lt;br /&gt;
[[File:afterfix.PNG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the 'review for mail check' page, more information can be added to indicate if a review has a conflict. We will add indicators beside each review that have conflicts.&lt;br /&gt;
&lt;br /&gt;
== Test Plan==&lt;br /&gt;
&lt;br /&gt;
=== Manual Test Plan ===&lt;br /&gt;
&lt;br /&gt;
To verify the conflict notification is working correctly, a mock assignment will be created and two reviews will be entered that should trigger a conflict. Successful retrieval of the email and verification of the links included in the email will provide sufficient verification that the changes were successful.&lt;br /&gt;
&lt;br /&gt;
=== File Changes ===&lt;br /&gt;
File: spec/models/answer_spec.rb&lt;br /&gt;
&lt;br /&gt;
Currently, tests only check if the values are not empty. More tests can be written to make sure the actual value is being returned correctly.&lt;br /&gt;
&lt;br /&gt;
File: spec/controllers/reports_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
More tests can be written to ensure correct names and values are written.&lt;br /&gt;
&lt;br /&gt;
== Implemented Solution ==&lt;br /&gt;
&lt;br /&gt;
=== Refactoring ===&lt;br /&gt;
&lt;br /&gt;
Moved following methods from review_mapping_helper.rb to report_formatter_helper.rb&lt;br /&gt;
&lt;br /&gt;
* average_of_round&lt;br /&gt;
* std_of_round&lt;br /&gt;
* review_score_helper_for_team&lt;br /&gt;
* review_score_for_team&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== New Implementation   ===&lt;br /&gt;
Adding base_url from the controller as this method is not accessible from model&lt;br /&gt;
&amp;lt;pre&amp;gt; @response.notify_instructor_on_difference(request.base_url) if (@map.is_a? ReviewResponseMap) &lt;br /&gt;
                       &amp;amp;&amp;amp; @response.is_submitted &amp;amp;&amp;amp; @response.significant_difference?&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt; @response.notify_instructor_on_difference(request.base_url)&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;# generate statistics for each round&lt;br /&gt;
   def review_statistics(id, team_name)&lt;br /&gt;
     res = []&lt;br /&gt;
     question_answers = review_score_for_team(id, team_name)&lt;br /&gt;
     question_answers.each do |question_answer|&lt;br /&gt;
       round = {}&lt;br /&gt;
       round[:question_answer] = question_answer&lt;br /&gt;
       round[:average] = average_of_round(question_answer)&lt;br /&gt;
       round[:std] = std_of_round(round[:average], question_answer)&lt;br /&gt;
       round[:upper_tolerance_limit] = (round[:average]+(2*round[:std])).round(2)&lt;br /&gt;
       round[:lower_tolerance_limit] = (round[:average]-(2*round[:std])).round(2)&lt;br /&gt;
       res.push(round)&lt;br /&gt;
     end&lt;br /&gt;
     res&lt;br /&gt;
   end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Relevant Links ==&lt;br /&gt;
GitHub - https://github.com/salmonandrew/expertiza &amp;lt;br&amp;gt;&lt;br /&gt;
Pull Request - https://github.com/expertiza/expertiza/pull/1840 &amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Team ==&lt;br /&gt;
'''Mentor: '''Sanket Pai (sgpai2@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
*Yen-An Jou (yjou@ncsu.edu)&lt;br /&gt;
*Xiwen Chen (xchen33@ncsu.edu)&lt;br /&gt;
*Andrew Hirasawa (achirasa@ncsu.edu)&lt;br /&gt;
*Derrick Li (xli56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== References / Previous Implementation ==&lt;br /&gt;
&lt;br /&gt;
*Previous Wikipedia page - [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1865._Conflict_Notification E1865 Conflict Notification Fall 2018]&lt;br /&gt;
&lt;br /&gt;
*Previous Final Video - [https://drive.google.com/drive/folders/1Z8rqRxdmXJYbOZzoptmBLP0kM7Bdul2Q Final Video]&lt;br /&gt;
&lt;br /&gt;
*Previous Pull Request -[https://github.com/expertiza/expertiza/pull/1445 Pull Request 1445]&lt;br /&gt;
&lt;br /&gt;
*Previous Github Repo - [https://github.com/cshinde57/expertiza Github Repo]&lt;br /&gt;
{{reflist}}&lt;/div&gt;</summary>
		<author><name>Xli56</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137145</id>
		<title>CSC/ECE 517 Fall 2020 - E2087. Conflict notification. Improve Search Facility In Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137145"/>
		<updated>2020-11-17T02:06:00Z</updated>

		<summary type="html">&lt;p&gt;Xli56: /* New Implementation */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Expertiza includes the functionality of notifying instructors when a conflict occurs in review scores for a submission. Currently, when two reviews for the same submission differ significantly, an email is sent to the instructor of the course, but there is no link to the review that caused the conflict. This improvement will allow the professor to have links to the reviews that caused the conflict and will be formatted better to help the instructor understand the conflict.&lt;br /&gt;
&lt;br /&gt;
=== Issues with previous submission ===&lt;br /&gt;
&lt;br /&gt;
# The functionality is good but the UI of conflict report needs work. &lt;br /&gt;
# The UI needs to be cleaned up a little. When charts have only one or two bars, the chart can be compressed. The reviewer whose scores deviate from the threshold can be displayed in a different colored bar.&lt;br /&gt;
# Tests need to be refactored.&lt;br /&gt;
# They included their debug code in their pull request. &lt;br /&gt;
# They have included a lot of logic in the views. &lt;br /&gt;
# Shallow tests: one or more of their test expectations only focus on the return value not being `nil`, `empty` or not equal to `0` without testing the `real` value.&lt;br /&gt;
&lt;br /&gt;
== Proposed Solution ==&lt;br /&gt;
&lt;br /&gt;
The previous team implemented new logic to determine if a review is in conflict with another and created a new page to link the instructors to in the email. Because their functionality was good, we will mainly be focused on improving the UI of the conflict reports. Furthermore, there is a lot of logic that lives in the views that can be refactored and moved to controllers. Additionally, there is debug code that can be removed and tests that can be fleshed out.&lt;br /&gt;
&lt;br /&gt;
=== UI Imporvements ===&lt;br /&gt;
&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb&lt;br /&gt;
&lt;br /&gt;
The UI can be improved for the conflict metric to give more information on the conflicted reviews.&lt;br /&gt;
&lt;br /&gt;
=== Logic in Views ===&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb &lt;br /&gt;
&lt;br /&gt;
The logic to determine if answers are within or outside of the tolerance limits can be moved to functions outside of the .erb file.&lt;br /&gt;
&lt;br /&gt;
== UML Activity Diagram ==&lt;br /&gt;
[[File:517 Final Project Student UML.jpg]]&lt;br /&gt;
[[File:517 Final Project Instructor UML.jpg]]&lt;br /&gt;
&lt;br /&gt;
== UI Changes ==&lt;br /&gt;
&lt;br /&gt;
Based on the previous changes from last group, the notification email triggered will send to the instructor whenever two reviews for the same submission differ &amp;quot;significantly&amp;quot; on their scoring (the threshold is specified in the &amp;quot;Notification limit&amp;quot; on the Rubric tab of assignment creation).&lt;br /&gt;
&lt;br /&gt;
[[File:afteremail.JPG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the email notification, the formatting can be improved to make it more readable and clear as to which links relate to what actions and what caused the conflict to trigger.&lt;br /&gt;
&lt;br /&gt;
The previous group of snapshot for the view which the instructor receives&lt;br /&gt;
&lt;br /&gt;
[[File:afterfix.PNG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the 'review for mail check' page, more information can be added to indicate if a review has a conflict. We will add indicators beside each review that have conflicts.&lt;br /&gt;
&lt;br /&gt;
== Test Plan==&lt;br /&gt;
&lt;br /&gt;
=== Manual Test Plan ===&lt;br /&gt;
&lt;br /&gt;
To verify the conflict notification is working correctly, a mock assignment will be created and two reviews will be entered that should trigger a conflict. Successful retrieval of the email and verification of the links included in the email will provide sufficient verification that the changes were successful.&lt;br /&gt;
&lt;br /&gt;
=== File Changes ===&lt;br /&gt;
File: spec/models/answer_spec.rb&lt;br /&gt;
&lt;br /&gt;
Currently, tests only check if the values are not empty. More tests can be written to make sure the actual value is being returned correctly.&lt;br /&gt;
&lt;br /&gt;
File: spec/controllers/reports_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
More tests can be written to ensure correct names and values are written.&lt;br /&gt;
&lt;br /&gt;
== Implemented Solution ==&lt;br /&gt;
&lt;br /&gt;
=== Refactoring ===&lt;br /&gt;
&lt;br /&gt;
Moved following methods from review_mapping_helper.rb to report_formatter_helper.rb&lt;br /&gt;
&lt;br /&gt;
* average_of_round&lt;br /&gt;
* std_of_round&lt;br /&gt;
* review_score_helper_for_team&lt;br /&gt;
* review_score_for_team&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== New Implementation   ===&lt;br /&gt;
Adding base_url from the controller as this method is not accessible from model&lt;br /&gt;
&amp;lt;pre&amp;gt; @response.notify_instructor_on_difference(request.base_url) if (@map.is_a? ReviewResponseMap) &lt;br /&gt;
                       &amp;amp;&amp;amp; @response.is_submitted &amp;amp;&amp;amp; @response.significant_difference?&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt; @response.notify_instructor_on_difference(request.base_url)&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Relevant Links ==&lt;br /&gt;
GitHub - https://github.com/salmonandrew/expertiza &amp;lt;br&amp;gt;&lt;br /&gt;
Pull Request - https://github.com/expertiza/expertiza/pull/1840 &amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Team ==&lt;br /&gt;
'''Mentor: '''Sanket Pai (sgpai2@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
*Yen-An Jou (yjou@ncsu.edu)&lt;br /&gt;
*Xiwen Chen (xchen33@ncsu.edu)&lt;br /&gt;
*Andrew Hirasawa (achirasa@ncsu.edu)&lt;br /&gt;
*Derrick Li (xli56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== References / Previous Implementation ==&lt;br /&gt;
&lt;br /&gt;
*Previous Wikipedia page - [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1865._Conflict_Notification E1865 Conflict Notification Fall 2018]&lt;br /&gt;
&lt;br /&gt;
*Previous Final Video - [https://drive.google.com/drive/folders/1Z8rqRxdmXJYbOZzoptmBLP0kM7Bdul2Q Final Video]&lt;br /&gt;
&lt;br /&gt;
*Previous Pull Request -[https://github.com/expertiza/expertiza/pull/1445 Pull Request 1445]&lt;br /&gt;
&lt;br /&gt;
*Previous Github Repo - [https://github.com/cshinde57/expertiza Github Repo]&lt;br /&gt;
{{reflist}}&lt;/div&gt;</summary>
		<author><name>Xli56</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137118</id>
		<title>CSC/ECE 517 Fall 2020 - E2087. Conflict notification. Improve Search Facility In Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137118"/>
		<updated>2020-11-17T01:24:46Z</updated>

		<summary type="html">&lt;p&gt;Xli56: /* New Implementation */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Expertiza includes the functionality of notifying instructors when a conflict occurs in review scores for a submission. Currently, when two reviews for the same submission differ significantly, an email is sent to the instructor of the course, but there is no link to the review that caused the conflict. This improvement will allow the professor to have links to the reviews that caused the conflict and will be formatted better to help the instructor understand the conflict.&lt;br /&gt;
&lt;br /&gt;
=== Issues with previous submission ===&lt;br /&gt;
&lt;br /&gt;
# The functionality is good but the UI of conflict report needs work. &lt;br /&gt;
# The UI needs to be cleaned up a little. When charts have only one or two bars, the chart can be compressed. The reviewer whose scores deviate from the threshold can be displayed in a different colored bar.&lt;br /&gt;
# Tests need to be refactored.&lt;br /&gt;
# They included their debug code in their pull request. &lt;br /&gt;
# They have included a lot of logic in the views. &lt;br /&gt;
# Shallow tests: one or more of their test expectations only focus on the return value not being `nil`, `empty` or not equal to `0` without testing the `real` value.&lt;br /&gt;
&lt;br /&gt;
== Proposed Solution ==&lt;br /&gt;
&lt;br /&gt;
The previous team implemented new logic to determine if a review is in conflict with another and created a new page to link the instructors to in the email. Because their functionality was good, we will mainly be focused on improving the UI of the conflict reports. Furthermore, there is a lot of logic that lives in the views that can be refactored and moved to controllers. Additionally, there is debug code that can be removed and tests that can be fleshed out.&lt;br /&gt;
&lt;br /&gt;
=== UI Imporvements ===&lt;br /&gt;
&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb&lt;br /&gt;
&lt;br /&gt;
The UI can be improved for the conflict metric to give more information on the conflicted reviews.&lt;br /&gt;
&lt;br /&gt;
=== Logic in Views ===&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb &lt;br /&gt;
&lt;br /&gt;
The logic to determine if answers are within or outside of the tolerance limits can be moved to functions outside of the .erb file.&lt;br /&gt;
&lt;br /&gt;
== UML Activity Diagram ==&lt;br /&gt;
[[File:517 Final Project Student UML.jpg]]&lt;br /&gt;
[[File:517 Final Project Instructor UML.jpg]]&lt;br /&gt;
&lt;br /&gt;
== UI Changes ==&lt;br /&gt;
&lt;br /&gt;
Based on the previous changes from last group, the notification email triggered will send to the instructor whenever two reviews for the same submission differ &amp;quot;significantly&amp;quot; on their scoring (the threshold is specified in the &amp;quot;Notification limit&amp;quot; on the Rubric tab of assignment creation).&lt;br /&gt;
&lt;br /&gt;
[[File:afteremail.JPG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the email notification, the formatting can be improved to make it more readable and clear as to which links relate to what actions and what caused the conflict to trigger.&lt;br /&gt;
&lt;br /&gt;
The previous group of snapshot for the view which the instructor receives&lt;br /&gt;
&lt;br /&gt;
[[File:afterfix.PNG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the 'review for mail check' page, more information can be added to indicate if a review has a conflict. We will add indicators beside each review that have conflicts.&lt;br /&gt;
&lt;br /&gt;
== Test Plan==&lt;br /&gt;
&lt;br /&gt;
=== Manual Test Plan ===&lt;br /&gt;
&lt;br /&gt;
To verify the conflict notification is working correctly, a mock assignment will be created and two reviews will be entered that should trigger a conflict. Successful retrieval of the email and verification of the links included in the email will provide sufficient verification that the changes were successful.&lt;br /&gt;
&lt;br /&gt;
=== File Changes ===&lt;br /&gt;
File: spec/models/answer_spec.rb&lt;br /&gt;
&lt;br /&gt;
Currently, tests only check if the values are not empty. More tests can be written to make sure the actual value is being returned correctly.&lt;br /&gt;
&lt;br /&gt;
File: spec/controllers/reports_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
More tests can be written to ensure correct names and values are written.&lt;br /&gt;
&lt;br /&gt;
== Implemented Solution ==&lt;br /&gt;
&lt;br /&gt;
=== Refactoring ===&lt;br /&gt;
&lt;br /&gt;
Moved following methods from review_mapping_helper.rb to report_formatter_helper.rb&lt;br /&gt;
&lt;br /&gt;
* average_of_round&lt;br /&gt;
* std_of_round&lt;br /&gt;
* review_score_helper_for_team&lt;br /&gt;
* review_score_for_team&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== New Implementation   ===&lt;br /&gt;
Adding base_url from the controller as this method is not accessible from model&lt;br /&gt;
&amp;lt;pre&amp;gt; @response.notify_instructor_on_difference(request.base_url) if (@map.is_a? ReviewResponseMap) &lt;br /&gt;
                       &amp;amp;&amp;amp; @response.is_submitted &amp;amp;&amp;amp; @response.significant_difference?&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Relevant Links ==&lt;br /&gt;
GitHub - https://github.com/salmonandrew/expertiza &amp;lt;br&amp;gt;&lt;br /&gt;
Pull Request - https://github.com/expertiza/expertiza/pull/1840 &amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Team ==&lt;br /&gt;
'''Mentor: '''Sanket Pai (sgpai2@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
*Yen-An Jou (yjou@ncsu.edu)&lt;br /&gt;
*Xiwen Chen (xchen33@ncsu.edu)&lt;br /&gt;
*Andrew Hirasawa (achirasa@ncsu.edu)&lt;br /&gt;
*Derrick Li (xli56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== References / Previous Implementation ==&lt;br /&gt;
&lt;br /&gt;
*Previous Wikipedia page - [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1865._Conflict_Notification E1865 Conflict Notification Fall 2018]&lt;br /&gt;
&lt;br /&gt;
*Previous Final Video - [https://drive.google.com/drive/folders/1Z8rqRxdmXJYbOZzoptmBLP0kM7Bdul2Q Final Video]&lt;br /&gt;
&lt;br /&gt;
*Previous Pull Request -[https://github.com/expertiza/expertiza/pull/1445 Pull Request 1445]&lt;br /&gt;
&lt;br /&gt;
*Previous Github Repo - [https://github.com/cshinde57/expertiza Github Repo]&lt;br /&gt;
{{reflist}}&lt;/div&gt;</summary>
		<author><name>Xli56</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137116</id>
		<title>CSC/ECE 517 Fall 2020 - E2087. Conflict notification. Improve Search Facility In Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137116"/>
		<updated>2020-11-17T01:24:29Z</updated>

		<summary type="html">&lt;p&gt;Xli56: /* New Implementation */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Expertiza includes the functionality of notifying instructors when a conflict occurs in review scores for a submission. Currently, when two reviews for the same submission differ significantly, an email is sent to the instructor of the course, but there is no link to the review that caused the conflict. This improvement will allow the professor to have links to the reviews that caused the conflict and will be formatted better to help the instructor understand the conflict.&lt;br /&gt;
&lt;br /&gt;
=== Issues with previous submission ===&lt;br /&gt;
&lt;br /&gt;
# The functionality is good but the UI of conflict report needs work. &lt;br /&gt;
# The UI needs to be cleaned up a little. When charts have only one or two bars, the chart can be compressed. The reviewer whose scores deviate from the threshold can be displayed in a different colored bar.&lt;br /&gt;
# Tests need to be refactored.&lt;br /&gt;
# They included their debug code in their pull request. &lt;br /&gt;
# They have included a lot of logic in the views. &lt;br /&gt;
# Shallow tests: one or more of their test expectations only focus on the return value not being `nil`, `empty` or not equal to `0` without testing the `real` value.&lt;br /&gt;
&lt;br /&gt;
== Proposed Solution ==&lt;br /&gt;
&lt;br /&gt;
The previous team implemented new logic to determine if a review is in conflict with another and created a new page to link the instructors to in the email. Because their functionality was good, we will mainly be focused on improving the UI of the conflict reports. Furthermore, there is a lot of logic that lives in the views that can be refactored and moved to controllers. Additionally, there is debug code that can be removed and tests that can be fleshed out.&lt;br /&gt;
&lt;br /&gt;
=== UI Imporvements ===&lt;br /&gt;
&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb&lt;br /&gt;
&lt;br /&gt;
The UI can be improved for the conflict metric to give more information on the conflicted reviews.&lt;br /&gt;
&lt;br /&gt;
=== Logic in Views ===&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb &lt;br /&gt;
&lt;br /&gt;
The logic to determine if answers are within or outside of the tolerance limits can be moved to functions outside of the .erb file.&lt;br /&gt;
&lt;br /&gt;
== UML Activity Diagram ==&lt;br /&gt;
[[File:517 Final Project Student UML.jpg]]&lt;br /&gt;
[[File:517 Final Project Instructor UML.jpg]]&lt;br /&gt;
&lt;br /&gt;
== UI Changes ==&lt;br /&gt;
&lt;br /&gt;
Based on the previous changes from last group, the notification email triggered will send to the instructor whenever two reviews for the same submission differ &amp;quot;significantly&amp;quot; on their scoring (the threshold is specified in the &amp;quot;Notification limit&amp;quot; on the Rubric tab of assignment creation).&lt;br /&gt;
&lt;br /&gt;
[[File:afteremail.JPG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the email notification, the formatting can be improved to make it more readable and clear as to which links relate to what actions and what caused the conflict to trigger.&lt;br /&gt;
&lt;br /&gt;
The previous group of snapshot for the view which the instructor receives&lt;br /&gt;
&lt;br /&gt;
[[File:afterfix.PNG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the 'review for mail check' page, more information can be added to indicate if a review has a conflict. We will add indicators beside each review that have conflicts.&lt;br /&gt;
&lt;br /&gt;
== Test Plan==&lt;br /&gt;
&lt;br /&gt;
=== Manual Test Plan ===&lt;br /&gt;
&lt;br /&gt;
To verify the conflict notification is working correctly, a mock assignment will be created and two reviews will be entered that should trigger a conflict. Successful retrieval of the email and verification of the links included in the email will provide sufficient verification that the changes were successful.&lt;br /&gt;
&lt;br /&gt;
=== File Changes ===&lt;br /&gt;
File: spec/models/answer_spec.rb&lt;br /&gt;
&lt;br /&gt;
Currently, tests only check if the values are not empty. More tests can be written to make sure the actual value is being returned correctly.&lt;br /&gt;
&lt;br /&gt;
File: spec/controllers/reports_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
More tests can be written to ensure correct names and values are written.&lt;br /&gt;
&lt;br /&gt;
== Implemented Solution ==&lt;br /&gt;
&lt;br /&gt;
=== Refactoring ===&lt;br /&gt;
&lt;br /&gt;
Moved following methods from review_mapping_helper.rb to report_formatter_helper.rb&lt;br /&gt;
&lt;br /&gt;
* average_of_round&lt;br /&gt;
* std_of_round&lt;br /&gt;
* review_score_helper_for_team&lt;br /&gt;
* review_score_for_team&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== New Implementation   ===&lt;br /&gt;
Adding base_url from the controller as this method is not accessible from model&lt;br /&gt;
&amp;lt;pre&amp;gt; &lt;br /&gt;
@response.notify_instructor_on_difference(request.base_url) if (@map.is_a? ReviewResponseMap) &lt;br /&gt;
                       &amp;amp;&amp;amp; @response.is_submitted &amp;amp;&amp;amp; @response.significant_difference?&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Relevant Links ==&lt;br /&gt;
GitHub - https://github.com/salmonandrew/expertiza &amp;lt;br&amp;gt;&lt;br /&gt;
Pull Request - https://github.com/expertiza/expertiza/pull/1840 &amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Team ==&lt;br /&gt;
'''Mentor: '''Sanket Pai (sgpai2@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
*Yen-An Jou (yjou@ncsu.edu)&lt;br /&gt;
*Xiwen Chen (xchen33@ncsu.edu)&lt;br /&gt;
*Andrew Hirasawa (achirasa@ncsu.edu)&lt;br /&gt;
*Derrick Li (xli56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== References / Previous Implementation ==&lt;br /&gt;
&lt;br /&gt;
*Previous Wikipedia page - [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1865._Conflict_Notification E1865 Conflict Notification Fall 2018]&lt;br /&gt;
&lt;br /&gt;
*Previous Final Video - [https://drive.google.com/drive/folders/1Z8rqRxdmXJYbOZzoptmBLP0kM7Bdul2Q Final Video]&lt;br /&gt;
&lt;br /&gt;
*Previous Pull Request -[https://github.com/expertiza/expertiza/pull/1445 Pull Request 1445]&lt;br /&gt;
&lt;br /&gt;
*Previous Github Repo - [https://github.com/cshinde57/expertiza Github Repo]&lt;br /&gt;
{{reflist}}&lt;/div&gt;</summary>
		<author><name>Xli56</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137114</id>
		<title>CSC/ECE 517 Fall 2020 - E2087. Conflict notification. Improve Search Facility In Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137114"/>
		<updated>2020-11-17T01:21:40Z</updated>

		<summary type="html">&lt;p&gt;Xli56: /* New Implementation */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Expertiza includes the functionality of notifying instructors when a conflict occurs in review scores for a submission. Currently, when two reviews for the same submission differ significantly, an email is sent to the instructor of the course, but there is no link to the review that caused the conflict. This improvement will allow the professor to have links to the reviews that caused the conflict and will be formatted better to help the instructor understand the conflict.&lt;br /&gt;
&lt;br /&gt;
=== Issues with previous submission ===&lt;br /&gt;
&lt;br /&gt;
# The functionality is good but the UI of conflict report needs work. &lt;br /&gt;
# The UI needs to be cleaned up a little. When charts have only one or two bars, the chart can be compressed. The reviewer whose scores deviate from the threshold can be displayed in a different colored bar.&lt;br /&gt;
# Tests need to be refactored.&lt;br /&gt;
# They included their debug code in their pull request. &lt;br /&gt;
# They have included a lot of logic in the views. &lt;br /&gt;
# Shallow tests: one or more of their test expectations only focus on the return value not being `nil`, `empty` or not equal to `0` without testing the `real` value.&lt;br /&gt;
&lt;br /&gt;
== Proposed Solution ==&lt;br /&gt;
&lt;br /&gt;
The previous team implemented new logic to determine if a review is in conflict with another and created a new page to link the instructors to in the email. Because their functionality was good, we will mainly be focused on improving the UI of the conflict reports. Furthermore, there is a lot of logic that lives in the views that can be refactored and moved to controllers. Additionally, there is debug code that can be removed and tests that can be fleshed out.&lt;br /&gt;
&lt;br /&gt;
=== UI Imporvements ===&lt;br /&gt;
&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb&lt;br /&gt;
&lt;br /&gt;
The UI can be improved for the conflict metric to give more information on the conflicted reviews.&lt;br /&gt;
&lt;br /&gt;
=== Logic in Views ===&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb &lt;br /&gt;
&lt;br /&gt;
The logic to determine if answers are within or outside of the tolerance limits can be moved to functions outside of the .erb file.&lt;br /&gt;
&lt;br /&gt;
== UML Activity Diagram ==&lt;br /&gt;
[[File:517 Final Project Student UML.jpg]]&lt;br /&gt;
[[File:517 Final Project Instructor UML.jpg]]&lt;br /&gt;
&lt;br /&gt;
== UI Changes ==&lt;br /&gt;
&lt;br /&gt;
Based on the previous changes from last group, the notification email triggered will send to the instructor whenever two reviews for the same submission differ &amp;quot;significantly&amp;quot; on their scoring (the threshold is specified in the &amp;quot;Notification limit&amp;quot; on the Rubric tab of assignment creation).&lt;br /&gt;
&lt;br /&gt;
[[File:afteremail.JPG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the email notification, the formatting can be improved to make it more readable and clear as to which links relate to what actions and what caused the conflict to trigger.&lt;br /&gt;
&lt;br /&gt;
The previous group of snapshot for the view which the instructor receives&lt;br /&gt;
&lt;br /&gt;
[[File:afterfix.PNG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the 'review for mail check' page, more information can be added to indicate if a review has a conflict. We will add indicators beside each review that have conflicts.&lt;br /&gt;
&lt;br /&gt;
== Test Plan==&lt;br /&gt;
&lt;br /&gt;
=== Manual Test Plan ===&lt;br /&gt;
&lt;br /&gt;
To verify the conflict notification is working correctly, a mock assignment will be created and two reviews will be entered that should trigger a conflict. Successful retrieval of the email and verification of the links included in the email will provide sufficient verification that the changes were successful.&lt;br /&gt;
&lt;br /&gt;
=== File Changes ===&lt;br /&gt;
File: spec/models/answer_spec.rb&lt;br /&gt;
&lt;br /&gt;
Currently, tests only check if the values are not empty. More tests can be written to make sure the actual value is being returned correctly.&lt;br /&gt;
&lt;br /&gt;
File: spec/controllers/reports_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
More tests can be written to ensure correct names and values are written.&lt;br /&gt;
&lt;br /&gt;
== Implemented Solution ==&lt;br /&gt;
&lt;br /&gt;
=== Refactoring ===&lt;br /&gt;
&lt;br /&gt;
Moved following methods from review_mapping_helper.rb to report_formatter_helper.rb&lt;br /&gt;
&lt;br /&gt;
* average_of_round&lt;br /&gt;
* std_of_round&lt;br /&gt;
* review_score_helper_for_team&lt;br /&gt;
* review_score_for_team&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== New Implementation   ===&lt;br /&gt;
&amp;lt;pre&amp;gt; #adding base_url from the controller as this method is not accessible from model&lt;br /&gt;
@response.notify_instructor_on_difference(request.base_url) if (@map.is_a? ReviewResponseMap) &lt;br /&gt;
                       &amp;amp;&amp;amp; @response.is_submitted &amp;amp;&amp;amp; @response.significant_difference?&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Relevant Links ==&lt;br /&gt;
GitHub - https://github.com/salmonandrew/expertiza &amp;lt;br&amp;gt;&lt;br /&gt;
Pull Request - https://github.com/expertiza/expertiza/pull/1840 &amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Team ==&lt;br /&gt;
'''Mentor: '''Sanket Pai (sgpai2@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
*Yen-An Jou (yjou@ncsu.edu)&lt;br /&gt;
*Xiwen Chen (xchen33@ncsu.edu)&lt;br /&gt;
*Andrew Hirasawa (achirasa@ncsu.edu)&lt;br /&gt;
*Derrick Li (xli56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== References / Previous Implementation ==&lt;br /&gt;
&lt;br /&gt;
*Previous Wikipedia page - [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1865._Conflict_Notification E1865 Conflict Notification Fall 2018]&lt;br /&gt;
&lt;br /&gt;
*Previous Final Video - [https://drive.google.com/drive/folders/1Z8rqRxdmXJYbOZzoptmBLP0kM7Bdul2Q Final Video]&lt;br /&gt;
&lt;br /&gt;
*Previous Pull Request -[https://github.com/expertiza/expertiza/pull/1445 Pull Request 1445]&lt;br /&gt;
&lt;br /&gt;
*Previous Github Repo - [https://github.com/cshinde57/expertiza Github Repo]&lt;br /&gt;
{{reflist}}&lt;/div&gt;</summary>
		<author><name>Xli56</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137112</id>
		<title>CSC/ECE 517 Fall 2020 - E2087. Conflict notification. Improve Search Facility In Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137112"/>
		<updated>2020-11-17T01:18:00Z</updated>

		<summary type="html">&lt;p&gt;Xli56: /* New Implementation */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Expertiza includes the functionality of notifying instructors when a conflict occurs in review scores for a submission. Currently, when two reviews for the same submission differ significantly, an email is sent to the instructor of the course, but there is no link to the review that caused the conflict. This improvement will allow the professor to have links to the reviews that caused the conflict and will be formatted better to help the instructor understand the conflict.&lt;br /&gt;
&lt;br /&gt;
=== Issues with previous submission ===&lt;br /&gt;
&lt;br /&gt;
# The functionality is good but the UI of conflict report needs work. &lt;br /&gt;
# The UI needs to be cleaned up a little. When charts have only one or two bars, the chart can be compressed. The reviewer whose scores deviate from the threshold can be displayed in a different colored bar.&lt;br /&gt;
# Tests need to be refactored.&lt;br /&gt;
# They included their debug code in their pull request. &lt;br /&gt;
# They have included a lot of logic in the views. &lt;br /&gt;
# Shallow tests: one or more of their test expectations only focus on the return value not being `nil`, `empty` or not equal to `0` without testing the `real` value.&lt;br /&gt;
&lt;br /&gt;
== Proposed Solution ==&lt;br /&gt;
&lt;br /&gt;
The previous team implemented new logic to determine if a review is in conflict with another and created a new page to link the instructors to in the email. Because their functionality was good, we will mainly be focused on improving the UI of the conflict reports. Furthermore, there is a lot of logic that lives in the views that can be refactored and moved to controllers. Additionally, there is debug code that can be removed and tests that can be fleshed out.&lt;br /&gt;
&lt;br /&gt;
=== UI Imporvements ===&lt;br /&gt;
&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb&lt;br /&gt;
&lt;br /&gt;
The UI can be improved for the conflict metric to give more information on the conflicted reviews.&lt;br /&gt;
&lt;br /&gt;
=== Logic in Views ===&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb &lt;br /&gt;
&lt;br /&gt;
The logic to determine if answers are within or outside of the tolerance limits can be moved to functions outside of the .erb file.&lt;br /&gt;
&lt;br /&gt;
== UML Activity Diagram ==&lt;br /&gt;
[[File:517 Final Project Student UML.jpg]]&lt;br /&gt;
[[File:517 Final Project Instructor UML.jpg]]&lt;br /&gt;
&lt;br /&gt;
== UI Changes ==&lt;br /&gt;
&lt;br /&gt;
Based on the previous changes from last group, the notification email triggered will send to the instructor whenever two reviews for the same submission differ &amp;quot;significantly&amp;quot; on their scoring (the threshold is specified in the &amp;quot;Notification limit&amp;quot; on the Rubric tab of assignment creation).&lt;br /&gt;
&lt;br /&gt;
[[File:afteremail.JPG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the email notification, the formatting can be improved to make it more readable and clear as to which links relate to what actions and what caused the conflict to trigger.&lt;br /&gt;
&lt;br /&gt;
The previous group of snapshot for the view which the instructor receives&lt;br /&gt;
&lt;br /&gt;
[[File:afterfix.PNG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the 'review for mail check' page, more information can be added to indicate if a review has a conflict. We will add indicators beside each review that have conflicts.&lt;br /&gt;
&lt;br /&gt;
== Test Plan==&lt;br /&gt;
&lt;br /&gt;
=== Manual Test Plan ===&lt;br /&gt;
&lt;br /&gt;
To verify the conflict notification is working correctly, a mock assignment will be created and two reviews will be entered that should trigger a conflict. Successful retrieval of the email and verification of the links included in the email will provide sufficient verification that the changes were successful.&lt;br /&gt;
&lt;br /&gt;
=== File Changes ===&lt;br /&gt;
File: spec/models/answer_spec.rb&lt;br /&gt;
&lt;br /&gt;
Currently, tests only check if the values are not empty. More tests can be written to make sure the actual value is being returned correctly.&lt;br /&gt;
&lt;br /&gt;
File: spec/controllers/reports_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
More tests can be written to ensure correct names and values are written.&lt;br /&gt;
&lt;br /&gt;
== Implemented Solution ==&lt;br /&gt;
&lt;br /&gt;
=== Refactoring ===&lt;br /&gt;
&lt;br /&gt;
Moved following methods from review_mapping_helper.rb to report_formatter_helper.rb&lt;br /&gt;
&lt;br /&gt;
* average_of_round&lt;br /&gt;
* std_of_round&lt;br /&gt;
* review_score_helper_for_team&lt;br /&gt;
* review_score_for_team&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== New Implementation   ===&lt;br /&gt;
&amp;lt;pre&amp;gt; #adding base_url from the controller as this method is not accessible from model&lt;br /&gt;
@response.notify_instructor_on_difference(request.base_url) if (@map.is_a? ReviewResponseMap) &amp;amp;&amp;amp; @response.is_submitted &amp;amp;&amp;amp; @response.significant_difference?&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Relevant Links ==&lt;br /&gt;
GitHub - https://github.com/salmonandrew/expertiza &amp;lt;br&amp;gt;&lt;br /&gt;
Pull Request - https://github.com/expertiza/expertiza/pull/1840 &amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Team ==&lt;br /&gt;
'''Mentor: '''Sanket Pai (sgpai2@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
*Yen-An Jou (yjou@ncsu.edu)&lt;br /&gt;
*Xiwen Chen (xchen33@ncsu.edu)&lt;br /&gt;
*Andrew Hirasawa (achirasa@ncsu.edu)&lt;br /&gt;
*Derrick Li (xli56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== References / Previous Implementation ==&lt;br /&gt;
&lt;br /&gt;
*Previous Wikipedia page - [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1865._Conflict_Notification E1865 Conflict Notification Fall 2018]&lt;br /&gt;
&lt;br /&gt;
*Previous Final Video - [https://drive.google.com/drive/folders/1Z8rqRxdmXJYbOZzoptmBLP0kM7Bdul2Q Final Video]&lt;br /&gt;
&lt;br /&gt;
*Previous Pull Request -[https://github.com/expertiza/expertiza/pull/1445 Pull Request 1445]&lt;br /&gt;
&lt;br /&gt;
*Previous Github Repo - [https://github.com/cshinde57/expertiza Github Repo]&lt;br /&gt;
{{reflist}}&lt;/div&gt;</summary>
		<author><name>Xli56</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137111</id>
		<title>CSC/ECE 517 Fall 2020 - E2087. Conflict notification. Improve Search Facility In Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137111"/>
		<updated>2020-11-17T01:15:32Z</updated>

		<summary type="html">&lt;p&gt;Xli56: /* New Implementation */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Expertiza includes the functionality of notifying instructors when a conflict occurs in review scores for a submission. Currently, when two reviews for the same submission differ significantly, an email is sent to the instructor of the course, but there is no link to the review that caused the conflict. This improvement will allow the professor to have links to the reviews that caused the conflict and will be formatted better to help the instructor understand the conflict.&lt;br /&gt;
&lt;br /&gt;
=== Issues with previous submission ===&lt;br /&gt;
&lt;br /&gt;
# The functionality is good but the UI of conflict report needs work. &lt;br /&gt;
# The UI needs to be cleaned up a little. When charts have only one or two bars, the chart can be compressed. The reviewer whose scores deviate from the threshold can be displayed in a different colored bar.&lt;br /&gt;
# Tests need to be refactored.&lt;br /&gt;
# They included their debug code in their pull request. &lt;br /&gt;
# They have included a lot of logic in the views. &lt;br /&gt;
# Shallow tests: one or more of their test expectations only focus on the return value not being `nil`, `empty` or not equal to `0` without testing the `real` value.&lt;br /&gt;
&lt;br /&gt;
== Proposed Solution ==&lt;br /&gt;
&lt;br /&gt;
The previous team implemented new logic to determine if a review is in conflict with another and created a new page to link the instructors to in the email. Because their functionality was good, we will mainly be focused on improving the UI of the conflict reports. Furthermore, there is a lot of logic that lives in the views that can be refactored and moved to controllers. Additionally, there is debug code that can be removed and tests that can be fleshed out.&lt;br /&gt;
&lt;br /&gt;
=== UI Imporvements ===&lt;br /&gt;
&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb&lt;br /&gt;
&lt;br /&gt;
The UI can be improved for the conflict metric to give more information on the conflicted reviews.&lt;br /&gt;
&lt;br /&gt;
=== Logic in Views ===&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb &lt;br /&gt;
&lt;br /&gt;
The logic to determine if answers are within or outside of the tolerance limits can be moved to functions outside of the .erb file.&lt;br /&gt;
&lt;br /&gt;
== UML Activity Diagram ==&lt;br /&gt;
[[File:517 Final Project Student UML.jpg]]&lt;br /&gt;
[[File:517 Final Project Instructor UML.jpg]]&lt;br /&gt;
&lt;br /&gt;
== UI Changes ==&lt;br /&gt;
&lt;br /&gt;
Based on the previous changes from last group, the notification email triggered will send to the instructor whenever two reviews for the same submission differ &amp;quot;significantly&amp;quot; on their scoring (the threshold is specified in the &amp;quot;Notification limit&amp;quot; on the Rubric tab of assignment creation).&lt;br /&gt;
&lt;br /&gt;
[[File:afteremail.JPG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the email notification, the formatting can be improved to make it more readable and clear as to which links relate to what actions and what caused the conflict to trigger.&lt;br /&gt;
&lt;br /&gt;
The previous group of snapshot for the view which the instructor receives&lt;br /&gt;
&lt;br /&gt;
[[File:afterfix.PNG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the 'review for mail check' page, more information can be added to indicate if a review has a conflict. We will add indicators beside each review that have conflicts.&lt;br /&gt;
&lt;br /&gt;
== Test Plan==&lt;br /&gt;
&lt;br /&gt;
=== Manual Test Plan ===&lt;br /&gt;
&lt;br /&gt;
To verify the conflict notification is working correctly, a mock assignment will be created and two reviews will be entered that should trigger a conflict. Successful retrieval of the email and verification of the links included in the email will provide sufficient verification that the changes were successful.&lt;br /&gt;
&lt;br /&gt;
=== File Changes ===&lt;br /&gt;
File: spec/models/answer_spec.rb&lt;br /&gt;
&lt;br /&gt;
Currently, tests only check if the values are not empty. More tests can be written to make sure the actual value is being returned correctly.&lt;br /&gt;
&lt;br /&gt;
File: spec/controllers/reports_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
More tests can be written to ensure correct names and values are written.&lt;br /&gt;
&lt;br /&gt;
== Implemented Solution ==&lt;br /&gt;
&lt;br /&gt;
=== Refactoring ===&lt;br /&gt;
&lt;br /&gt;
Moved following methods from review_mapping_helper.rb to report_formatter_helper.rb&lt;br /&gt;
&lt;br /&gt;
* average_of_round&lt;br /&gt;
* std_of_round&lt;br /&gt;
* review_score_helper_for_team&lt;br /&gt;
* review_score_for_team&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== New Implementation   ===&lt;br /&gt;
&amp;lt;code&amp;gt; #adding base_url from the controller as this method is not accessible from model&lt;br /&gt;
@response.notify_instructor_on_difference(request.base_url) if (@map.is_a? ReviewResponseMap) &amp;amp;&amp;amp; @response.is_submitted &amp;amp;&amp;amp; @response.significant_difference?&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Relevant Links ==&lt;br /&gt;
GitHub - https://github.com/salmonandrew/expertiza &amp;lt;br&amp;gt;&lt;br /&gt;
Pull Request - https://github.com/expertiza/expertiza/pull/1840 &amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Team ==&lt;br /&gt;
'''Mentor: '''Sanket Pai (sgpai2@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
*Yen-An Jou (yjou@ncsu.edu)&lt;br /&gt;
*Xiwen Chen (xchen33@ncsu.edu)&lt;br /&gt;
*Andrew Hirasawa (achirasa@ncsu.edu)&lt;br /&gt;
*Derrick Li (xli56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== References / Previous Implementation ==&lt;br /&gt;
&lt;br /&gt;
*Previous Wikipedia page - [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1865._Conflict_Notification E1865 Conflict Notification Fall 2018]&lt;br /&gt;
&lt;br /&gt;
*Previous Final Video - [https://drive.google.com/drive/folders/1Z8rqRxdmXJYbOZzoptmBLP0kM7Bdul2Q Final Video]&lt;br /&gt;
&lt;br /&gt;
*Previous Pull Request -[https://github.com/expertiza/expertiza/pull/1445 Pull Request 1445]&lt;br /&gt;
&lt;br /&gt;
*Previous Github Repo - [https://github.com/cshinde57/expertiza Github Repo]&lt;br /&gt;
{{reflist}}&lt;/div&gt;</summary>
		<author><name>Xli56</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137104</id>
		<title>CSC/ECE 517 Fall 2020 - E2087. Conflict notification. Improve Search Facility In Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137104"/>
		<updated>2020-11-17T01:02:16Z</updated>

		<summary type="html">&lt;p&gt;Xli56: /* New Implication */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Expertiza includes the functionality of notifying instructors when a conflict occurs in review scores for a submission. Currently, when two reviews for the same submission differ significantly, an email is sent to the instructor of the course, but there is no link to the review that caused the conflict. This improvement will allow the professor to have links to the reviews that caused the conflict and will be formatted better to help the instructor understand the conflict.&lt;br /&gt;
&lt;br /&gt;
=== Issues with previous submission ===&lt;br /&gt;
&lt;br /&gt;
# The functionality is good but the UI of conflict report needs work. &lt;br /&gt;
# The UI needs to be cleaned up a little. When charts have only one or two bars, the chart can be compressed. The reviewer whose scores deviate from the threshold can be displayed in a different colored bar.&lt;br /&gt;
# Tests need to be refactored.&lt;br /&gt;
# They included their debug code in their pull request. &lt;br /&gt;
# They have included a lot of logic in the views. &lt;br /&gt;
# Shallow tests: one or more of their test expectations only focus on the return value not being `nil`, `empty` or not equal to `0` without testing the `real` value.&lt;br /&gt;
&lt;br /&gt;
== Proposed Solution ==&lt;br /&gt;
&lt;br /&gt;
The previous team implemented new logic to determine if a review is in conflict with another and created a new page to link the instructors to in the email. Because their functionality was good, we will mainly be focused on improving the UI of the conflict reports. Furthermore, there is a lot of logic that lives in the views that can be refactored and moved to controllers. Additionally, there is debug code that can be removed and tests that can be fleshed out.&lt;br /&gt;
&lt;br /&gt;
=== UI Imporvements ===&lt;br /&gt;
&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb&lt;br /&gt;
&lt;br /&gt;
The UI can be improved for the conflict metric to give more information on the conflicted reviews.&lt;br /&gt;
&lt;br /&gt;
=== Logic in Views ===&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb &lt;br /&gt;
&lt;br /&gt;
The logic to determine if answers are within or outside of the tolerance limits can be moved to functions outside of the .erb file.&lt;br /&gt;
&lt;br /&gt;
== UML Activity Diagram ==&lt;br /&gt;
[[File:517 Final Project Student UML.jpg]]&lt;br /&gt;
[[File:517 Final Project Instructor UML.jpg]]&lt;br /&gt;
&lt;br /&gt;
== UI Changes ==&lt;br /&gt;
&lt;br /&gt;
Based on the previous changes from last group, the notification email triggered will send to the instructor whenever two reviews for the same submission differ &amp;quot;significantly&amp;quot; on their scoring (the threshold is specified in the &amp;quot;Notification limit&amp;quot; on the Rubric tab of assignment creation).&lt;br /&gt;
&lt;br /&gt;
[[File:afteremail.JPG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the email notification, the formatting can be improved to make it more readable and clear as to which links relate to what actions and what caused the conflict to trigger.&lt;br /&gt;
&lt;br /&gt;
The previous group of snapshot for the view which the instructor receives&lt;br /&gt;
&lt;br /&gt;
[[File:afterfix.PNG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the 'review for mail check' page, more information can be added to indicate if a review has a conflict. We will add indicators beside each review that have conflicts.&lt;br /&gt;
&lt;br /&gt;
== Test Plan==&lt;br /&gt;
&lt;br /&gt;
=== Manual Test Plan ===&lt;br /&gt;
&lt;br /&gt;
To verify the conflict notification is working correctly, a mock assignment will be created and two reviews will be entered that should trigger a conflict. Successful retrieval of the email and verification of the links included in the email will provide sufficient verification that the changes were successful.&lt;br /&gt;
&lt;br /&gt;
=== File Changes ===&lt;br /&gt;
File: spec/models/answer_spec.rb&lt;br /&gt;
&lt;br /&gt;
Currently, tests only check if the values are not empty. More tests can be written to make sure the actual value is being returned correctly.&lt;br /&gt;
&lt;br /&gt;
File: spec/controllers/reports_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
More tests can be written to ensure correct names and values are written.&lt;br /&gt;
&lt;br /&gt;
== Implemented Solution ==&lt;br /&gt;
&lt;br /&gt;
=== Refactoring ===&lt;br /&gt;
&lt;br /&gt;
Moved following methods from review_mapping_helper.rb to report_formatter_helper.rb&lt;br /&gt;
&lt;br /&gt;
* average_of_round&lt;br /&gt;
* std_of_round&lt;br /&gt;
* review_score_helper_for_team&lt;br /&gt;
* review_score_for_team&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== New Implementation   ===&lt;br /&gt;
&lt;br /&gt;
== Relevant Links ==&lt;br /&gt;
GitHub - https://github.com/salmonandrew/expertiza &amp;lt;br&amp;gt;&lt;br /&gt;
Pull Request - https://github.com/expertiza/expertiza/pull/1829 &amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Team ==&lt;br /&gt;
'''Mentor: '''Sanket Pai (sgpai2@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
*Yen-An Jou (yjou@ncsu.edu)&lt;br /&gt;
*Xiwen Chen (xchen33@ncsu.edu)&lt;br /&gt;
*Andrew Hirasawa (achirasa@ncsu.edu)&lt;br /&gt;
*Derrick Li (xli56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== References / Previous Implementation ==&lt;br /&gt;
&lt;br /&gt;
*Previous Wikipedia page - [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1865._Conflict_Notification E1865 Conflict Notification Fall 2018]&lt;br /&gt;
&lt;br /&gt;
*Previous Final Video - [https://drive.google.com/drive/folders/1Z8rqRxdmXJYbOZzoptmBLP0kM7Bdul2Q Final Video]&lt;br /&gt;
&lt;br /&gt;
*Previous Pull Request -[https://github.com/expertiza/expertiza/pull/1445 Pull Request 1445]&lt;br /&gt;
&lt;br /&gt;
*Previous Github Repo - [https://github.com/cshinde57/expertiza Github Repo]&lt;br /&gt;
{{reflist}}&lt;/div&gt;</summary>
		<author><name>Xli56</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137099</id>
		<title>CSC/ECE 517 Fall 2020 - E2087. Conflict notification. Improve Search Facility In Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2087._Conflict_notification._Improve_Search_Facility_In_Expertiza&amp;diff=137099"/>
		<updated>2020-11-17T00:54:27Z</updated>

		<summary type="html">&lt;p&gt;Xli56: /* Implemented Solution */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Expertiza includes the functionality of notifying instructors when a conflict occurs in review scores for a submission. Currently, when two reviews for the same submission differ significantly, an email is sent to the instructor of the course, but there is no link to the review that caused the conflict. This improvement will allow the professor to have links to the reviews that caused the conflict and will be formatted better to help the instructor understand the conflict.&lt;br /&gt;
&lt;br /&gt;
=== Issues with previous submission ===&lt;br /&gt;
&lt;br /&gt;
# The functionality is good but the UI of conflict report needs work. &lt;br /&gt;
# The UI needs to be cleaned up a little. When charts have only one or two bars, the chart can be compressed. The reviewer whose scores deviate from the threshold can be displayed in a different colored bar.&lt;br /&gt;
# Tests need to be refactored.&lt;br /&gt;
# They included their debug code in their pull request. &lt;br /&gt;
# They have included a lot of logic in the views. &lt;br /&gt;
# Shallow tests: one or more of their test expectations only focus on the return value not being `nil`, `empty` or not equal to `0` without testing the `real` value.&lt;br /&gt;
&lt;br /&gt;
== Proposed Solution ==&lt;br /&gt;
&lt;br /&gt;
The previous team implemented new logic to determine if a review is in conflict with another and created a new page to link the instructors to in the email. Because their functionality was good, we will mainly be focused on improving the UI of the conflict reports. Furthermore, there is a lot of logic that lives in the views that can be refactored and moved to controllers. Additionally, there is debug code that can be removed and tests that can be fleshed out.&lt;br /&gt;
&lt;br /&gt;
=== UI Imporvements ===&lt;br /&gt;
&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb&lt;br /&gt;
&lt;br /&gt;
The UI can be improved for the conflict metric to give more information on the conflicted reviews.&lt;br /&gt;
&lt;br /&gt;
=== Logic in Views ===&lt;br /&gt;
File: app/views/reports/_review_conflict_metric.html.erb &lt;br /&gt;
&lt;br /&gt;
The logic to determine if answers are within or outside of the tolerance limits can be moved to functions outside of the .erb file.&lt;br /&gt;
&lt;br /&gt;
== UML Activity Diagram ==&lt;br /&gt;
[[File:517 Final Project Student UML.jpg]]&lt;br /&gt;
[[File:517 Final Project Instructor UML.jpg]]&lt;br /&gt;
&lt;br /&gt;
== UI Changes ==&lt;br /&gt;
&lt;br /&gt;
Based on the previous changes from last group, the notification email triggered will send to the instructor whenever two reviews for the same submission differ &amp;quot;significantly&amp;quot; on their scoring (the threshold is specified in the &amp;quot;Notification limit&amp;quot; on the Rubric tab of assignment creation).&lt;br /&gt;
&lt;br /&gt;
[[File:afteremail.JPG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the email notification, the formatting can be improved to make it more readable and clear as to which links relate to what actions and what caused the conflict to trigger.&lt;br /&gt;
&lt;br /&gt;
The previous group of snapshot for the view which the instructor receives&lt;br /&gt;
&lt;br /&gt;
[[File:afterfix.PNG|1000px]]&lt;br /&gt;
&lt;br /&gt;
On the 'review for mail check' page, more information can be added to indicate if a review has a conflict. We will add indicators beside each review that have conflicts.&lt;br /&gt;
&lt;br /&gt;
== Test Plan==&lt;br /&gt;
&lt;br /&gt;
=== Manual Test Plan ===&lt;br /&gt;
&lt;br /&gt;
To verify the conflict notification is working correctly, a mock assignment will be created and two reviews will be entered that should trigger a conflict. Successful retrieval of the email and verification of the links included in the email will provide sufficient verification that the changes were successful.&lt;br /&gt;
&lt;br /&gt;
=== File Changes ===&lt;br /&gt;
File: spec/models/answer_spec.rb&lt;br /&gt;
&lt;br /&gt;
Currently, tests only check if the values are not empty. More tests can be written to make sure the actual value is being returned correctly.&lt;br /&gt;
&lt;br /&gt;
File: spec/controllers/reports_controller_spec.rb&lt;br /&gt;
&lt;br /&gt;
More tests can be written to ensure correct names and values are written.&lt;br /&gt;
&lt;br /&gt;
== Implemented Solution ==&lt;br /&gt;
&lt;br /&gt;
=== Refactoring ===&lt;br /&gt;
&lt;br /&gt;
Moved following methods from review_mapping_helper.rb to report_formatter_helper.rb&lt;br /&gt;
&lt;br /&gt;
* average_of_round&lt;br /&gt;
* std_of_round&lt;br /&gt;
* review_score_helper_for_team&lt;br /&gt;
* review_score_for_team&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== New Implication  ===&lt;br /&gt;
&lt;br /&gt;
== Relevant Links ==&lt;br /&gt;
GitHub - https://github.com/salmonandrew/expertiza &amp;lt;br&amp;gt;&lt;br /&gt;
Pull Request - https://github.com/expertiza/expertiza/pull/1829 &amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Team ==&lt;br /&gt;
'''Mentor: '''Sanket Pai (sgpai2@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
*Yen-An Jou (yjou@ncsu.edu)&lt;br /&gt;
*Xiwen Chen (xchen33@ncsu.edu)&lt;br /&gt;
*Andrew Hirasawa (achirasa@ncsu.edu)&lt;br /&gt;
*Derrick Li (xli56@ncsu.edu)&lt;br /&gt;
&lt;br /&gt;
== References / Previous Implementation ==&lt;br /&gt;
&lt;br /&gt;
*Previous Wikipedia page - [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1865._Conflict_Notification E1865 Conflict Notification Fall 2018]&lt;br /&gt;
&lt;br /&gt;
*Previous Final Video - [https://drive.google.com/drive/folders/1Z8rqRxdmXJYbOZzoptmBLP0kM7Bdul2Q Final Video]&lt;br /&gt;
&lt;br /&gt;
*Previous Pull Request -[https://github.com/expertiza/expertiza/pull/1445 Pull Request 1445]&lt;br /&gt;
&lt;br /&gt;
*Previous Github Repo - [https://github.com/cshinde57/expertiza Github Repo]&lt;br /&gt;
{{reflist}}&lt;/div&gt;</summary>
		<author><name>Xli56</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2070._Refactor_response_controller.rb&amp;diff=135089</id>
		<title>CSC/ECE 517 Fall 2020 - E2070. Refactor response controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2070._Refactor_response_controller.rb&amp;diff=135089"/>
		<updated>2020-10-14T02:01:15Z</updated>

		<summary type="html">&lt;p&gt;Xli56: /* METHOD: def set_questionnaire_for_new_response */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Project Background ==&lt;br /&gt;
&lt;br /&gt;
A response is the object that is created when someone fills out a review rubric, such as when one writes a review, gives feedback to a reviewer, or fills out a survey.  Responses to the individual rubric items are kept in Answer objects; each Answer object has a response_id to say what Response it is part of.  Since response_controller needs to work with many kinds of responses, its code is pretty general.  It is not the worst controller in the system, but it would be much clearer if its method names were more descriptive of what they do.&lt;br /&gt;
&lt;br /&gt;
=== Project Team Member===&lt;br /&gt;
&lt;br /&gt;
* Chenwei Zhou (czhou6)&lt;br /&gt;
* Tianrui Wang (twang33)&lt;br /&gt;
* Xinran Li (xli56)&lt;br /&gt;
&lt;br /&gt;
=== Goal of this Project===&lt;br /&gt;
This project tries to modify and refactor the response_controller.rb in a more clear way&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
response_controller.rb&lt;br /&gt;
&lt;br /&gt;
response.rb&lt;br /&gt;
&lt;br /&gt;
== Issue ==&lt;br /&gt;
=== Methods need to be fixed ===&lt;br /&gt;
* def assign_instance_vars&lt;br /&gt;
* def scores&lt;br /&gt;
* def new&lt;br /&gt;
* def set_questionnaire&lt;br /&gt;
* def set_questionnaire_for_new_response&lt;br /&gt;
* def show_calibration_results_for_students&lt;br /&gt;
&lt;br /&gt;
=== Recommandation from mentor === &lt;br /&gt;
[https://docs.google.com/document/d/1LCl_4jGFEQSz09c9TK1fVlVmOiGJ38OEVMxAsjAcEec/edit# Project Lists]&lt;br /&gt;
* def assign_instance_vars : This name could be more specific.&lt;br /&gt;
* def scores : This should be a model method (in response.rb)!  It is all calculation. &lt;br /&gt;
* def new : This method contains a complicated condition that determines whether the submission has been updated since the last time it was reviewed.  If it has not, then the reviewer can edit his/her previous review.  If there has been an update, then the reviewer gets a new review form to “update” the review.  It would make sense to have a model method that tests whether there has been a review since the last file or link was submitted.  Then the code here would just call that function.  It would be a lot clearer what the new method is doing.  set_content(new_response = false) also plays a role in this calculation.  Perhaps this method should also be included in the refactoring, for the sake of clarity of the resulting code.&lt;br /&gt;
* def set_questionnaire : Badly named; what kind of questionnaire and why?  The name should be a lot clearer.&lt;br /&gt;
* def set_questionnaire_for_new_response : Badly named, no comments, not at all clear.  The logic is not like set_questionnaire.  Rename, refactor for clarity, and add comments as appropriate.&lt;br /&gt;
* def show_calibration_results_for_student : This method makes about five db accesses.  Can it be broken into 2 methods, with the business logic moved to response.rb?&lt;br /&gt;
&lt;br /&gt;
== Refactor &amp;amp; Code Modification ==&lt;br /&gt;
&lt;br /&gt;
=== METHOD: def assign_instance_vars ===&lt;br /&gt;
We did the following refactor to make this method more clear:&lt;br /&gt;
*After inspection of the code, the instance variable is actually action handles to the views from controller including &amp;quot;new&amp;quot; and &amp;quot;edit&amp;quot;, thus refactor method name to assign_action_parameter would be better to understand.&lt;br /&gt;
[[File:E2070 assign instance.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
=== METHOD: def scores ===&lt;br /&gt;
*After inspection of the code, this method was already defined in other class and is useless in the current class, thus remove it would be a reasonable choice.&lt;br /&gt;
[[File:E2070 Scores.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def set_questionnaire===&lt;br /&gt;
In the method set_content in response_controller.rb, there is one line of code that &amp;quot;new_response ? set_questionnaire_for_new_response : set_questionnaire&amp;quot;. Thus, we can tell the method set_qustionnaire will called when new_response is false, which means that the object was triggered by an existing response. In the method set_questionnaire, the line of code that “@questionnaire = @response.questionnaire_by_answer(answer)”, which is looking up the questionnaire answered by this existing response. Therefore, refactoring the method name to find_quesetionnaire would be better to understand. &lt;br /&gt;
[[File:E2070 set questionnaire.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def set_questionnaire_for_new_response===&lt;br /&gt;
In the method set_content in response_controller.rb, there is one line of code that &amp;quot;new_response ? set_questionnaire_for_new_response : set_questionnaire&amp;quot;. Thus, we can tell the method set_qustionnaire will called when new_response is true, which means that the object was triggered by a new response. In the set_questionnaire_for_new_response method, the &amp;quot;cast&amp;quot; statement informs us that the new questionnaire are created based on the types or Reviewers, such as Review, Metareview, Teammate Review and so on. Therefore, refactoring the set_questionnaire_for_new_response method to create_new_questionnaire would be better to understand. &lt;br /&gt;
[[File:E2070 set questionnaire for new.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def show_calibration_results_for_student ===&lt;br /&gt;
[[File:E2070 calibration controller.png|1200px]]&lt;br /&gt;
[[File:E2070 calibration model.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
====show_calibration page ====&lt;br /&gt;
[[File:E2070 calibration student view.png|900px]]&lt;br /&gt;
&lt;br /&gt;
====Teacher's action to triggle this function ====&lt;br /&gt;
[[File:E2070 calibration edit assignment.png|900px]]&lt;br /&gt;
&lt;br /&gt;
====After calibration function is activated====&lt;br /&gt;
[[File:E2070 expert review.png|900px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def new ===&lt;br /&gt;
[[File:E2070 new.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
====Create new response====&lt;br /&gt;
[[File:E2070 request a new review.png|900px]]&lt;br /&gt;
&lt;br /&gt;
====After NEW action====&lt;br /&gt;
[[File:E2070 new method called to generate new response.png|900px]]&lt;/div&gt;</summary>
		<author><name>Xli56</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2070._Refactor_response_controller.rb&amp;diff=135053</id>
		<title>CSC/ECE 517 Fall 2020 - E2070. Refactor response controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2070._Refactor_response_controller.rb&amp;diff=135053"/>
		<updated>2020-10-14T00:41:11Z</updated>

		<summary type="html">&lt;p&gt;Xli56: /* METHOD: def set_questionnaire Second version */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Project Background ==&lt;br /&gt;
&lt;br /&gt;
A response is the object that is created when someone fills out a review rubric, such as when one writes a review, gives feedback to a reviewer, or fills out a survey.  Responses to the individual rubric items are kept in Answer objects; each Answer object has a response_id to say what Response it is part of.  Since response_controller needs to work with many kinds of responses, its code is pretty general.  It is not the worst controller in the system, but it would be much clearer if its method names were more descriptive of what they do.&lt;br /&gt;
&lt;br /&gt;
=== Project Team Member===&lt;br /&gt;
&lt;br /&gt;
* Chenwei Zhou (czhou6)&lt;br /&gt;
* Tianrui Wang (twang33)&lt;br /&gt;
* Xinran Li (xli56)&lt;br /&gt;
&lt;br /&gt;
=== Goal of this Project===&lt;br /&gt;
This project tries to modify and refactor the response_controller.rb in a more clear way&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
response_controller.rb&lt;br /&gt;
&lt;br /&gt;
response.rb&lt;br /&gt;
&lt;br /&gt;
== Issue ==&lt;br /&gt;
=== Methods need to be fixed ===&lt;br /&gt;
* def assign_instance_vars&lt;br /&gt;
* def scores&lt;br /&gt;
* def new&lt;br /&gt;
* def set_questionnaire&lt;br /&gt;
* def set_questionnaire_for_new_response&lt;br /&gt;
* def show_calibration_results_for_students&lt;br /&gt;
&lt;br /&gt;
=== Recommandation from mentor === &lt;br /&gt;
[https://docs.google.com/document/d/1LCl_4jGFEQSz09c9TK1fVlVmOiGJ38OEVMxAsjAcEec/edit# Project Lists]&lt;br /&gt;
* def assign_instance_vars : This name could be more specific.&lt;br /&gt;
* def scores : This should be a model method (in response.rb)!  It is all calculation. &lt;br /&gt;
* def new : This method contains a complicated condition that determines whether the submission has been updated since the last time it was reviewed.  If it has not, then the reviewer can edit his/her previous review.  If there has been an update, then the reviewer gets a new review form to “update” the review.  It would make sense to have a model method that tests whether there has been a review since the last file or link was submitted.  Then the code here would just call that function.  It would be a lot clearer what the new method is doing.  set_content(new_response = false) also plays a role in this calculation.  Perhaps this method should also be included in the refactoring, for the sake of clarity of the resulting code.&lt;br /&gt;
* def set_questionnaire : Badly named; what kind of questionnaire and why?  The name should be a lot clearer.&lt;br /&gt;
* def set_questionnaire_for_new_response : Badly named, no comments, not at all clear.  The logic is not like set_questionnaire.  Rename, refactor for clarity, and add comments as appropriate.&lt;br /&gt;
* def show_calibration_results_for_student : This method makes about five db accesses.  Can it be broken into 2 methods, with the business logic moved to response.rb?&lt;br /&gt;
&lt;br /&gt;
== Refactor &amp;amp; Code Modification ==&lt;br /&gt;
&lt;br /&gt;
=== METHOD: def assign_instance_vars ===&lt;br /&gt;
We did the following refactor to make this method more clear:&lt;br /&gt;
*After inspection of the code, the instance variable is actually action handles to the views from controller including &amp;quot;new&amp;quot; and &amp;quot;edit&amp;quot;, thus refactor method name to assign_action_parameter would be better to understand.&lt;br /&gt;
[[File:E2070 assign instance.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
=== METHOD: def scores ===&lt;br /&gt;
*After inspection of the code, this method was already defined in other class and is useless in the current class, thus remove it would be a reasonable choice.&lt;br /&gt;
[[File:E2070 Scores.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def set_questionnaire===&lt;br /&gt;
In the method set_content in response_controller.rb, there is one line of code that &amp;quot;new_response ? set_questionnaire_for_new_response : set_questionnaire&amp;quot;. Thus, we can tell the method set_qustionnaire will called when new_response is false, which means that the object was triggered by an existing response. In the method set_questionnaire, the line of code that “@questionnaire = @response.questionnaire_by_answer(answer)”, which is looking up the questionnaire answered by this existing response. Therefore, refactoring the method name to find_quesetionnaire would be better to understand. &lt;br /&gt;
[[File:E2070 set questionnaire.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def set_questionnaire_for_new_response===&lt;br /&gt;
After inspection of the code, the method set_questionnaire_for_new_response is to set a questionnaire for a new response. Thus, refactoring the method name to create_new_quesetionnaire would be better to understand. &lt;br /&gt;
[[File:E2070 set questionnaire for new.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def show_calibration_results_for_student ===&lt;br /&gt;
[[File:E2070 calibration controller.png|1200px]]&lt;br /&gt;
[[File:E2070 calibration model.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
====show_calibration page ====&lt;br /&gt;
[[File:E2070 calibration student view.png|900px]]&lt;br /&gt;
&lt;br /&gt;
====Teacher's action to triggle this function ====&lt;br /&gt;
[[File:E2070 calibration edit assignment.png|900px]]&lt;br /&gt;
&lt;br /&gt;
====After calibration function is activated====&lt;br /&gt;
[[File:E2070 expert review.png|900px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def new ===&lt;br /&gt;
[[File:E2070 new.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
====Create new response====&lt;br /&gt;
[[File:E2070 request a new review.png|900px]]&lt;br /&gt;
&lt;br /&gt;
====After NEW action====&lt;br /&gt;
[[File:E2070 new method called to generate new response.png|900px]]&lt;/div&gt;</summary>
		<author><name>Xli56</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2070._Refactor_response_controller.rb&amp;diff=135038</id>
		<title>CSC/ECE 517 Fall 2020 - E2070. Refactor response controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2070._Refactor_response_controller.rb&amp;diff=135038"/>
		<updated>2020-10-14T00:21:35Z</updated>

		<summary type="html">&lt;p&gt;Xli56: /* METHOD: def set_questionnaire First version */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Project Background ==&lt;br /&gt;
&lt;br /&gt;
A response is the object that is created when someone fills out a review rubric, such as when one writes a review, gives feedback to a reviewer, or fills out a survey.  Responses to the individual rubric items are kept in Answer objects; each Answer object has a response_id to say what Response it is part of.  Since response_controller needs to work with many kinds of responses, its code is pretty general.  It is not the worst controller in the system, but it would be much clearer if its method names were more descriptive of what they do.&lt;br /&gt;
&lt;br /&gt;
=== Project Team Member===&lt;br /&gt;
&lt;br /&gt;
* Chenwei Zhou (czhou6)&lt;br /&gt;
* Tianrui Wang (twang33)&lt;br /&gt;
* Xinran Li (xli56)&lt;br /&gt;
&lt;br /&gt;
=== Goal of this Project===&lt;br /&gt;
This project tries to modify and refactor the response_controller.rb in a more clear way&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
response_controller.rb&lt;br /&gt;
&lt;br /&gt;
response.rb&lt;br /&gt;
&lt;br /&gt;
== Issue ==&lt;br /&gt;
=== Methods need to be fixed ===&lt;br /&gt;
* def assign_instance_vars&lt;br /&gt;
* def scores&lt;br /&gt;
* def new&lt;br /&gt;
* def set_questionnaire&lt;br /&gt;
* def set_questionnaire_for_new_response&lt;br /&gt;
* def show_calibration_results_for_students&lt;br /&gt;
&lt;br /&gt;
=== Recommandation from mentor === &lt;br /&gt;
[https://docs.google.com/document/d/1LCl_4jGFEQSz09c9TK1fVlVmOiGJ38OEVMxAsjAcEec/edit# Project Lists]&lt;br /&gt;
* def assign_instance_vars : This name could be more specific.&lt;br /&gt;
* def scores : This should be a model method (in response.rb)!  It is all calculation. &lt;br /&gt;
* def new : This method contains a complicated condition that determines whether the submission has been updated since the last time it was reviewed.  If it has not, then the reviewer can edit his/her previous review.  If there has been an update, then the reviewer gets a new review form to “update” the review.  It would make sense to have a model method that tests whether there has been a review since the last file or link was submitted.  Then the code here would just call that function.  It would be a lot clearer what the new method is doing.  set_content(new_response = false) also plays a role in this calculation.  Perhaps this method should also be included in the refactoring, for the sake of clarity of the resulting code.&lt;br /&gt;
* def set_questionnaire : Badly named; what kind of questionnaire and why?  The name should be a lot clearer.&lt;br /&gt;
* def set_questionnaire_for_new_response : Badly named, no comments, not at all clear.  The logic is not like set_questionnaire.  Rename, refactor for clarity, and add comments as appropriate.&lt;br /&gt;
* def show_calibration_results_for_student : This method makes about five db accesses.  Can it be broken into 2 methods, with the business logic moved to response.rb?&lt;br /&gt;
&lt;br /&gt;
== Refactor &amp;amp; Code Modification ==&lt;br /&gt;
&lt;br /&gt;
=== METHOD: def assign_instance_vars ===&lt;br /&gt;
We did the following refactor to make this method more clear:&lt;br /&gt;
*After inspection of the code, the instance variable is actually action handles to the views from controller including &amp;quot;new&amp;quot; and &amp;quot;edit&amp;quot;, thus refactor method name to assign_action_parameter would be better to understand.&lt;br /&gt;
[[File:E2070 assign instance.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
=== METHOD: def scores ===&lt;br /&gt;
*After inspection of the code, this method was already defined in other class and is useless in the current class, thus remove it would be a reasonable choice.&lt;br /&gt;
[[File:E2070 Scores.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def set_questionnaire Second version===&lt;br /&gt;
After inspection of the code, the method set_questionnaire is to find the questionnaire for a exist response. Thus, refactoring the method name to find_quesetionnaire would be better to understand. &lt;br /&gt;
[[File:E2070 set questionnaire.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def set_questionnaire_for_new_response===&lt;br /&gt;
After inspection of the code, the method set_questionnaire_for_new_response is to set a questionnaire for a new response. Thus, refactoring the method name to create_new_quesetionnaire would be better to understand. &lt;br /&gt;
[[File:E2070 set questionnaire for new.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def show_calibration_results_for_student ===&lt;br /&gt;
[[File:E2070 calibration controller.png|1200px]]&lt;br /&gt;
[[File:E2070 calibration model.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
====show_calibration page ====&lt;br /&gt;
[[File:E2070 calibration student view.png|900px]]&lt;br /&gt;
&lt;br /&gt;
====Teacher's action to triggle this function ====&lt;br /&gt;
[[File:E2070 calibration edit assignment.png|900px]]&lt;br /&gt;
&lt;br /&gt;
====After calibration function is activated====&lt;br /&gt;
[[File:E2070 expert review.png|900px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def new ===&lt;br /&gt;
[[File:E2070 new.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
====Create new response====&lt;br /&gt;
[[File:E2070 request a new review.png|900px]]&lt;br /&gt;
&lt;br /&gt;
====After NEW action====&lt;br /&gt;
[[File:E2070 new method called to generate new response.png|900px]]&lt;/div&gt;</summary>
		<author><name>Xli56</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2070._Refactor_response_controller.rb&amp;diff=134983</id>
		<title>CSC/ECE 517 Fall 2020 - E2070. Refactor response controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2070._Refactor_response_controller.rb&amp;diff=134983"/>
		<updated>2020-10-13T21:22:51Z</updated>

		<summary type="html">&lt;p&gt;Xli56: /* METHOD: def set_questionnaire_for_new_response */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Project Background ==&lt;br /&gt;
&lt;br /&gt;
A response is the object that is created when someone fills out a review rubric, such as when one writes a review, gives feedback to a reviewer, or fills out a survey.  Responses to the individual rubric items are kept in Answer objects; each Answer object has a response_id to say what Response it is part of.  Since response_controller needs to work with many kinds of responses, its code is pretty general.  It is not the worst controller in the system, but it would be much clearer if its method names were more descriptive of what they do.&lt;br /&gt;
&lt;br /&gt;
=== Project Team Member===&lt;br /&gt;
&lt;br /&gt;
* Chenwei Zhou (czhou6)&lt;br /&gt;
* Tianrui Wang (twang33)&lt;br /&gt;
* Xinran Li (xli56)&lt;br /&gt;
&lt;br /&gt;
=== Goal of this Project===&lt;br /&gt;
This project tries to modify and refactor the response_controller.rb in a more clear way&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
response_controller.rb&lt;br /&gt;
&lt;br /&gt;
response.rb&lt;br /&gt;
&lt;br /&gt;
== Issue ==&lt;br /&gt;
=== Methods need to be fixed ===&lt;br /&gt;
* def assign_instance_vars&lt;br /&gt;
* def scores&lt;br /&gt;
* def new&lt;br /&gt;
* def set_questionnaire&lt;br /&gt;
* def set_questionnaire_for_new_response&lt;br /&gt;
* def show_calibration_results_for_students&lt;br /&gt;
&lt;br /&gt;
=== Recommandation from mentor === &lt;br /&gt;
[https://docs.google.com/document/d/1LCl_4jGFEQSz09c9TK1fVlVmOiGJ38OEVMxAsjAcEec/edit# Project Lists]&lt;br /&gt;
* def assign_instance_vars : This name could be more specific.&lt;br /&gt;
* def scores : This should be a model method (in response.rb)!  It is all calculation. &lt;br /&gt;
* def new : This method contains a complicated condition that determines whether the submission has been updated since the last time it was reviewed.  If it has not, then the reviewer can edit his/her previous review.  If there has been an update, then the reviewer gets a new review form to “update” the review.  It would make sense to have a model method that tests whether there has been a review since the last file or link was submitted.  Then the code here would just call that function.  It would be a lot clearer what the new method is doing.  set_content(new_response = false) also plays a role in this calculation.  Perhaps this method should also be included in the refactoring, for the sake of clarity of the resulting code.&lt;br /&gt;
* def set_questionnaire : Badly named; what kind of questionnaire and why?  The name should be a lot clearer.&lt;br /&gt;
* def set_questionnaire_for_new_response : Badly named, no comments, not at all clear.  The logic is not like set_questionnaire.  Rename, refactor for clarity, and add comments as appropriate.&lt;br /&gt;
* def show_calibration_results_for_student : This method makes about five db accesses.  Can it be broken into 2 methods, with the business logic moved to response.rb?&lt;br /&gt;
&lt;br /&gt;
== Refactor &amp;amp; Code Modification ==&lt;br /&gt;
&lt;br /&gt;
=== METHOD: def assign_instance_vars ===&lt;br /&gt;
We did the following refactor to make this method more clear:&lt;br /&gt;
*After inspection of the code, the instance variable is actually action handles to the views from controller including &amp;quot;new&amp;quot; and &amp;quot;edit&amp;quot;, thus refactor method name to assign_action_parameter would be better to understand.&lt;br /&gt;
[[File:E2070 assign instance.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
=== METHOD: def scores ===&lt;br /&gt;
*After inspection of the code, this method was already defined in other class and is useless in the current class, thus remove it would be a reasonable choice.&lt;br /&gt;
[[File:E2070 Scores.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def set_questionnaire First version===&lt;br /&gt;
After inspection of the code, the method set_questionnaire is to find the questionnaire for a exist response. Thus, refactoring the method name to find_quesetionnaire would be better to understand. &lt;br /&gt;
[[File:E2070 set questionnaire 1.png|1200px]]&lt;br /&gt;
[[File:E2070 set questionnaire 2.png|1200px]]&lt;br /&gt;
[[File:E2070 set questionnaire 3.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def set_questionnaire Second version===&lt;br /&gt;
After inspection of the code, the method set_questionnaire is to find the questionnaire for a exist response. Thus, refactoring the method name to find_quesetionnaire would be better to understand. &lt;br /&gt;
[[File:E2070 set questionnaire.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def set_questionnaire_for_new_response===&lt;br /&gt;
After inspection of the code, the method set_questionnaire_for_new_response is to set a questionnaire for a new response. Thus, refactoring the method name to create_new_quesetionnaire would be better to understand. &lt;br /&gt;
[[File:E2070 set questionnaire for new.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def show_calibration_results_for_student ===&lt;br /&gt;
[[File:E2070 calibration controller.png|1200px]]&lt;br /&gt;
[[File:E2070 calibration model.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
====show_calibration page ====&lt;br /&gt;
[[File:E2070 calibration student view.png|900px]]&lt;br /&gt;
&lt;br /&gt;
====Teacher's action to triggle this function ====&lt;br /&gt;
[[File:E2070 calibration edit assignment.png|900px]]&lt;br /&gt;
&lt;br /&gt;
====After calibration function is activated====&lt;br /&gt;
[[File:E2070 expert review.png|900px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def new ===&lt;br /&gt;
[[File:E2070 new.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
====Create new response====&lt;br /&gt;
[[File:E2070 request a new review.png|900px]]&lt;br /&gt;
&lt;br /&gt;
====After NEW action====&lt;br /&gt;
[[File:E2070 new method called to generate new response.png|900px]]&lt;/div&gt;</summary>
		<author><name>Xli56</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2070._Refactor_response_controller.rb&amp;diff=134982</id>
		<title>CSC/ECE 517 Fall 2020 - E2070. Refactor response controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2070._Refactor_response_controller.rb&amp;diff=134982"/>
		<updated>2020-10-13T21:22:35Z</updated>

		<summary type="html">&lt;p&gt;Xli56: /* METHOD: def set_questionnaire Second version */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Project Background ==&lt;br /&gt;
&lt;br /&gt;
A response is the object that is created when someone fills out a review rubric, such as when one writes a review, gives feedback to a reviewer, or fills out a survey.  Responses to the individual rubric items are kept in Answer objects; each Answer object has a response_id to say what Response it is part of.  Since response_controller needs to work with many kinds of responses, its code is pretty general.  It is not the worst controller in the system, but it would be much clearer if its method names were more descriptive of what they do.&lt;br /&gt;
&lt;br /&gt;
=== Project Team Member===&lt;br /&gt;
&lt;br /&gt;
* Chenwei Zhou (czhou6)&lt;br /&gt;
* Tianrui Wang (twang33)&lt;br /&gt;
* Xinran Li (xli56)&lt;br /&gt;
&lt;br /&gt;
=== Goal of this Project===&lt;br /&gt;
This project tries to modify and refactor the response_controller.rb in a more clear way&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
response_controller.rb&lt;br /&gt;
&lt;br /&gt;
response.rb&lt;br /&gt;
&lt;br /&gt;
== Issue ==&lt;br /&gt;
=== Methods need to be fixed ===&lt;br /&gt;
* def assign_instance_vars&lt;br /&gt;
* def scores&lt;br /&gt;
* def new&lt;br /&gt;
* def set_questionnaire&lt;br /&gt;
* def set_questionnaire_for_new_response&lt;br /&gt;
* def show_calibration_results_for_students&lt;br /&gt;
&lt;br /&gt;
=== Recommandation from mentor === &lt;br /&gt;
[https://docs.google.com/document/d/1LCl_4jGFEQSz09c9TK1fVlVmOiGJ38OEVMxAsjAcEec/edit# Project Lists]&lt;br /&gt;
* def assign_instance_vars : This name could be more specific.&lt;br /&gt;
* def scores : This should be a model method (in response.rb)!  It is all calculation. &lt;br /&gt;
* def new : This method contains a complicated condition that determines whether the submission has been updated since the last time it was reviewed.  If it has not, then the reviewer can edit his/her previous review.  If there has been an update, then the reviewer gets a new review form to “update” the review.  It would make sense to have a model method that tests whether there has been a review since the last file or link was submitted.  Then the code here would just call that function.  It would be a lot clearer what the new method is doing.  set_content(new_response = false) also plays a role in this calculation.  Perhaps this method should also be included in the refactoring, for the sake of clarity of the resulting code.&lt;br /&gt;
* def set_questionnaire : Badly named; what kind of questionnaire and why?  The name should be a lot clearer.&lt;br /&gt;
* def set_questionnaire_for_new_response : Badly named, no comments, not at all clear.  The logic is not like set_questionnaire.  Rename, refactor for clarity, and add comments as appropriate.&lt;br /&gt;
* def show_calibration_results_for_student : This method makes about five db accesses.  Can it be broken into 2 methods, with the business logic moved to response.rb?&lt;br /&gt;
&lt;br /&gt;
== Refactor &amp;amp; Code Modification ==&lt;br /&gt;
&lt;br /&gt;
=== METHOD: def assign_instance_vars ===&lt;br /&gt;
We did the following refactor to make this method more clear:&lt;br /&gt;
*After inspection of the code, the instance variable is actually action handles to the views from controller including &amp;quot;new&amp;quot; and &amp;quot;edit&amp;quot;, thus refactor method name to assign_action_parameter would be better to understand.&lt;br /&gt;
[[File:E2070 assign instance.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
=== METHOD: def scores ===&lt;br /&gt;
*After inspection of the code, this method was already defined in other class and is useless in the current class, thus remove it would be a reasonable choice.&lt;br /&gt;
[[File:E2070 Scores.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def set_questionnaire First version===&lt;br /&gt;
After inspection of the code, the method set_questionnaire is to find the questionnaire for a exist response. Thus, refactoring the method name to find_quesetionnaire would be better to understand. &lt;br /&gt;
[[File:E2070 set questionnaire 1.png|1200px]]&lt;br /&gt;
[[File:E2070 set questionnaire 2.png|1200px]]&lt;br /&gt;
[[File:E2070 set questionnaire 3.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def set_questionnaire Second version===&lt;br /&gt;
After inspection of the code, the method set_questionnaire is to find the questionnaire for a exist response. Thus, refactoring the method name to find_quesetionnaire would be better to understand. &lt;br /&gt;
[[File:E2070 set questionnaire.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def set_questionnaire_for_new_response===&lt;br /&gt;
[[File:E2070 set questionnaire for new.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def show_calibration_results_for_student ===&lt;br /&gt;
[[File:E2070 calibration controller.png|1200px]]&lt;br /&gt;
[[File:E2070 calibration model.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
====show_calibration page ====&lt;br /&gt;
[[File:E2070 calibration student view.png|900px]]&lt;br /&gt;
&lt;br /&gt;
====Teacher's action to triggle this function ====&lt;br /&gt;
[[File:E2070 calibration edit assignment.png|900px]]&lt;br /&gt;
&lt;br /&gt;
====After calibration function is activated====&lt;br /&gt;
[[File:E2070 expert review.png|900px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def new ===&lt;br /&gt;
[[File:E2070 new.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
====Create new response====&lt;br /&gt;
[[File:E2070 request a new review.png|900px]]&lt;br /&gt;
&lt;br /&gt;
====After NEW action====&lt;br /&gt;
[[File:E2070 new method called to generate new response.png|900px]]&lt;/div&gt;</summary>
		<author><name>Xli56</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2070._Refactor_response_controller.rb&amp;diff=134980</id>
		<title>CSC/ECE 517 Fall 2020 - E2070. Refactor response controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2070._Refactor_response_controller.rb&amp;diff=134980"/>
		<updated>2020-10-13T21:22:02Z</updated>

		<summary type="html">&lt;p&gt;Xli56: /* METHOD: def set_questionnaire Second version */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Project Background ==&lt;br /&gt;
&lt;br /&gt;
A response is the object that is created when someone fills out a review rubric, such as when one writes a review, gives feedback to a reviewer, or fills out a survey.  Responses to the individual rubric items are kept in Answer objects; each Answer object has a response_id to say what Response it is part of.  Since response_controller needs to work with many kinds of responses, its code is pretty general.  It is not the worst controller in the system, but it would be much clearer if its method names were more descriptive of what they do.&lt;br /&gt;
&lt;br /&gt;
=== Project Team Member===&lt;br /&gt;
&lt;br /&gt;
* Chenwei Zhou (czhou6)&lt;br /&gt;
* Tianrui Wang (twang33)&lt;br /&gt;
* Xinran Li (xli56)&lt;br /&gt;
&lt;br /&gt;
=== Goal of this Project===&lt;br /&gt;
This project tries to modify and refactor the response_controller.rb in a more clear way&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
response_controller.rb&lt;br /&gt;
&lt;br /&gt;
response.rb&lt;br /&gt;
&lt;br /&gt;
== Issue ==&lt;br /&gt;
=== Methods need to be fixed ===&lt;br /&gt;
* def assign_instance_vars&lt;br /&gt;
* def scores&lt;br /&gt;
* def new&lt;br /&gt;
* def set_questionnaire&lt;br /&gt;
* def set_questionnaire_for_new_response&lt;br /&gt;
* def show_calibration_results_for_students&lt;br /&gt;
&lt;br /&gt;
=== Recommandation from mentor === &lt;br /&gt;
[https://docs.google.com/document/d/1LCl_4jGFEQSz09c9TK1fVlVmOiGJ38OEVMxAsjAcEec/edit# Project Lists]&lt;br /&gt;
* def assign_instance_vars : This name could be more specific.&lt;br /&gt;
* def scores : This should be a model method (in response.rb)!  It is all calculation. &lt;br /&gt;
* def new : This method contains a complicated condition that determines whether the submission has been updated since the last time it was reviewed.  If it has not, then the reviewer can edit his/her previous review.  If there has been an update, then the reviewer gets a new review form to “update” the review.  It would make sense to have a model method that tests whether there has been a review since the last file or link was submitted.  Then the code here would just call that function.  It would be a lot clearer what the new method is doing.  set_content(new_response = false) also plays a role in this calculation.  Perhaps this method should also be included in the refactoring, for the sake of clarity of the resulting code.&lt;br /&gt;
* def set_questionnaire : Badly named; what kind of questionnaire and why?  The name should be a lot clearer.&lt;br /&gt;
* def set_questionnaire_for_new_response : Badly named, no comments, not at all clear.  The logic is not like set_questionnaire.  Rename, refactor for clarity, and add comments as appropriate.&lt;br /&gt;
* def show_calibration_results_for_student : This method makes about five db accesses.  Can it be broken into 2 methods, with the business logic moved to response.rb?&lt;br /&gt;
&lt;br /&gt;
== Refactor &amp;amp; Code Modification ==&lt;br /&gt;
&lt;br /&gt;
=== METHOD: def assign_instance_vars ===&lt;br /&gt;
We did the following refactor to make this method more clear:&lt;br /&gt;
*After inspection of the code, the instance variable is actually action handles to the views from controller including &amp;quot;new&amp;quot; and &amp;quot;edit&amp;quot;, thus refactor method name to assign_action_parameter would be better to understand.&lt;br /&gt;
[[File:E2070 assign instance.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
=== METHOD: def scores ===&lt;br /&gt;
*After inspection of the code, this method was already defined in other class and is useless in the current class, thus remove it would be a reasonable choice.&lt;br /&gt;
[[File:E2070 Scores.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def set_questionnaire First version===&lt;br /&gt;
After inspection of the code, the method set_questionnaire is to find the questionnaire for a exist response. Thus, refactoring the method name to find_quesetionnaire would be better to understand. &lt;br /&gt;
[[File:E2070 set questionnaire 1.png|1200px]]&lt;br /&gt;
[[File:E2070 set questionnaire 2.png|1200px]]&lt;br /&gt;
[[File:E2070 set questionnaire 3.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def set_questionnaire Second version===&lt;br /&gt;
After inspection of the code, the method set_questionnaire_for_new_response is to set a questionnaire for a new response. Thus, refactoring the method name to create_new_quesetionnaire would be better to understand. &lt;br /&gt;
[[File:E2070 set questionnaire.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def set_questionnaire_for_new_response===&lt;br /&gt;
[[File:E2070 set questionnaire for new.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def show_calibration_results_for_student ===&lt;br /&gt;
[[File:E2070 calibration controller.png|1200px]]&lt;br /&gt;
[[File:E2070 calibration model.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
====show_calibration page ====&lt;br /&gt;
[[File:E2070 calibration student view.png|900px]]&lt;br /&gt;
&lt;br /&gt;
====Teacher's action to triggle this function ====&lt;br /&gt;
[[File:E2070 calibration edit assignment.png|900px]]&lt;br /&gt;
&lt;br /&gt;
====After calibration function is activated====&lt;br /&gt;
[[File:E2070 expert review.png|900px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def new ===&lt;br /&gt;
[[File:E2070 new.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
====Create new response====&lt;br /&gt;
[[File:E2070 request a new review.png|900px]]&lt;br /&gt;
&lt;br /&gt;
====After NEW action====&lt;br /&gt;
[[File:E2070 new method called to generate new response.png|900px]]&lt;/div&gt;</summary>
		<author><name>Xli56</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2070._Refactor_response_controller.rb&amp;diff=134978</id>
		<title>CSC/ECE 517 Fall 2020 - E2070. Refactor response controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2070._Refactor_response_controller.rb&amp;diff=134978"/>
		<updated>2020-10-13T21:21:37Z</updated>

		<summary type="html">&lt;p&gt;Xli56: /* METHOD: def set_questionnaire First version */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Project Background ==&lt;br /&gt;
&lt;br /&gt;
A response is the object that is created when someone fills out a review rubric, such as when one writes a review, gives feedback to a reviewer, or fills out a survey.  Responses to the individual rubric items are kept in Answer objects; each Answer object has a response_id to say what Response it is part of.  Since response_controller needs to work with many kinds of responses, its code is pretty general.  It is not the worst controller in the system, but it would be much clearer if its method names were more descriptive of what they do.&lt;br /&gt;
&lt;br /&gt;
=== Project Team Member===&lt;br /&gt;
&lt;br /&gt;
* Chenwei Zhou (czhou6)&lt;br /&gt;
* Tianrui Wang (twang33)&lt;br /&gt;
* Xinran Li (xli56)&lt;br /&gt;
&lt;br /&gt;
=== Goal of this Project===&lt;br /&gt;
This project tries to modify and refactor the response_controller.rb in a more clear way&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
response_controller.rb&lt;br /&gt;
&lt;br /&gt;
response.rb&lt;br /&gt;
&lt;br /&gt;
== Issue ==&lt;br /&gt;
=== Methods need to be fixed ===&lt;br /&gt;
* def assign_instance_vars&lt;br /&gt;
* def scores&lt;br /&gt;
* def new&lt;br /&gt;
* def set_questionnaire&lt;br /&gt;
* def set_questionnaire_for_new_response&lt;br /&gt;
* def show_calibration_results_for_students&lt;br /&gt;
&lt;br /&gt;
=== Recommandation from mentor === &lt;br /&gt;
[https://docs.google.com/document/d/1LCl_4jGFEQSz09c9TK1fVlVmOiGJ38OEVMxAsjAcEec/edit# Project Lists]&lt;br /&gt;
* def assign_instance_vars : This name could be more specific.&lt;br /&gt;
* def scores : This should be a model method (in response.rb)!  It is all calculation. &lt;br /&gt;
* def new : This method contains a complicated condition that determines whether the submission has been updated since the last time it was reviewed.  If it has not, then the reviewer can edit his/her previous review.  If there has been an update, then the reviewer gets a new review form to “update” the review.  It would make sense to have a model method that tests whether there has been a review since the last file or link was submitted.  Then the code here would just call that function.  It would be a lot clearer what the new method is doing.  set_content(new_response = false) also plays a role in this calculation.  Perhaps this method should also be included in the refactoring, for the sake of clarity of the resulting code.&lt;br /&gt;
* def set_questionnaire : Badly named; what kind of questionnaire and why?  The name should be a lot clearer.&lt;br /&gt;
* def set_questionnaire_for_new_response : Badly named, no comments, not at all clear.  The logic is not like set_questionnaire.  Rename, refactor for clarity, and add comments as appropriate.&lt;br /&gt;
* def show_calibration_results_for_student : This method makes about five db accesses.  Can it be broken into 2 methods, with the business logic moved to response.rb?&lt;br /&gt;
&lt;br /&gt;
== Refactor &amp;amp; Code Modification ==&lt;br /&gt;
&lt;br /&gt;
=== METHOD: def assign_instance_vars ===&lt;br /&gt;
We did the following refactor to make this method more clear:&lt;br /&gt;
*After inspection of the code, the instance variable is actually action handles to the views from controller including &amp;quot;new&amp;quot; and &amp;quot;edit&amp;quot;, thus refactor method name to assign_action_parameter would be better to understand.&lt;br /&gt;
[[File:E2070 assign instance.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
=== METHOD: def scores ===&lt;br /&gt;
*After inspection of the code, this method was already defined in other class and is useless in the current class, thus remove it would be a reasonable choice.&lt;br /&gt;
[[File:E2070 Scores.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def set_questionnaire First version===&lt;br /&gt;
After inspection of the code, the method set_questionnaire is to find the questionnaire for a exist response. Thus, refactoring the method name to find_quesetionnaire would be better to understand. &lt;br /&gt;
[[File:E2070 set questionnaire 1.png|1200px]]&lt;br /&gt;
[[File:E2070 set questionnaire 2.png|1200px]]&lt;br /&gt;
[[File:E2070 set questionnaire 3.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def set_questionnaire Second version===&lt;br /&gt;
[[File:E2070 set questionnaire.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def set_questionnaire_for_new_response===&lt;br /&gt;
[[File:E2070 set questionnaire for new.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def show_calibration_results_for_student ===&lt;br /&gt;
[[File:E2070 calibration controller.png|1200px]]&lt;br /&gt;
[[File:E2070 calibration model.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
====show_calibration page ====&lt;br /&gt;
[[File:E2070 calibration student view.png|900px]]&lt;br /&gt;
&lt;br /&gt;
====Teacher's action to triggle this function ====&lt;br /&gt;
[[File:E2070 calibration edit assignment.png|900px]]&lt;br /&gt;
&lt;br /&gt;
====After calibration function is activated====&lt;br /&gt;
[[File:E2070 expert review.png|900px]]&lt;br /&gt;
&lt;br /&gt;
===METHOD: def new ===&lt;br /&gt;
[[File:E2070 new.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
====Create new response====&lt;br /&gt;
[[File:E2070 request a new review.png|900px]]&lt;br /&gt;
&lt;br /&gt;
====After NEW action====&lt;br /&gt;
[[File:E2070 new method called to generate new response.png|900px]]&lt;/div&gt;</summary>
		<author><name>Xli56</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2070._Refactor_response_controller.rb&amp;diff=134778</id>
		<title>CSC/ECE 517 Fall 2020 - E2070. Refactor response controller.rb</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2070._Refactor_response_controller.rb&amp;diff=134778"/>
		<updated>2020-10-13T00:32:49Z</updated>

		<summary type="html">&lt;p&gt;Xli56: /* Project Team Member */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Project Background ==&lt;br /&gt;
&lt;br /&gt;
A response is the object that is created when someone fills out a review rubric, such as when one writes a review, gives feedback to a reviewer, or fills out a survey.  Responses to the individual rubric items are kept in Answer objects; each Answer object has a response_id to say what Response it is part of.  Since response_controller needs to work with many kinds of responses, its code is pretty general.  It is not the worst controller in the system, but it would be much clearer if its method names were more descriptive of what they do.&lt;br /&gt;
&lt;br /&gt;
=== Project Team Member===&lt;br /&gt;
&lt;br /&gt;
Chenwei Zhou (czhou6)&lt;br /&gt;
Tianrui Wang (twang33)&lt;br /&gt;
Xinran Li (xli56)&lt;br /&gt;
&lt;br /&gt;
=== Goal of this Project===&lt;br /&gt;
This project tries to modify and refactor the response_controller.rb in a more clear way&lt;br /&gt;
&lt;br /&gt;
=== Files Involved ===&lt;br /&gt;
&lt;br /&gt;
response_controller.rb&lt;br /&gt;
&lt;br /&gt;
response.rb&lt;br /&gt;
&lt;br /&gt;
== Issue ==&lt;br /&gt;
=== Methods need to be fixed ===&lt;br /&gt;
* def assign_instance_vars&lt;br /&gt;
* def scores&lt;br /&gt;
* def new&lt;br /&gt;
* def set_questionnaire&lt;br /&gt;
* def set_questionnaire_for_new_response&lt;br /&gt;
* def show_calibration_results_for_students&lt;br /&gt;
&lt;br /&gt;
=== Recommandation from mentor === &lt;br /&gt;
[https://docs.google.com/document/d/1LCl_4jGFEQSz09c9TK1fVlVmOiGJ38OEVMxAsjAcEec/edit# Project Lists]&lt;br /&gt;
* def assign_instance_vars : This name could be more specific.&lt;br /&gt;
* def scores : This should be a model method (in response.rb)!  It is all calculation. &lt;br /&gt;
* def new : This method contains a complicated condition that determines whether the submission has been updated since the last time it was reviewed.  If it has not, then the reviewer can edit his/her previous review.  If there has been an update, then the reviewer gets a new review form to “update” the review.  It would make sense to have a model method that tests whether there has been a review since the last file or link was submitted.  Then the code here would just call that function.  It would be a lot clearer what the new method is doing.  set_content(new_response = false) also plays a role in this calculation.  Perhaps this method should also be included in the refactoring, for the sake of clarity of the resulting code.&lt;br /&gt;
* def set_questionnaire : Badly named; what kind of questionnaire and why?  The name should be a lot clearer.&lt;br /&gt;
* def set_questionnaire_for_new_response : Badly named, no comments, not at all clear.  The logic is not like set_questionnaire.  Rename, refactor for clarity, and add comments as appropriate.&lt;br /&gt;
* def show_calibration_results_for_student : This method makes about five db accesses.  Can it be broken into 2 methods, with the business logic moved to response.rb?&lt;br /&gt;
&lt;br /&gt;
== Refactor &amp;amp; Code Modification ==&lt;br /&gt;
&lt;br /&gt;
=== def assign_instance_vars ===&lt;br /&gt;
We did the following refactor to make this method more clear &lt;br /&gt;
[[File:E2070 assign instance.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
=== def scores ===&lt;br /&gt;
[[File:E2070 Scores.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
=== def set_questionnaire ===&lt;br /&gt;
[[File:E2070 set questionnaire 1.png|1200px]]&lt;br /&gt;
[[File:E2070 set questionnaire 2.png|1200px]]&lt;br /&gt;
[[File:E2070 set questionnaire 3.png|1200px]]&lt;br /&gt;
&lt;br /&gt;
=== def show_calibration_results_for_student ===&lt;br /&gt;
[[File:E2070 calibration controller.png|1200px]]&lt;br /&gt;
[[File:E2070 calibration model.png|1200px]]&lt;/div&gt;</summary>
		<author><name>Xli56</name></author>
	</entry>
</feed>