Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2016/E1705. Tracking the time students look at the others' submissions

2016-11-14T23:52:29Z

Rbhatt: /* Steps to follow for all external links (Github, YouTube etc) */

=='''Introduction'''==
==='''Purpose'''===
Expertiza provides the functionality of peer reviews. The best advantage of peer review for the students is that it allows students to learn from each other work.
#It provides a dual benefit for both the reviewer and the writer as they are introduced to a different set of eyes on the code
#It might expose edge cases not previously thought of
#It helps instructors review a project faster
#It emphasizes the importance of writing in such a way that it's easy for a third person to read and understand
In order to assess and analyze quality of reviews, we want to be able to track the time that students spend observing the other's work. Unfortunately, most peer assessment systems do not manage the content of students’ submission within the systems. They usually allow the authors submit external links to the submission, which makes it difficult for the system to track the time that the reviewers spend on the submissions. To assess and improve review qualities, the purpose of the project is to be able to successfully track the time that each student spends on peer reviewing the work.

==='''What needs to be done'''===
#Design and implement a solution that handles the use case, where students’ submissions are hosted on an external website e.g. GitHub and Youtube use cases
#Modify the reviewer interface in expertiza to accommodate your solution e.g., change the link that opens submitted files in views/response/_submitted_files.html.erb so that when the user clicks on the link, it opens a popup window that shows the submission, record time when it opens and closes
#Design a database schema for logging the time a reviewer spend on a submission
#Modify Review report (views/review_mapping/_review_report.html.erb) to show the time spent on each submission

=='''Approach and Implementation'''==
==='''Types of submissions'''===

Based on each submission type, we need to handle the tracking functionalities differently. Generally, the submission links can be one of the following:
#GitHub project/repository link , GitHub Pull requests link or Deployment link
#Youtube videos
#Wikipages
#Text document/doc/pdf/ppt
#Images - png/jpg
#Downloadable contents

==='''Steps to follow for all external links (Github, YouTube etc)'''===
On clicking a submitted link available in '''submitted_content/submitted_files.html.erb''', a new window will pop-up that will keep track of the time spent on that new window. This can be a link to any of the above-mentioned submissions. 
Our solution is to embed the submissions (done on an external website) within the peer assessment system itself using e.g., '''IFrame''' or '''Embed''' tag.
We shall include two new javascript files - '''TimeMe.js''' and '''IfVisible.js''' to keep track of open submission links and time spent viewing them. The following are the steps that will be followed to keep track of the time:
#Start the time when a user clicks on the submitted link (a new window pops-up)
#We'll pause the time in the following cases:
##User idle for more than 30sec
##User switched tabs
##User minimized the window
#Resume time when:
##User switches back to this window
##User performs some activity after being idle
#Time is saved into the database when the user saves, submits review or closes the popped-up window
##If the corresponding entry already exists, the value of the time column is updated otherwise it is created 
'''Behaviour Diagram''' : 
[[File:Flow.JPG|center]]
 
Instructor can now view the times taken for reviewers by reviewer in the Review report summary. This report is rendered by partial '''review_mapping/_review_report.html.erb'''. We shall modify this view to record the times spent by the reviewer per review round for each assignment. For example - 15.32/12.67 indicates that reviewer spent 15.32 minutes on round 1 review and 12.67 minutes on round 2 review.
 
'''Modified View''' : 
review_mapping/_review_report.html.erb will be modified to show the time spent in reviewing a submission. For example, the view below shows a sample modification of the view to depict the time taken in different rounds (separated by '/').[[File:ReviewReport1.png|center]] 

==='''Edge cases'''===

Edge cases that need to be handled :

#What happens when the user refreshes the window : It will set the timer back to 0 and the time spent on that page will be reset
#What happens when the user downloads the submission: If the user downloads any solution and then opens it in his/her local machine, then the time spent on that can't be tracked

==='''Database Design'''===
The following table review_submission_timing will be created to implement a solution for this project: 

[[File:Database table review submission timing.png]]

==='''Files to be modified/added'''===
#student_review/list.html.erb
#review_mapping/_review_report.html.erb
#review_mapping_helper.rb (method- get_data_for_review_report)
#Additionally, we will create a new model class corresponding to new database table
#TimeMe.js and IfVisible.js for handling timing counter

==='''Test Plan'''===
'''Functional Testing using RSpec:'''
 
To test if the time spent by the reviewer on the submitted links shows up in the response_report in Instructor View. 
# Login as a reviewer, for example (student5930). Click on the submitted links to start reviewing. Once review is done, the time spent is recorded in the background and saved in our database
# Login as an instructor. Click on assignments tab. Click on 'View Review Report' under actions for the particular assignment. In the view rendered we expect the new content of time spent by the reviewers to be visible
 
'''Manual Testing for Verification:'''
#When user clicks on a submitted link, it opens up in a new window.
#To verify if the time displayed in the response_report view matches with the actual time spent by the reviewer for all reviews.

File:Flow diagram.PNG

2016-11-14T23:49:11Z

Rbhatt:

CSC/ECE 517 Fall 2016/E1705. Tracking the time students look at the others' submissions

2016-11-14T23:46:00Z

Rbhatt: /* changed the flow diagram*/

=='''Introduction'''==
==='''Purpose'''===
Expertiza provides the functionality of peer reviews. The best advantage of peer review for the students is that it allows students to learn from each other work.
#It provides a dual benefit for both the reviewer and the writer as they are introduced to a different set of eyes on the code
#It might expose edge cases not previously thought of
#It helps instructors review a project faster
#It emphasizes the importance of writing in such a way that it's easy for a third person to read and understand
In order to assess and analyze quality of reviews, we want to be able to track the time that students spend observing the other's work. Unfortunately, most peer assessment systems do not manage the content of students’ submission within the systems. They usually allow the authors submit external links to the submission, which makes it difficult for the system to track the time that the reviewers spend on the submissions. To assess and improve review qualities, the purpose of the project is to be able to successfully track the time that each student spends on peer reviewing the work.

==='''What needs to be done'''===
#Design and implement a solution that handles the use case, where students’ submissions are hosted on an external website e.g. GitHub and Youtube use cases
#Modify the reviewer interface in expertiza to accommodate your solution e.g., change the link that opens submitted files in views/response/_submitted_files.html.erb so that when the user clicks on the link, it opens a popup window that shows the submission, record time when it opens and closes
#Design a database schema for logging the time a reviewer spend on a submission
#Modify Review report (views/review_mapping/_review_report.html.erb) to show the time spent on each submission

=='''Approach and Implementation'''==
==='''Types of submissions'''===

Based on each submission type, we need to handle the tracking functionalities differently. Generally, the submission links can be one of the following:
#GitHub project/repository link , GitHub Pull requests link or Deployment link
#Youtube videos
#Wikipages
#Text document/doc/pdf/ppt
#Images - png/jpg
#Downloadable contents

==='''Steps to follow for all external links (Github, YouTube etc)'''===
On clicking a submitted link available in '''submitted_content/submitted_files.html.erb''', a new window will pop-up that will keep track of the time spent on that new window. This can be a link to any of the above-mentioned submissions. 
Our solution is to embed the submissions (done on an external website) within the peer assessment system itself using e.g., '''IFrame''' or '''Embed''' tag.
We shall include two new javascript files - '''TimeMe.js''' and '''IfVisible.js''' to keep track of open submission links and time spent viewing them. The following are the steps that will be followed to keep track of the time:
#Start the time when a user clicks on the submitted link (a new window pops-up)
#We'll pause the time in the following cases:
##User idle for more than 30sec
##User switched tabs
##User minimized the window
#Resume time when:
##User switches back to this window
##User performs some activity after being idle
#Time is saved into the database when the user saves, submits review or closes the popped-up window
##If the corresponding entry already exists, the value of the time column is updated otherwise it is created 
'''Behaviour Diagram''' : 
[[File:Flow.jpg|center]]
 
Instructor can now view the times taken for reviewers by reviewer in the Review report summary. This report is rendered by partial '''review_mapping/_review_report.html.erb'''. We shall modify this view to record the times spent by the reviewer per review round for each assignment. For example - 15.32/12.67 indicates that reviewer spent 15.32 minutes on round 1 review and 12.67 minutes on round 2 review.
 
'''Modified View''' : 
review_mapping/_review_report.html.erb will be modified to show the time spent in reviewing a submission. For example, the view below shows a sample modification of the view to depict the time taken in different rounds (separated by '/').[[File:ReviewReport1.png|center]] 

==='''Edge cases'''===

Edge cases that need to be handled :

#What happens when the user refreshes the window : It will set the timer back to 0 and the time spent on that page will be reset
#What happens when the user downloads the submission: If the user downloads any solution and then opens it in his/her local machine, then the time spent on that can't be tracked

==='''Database Design'''===
The following table review_submission_timing will be created to implement a solution for this project: 

[[File:Database table review submission timing.png]]

==='''Files to be modified/added'''===
#student_review/list.html.erb
#review_mapping/_review_report.html.erb
#review_mapping_helper.rb (method- get_data_for_review_report)
#Additionally, we will create a new model class corresponding to new database table
#TimeMe.js and IfVisible.js for handling timing counter

==='''Test Plan'''===
'''Functional Testing using RSpec:'''
 
To test if the time spent by the reviewer on the submitted links shows up in the response_report in Instructor View. 
# Login as a reviewer, for example (student5930). Click on the submitted links to start reviewing. Once review is done, the time spent is recorded in the background and saved in our database
# Login as an instructor. Click on assignments tab. Click on 'View Review Report' under actions for the particular assignment. In the view rendered we expect the new content of time spent by the reviewers to be visible
 
'''Manual Testing for Verification:'''
#When user clicks on a submitted link, it opens up in a new window.
#To verify if the time displayed in the response_report view matches with the actual time spent by the reviewer for all reviews.

File:Flow.JPG

2016-11-14T23:45:05Z

Rbhatt: Flow diagram updated

Flow diagram updated

CSC/ECE 517 Fall 2016/E1705. Tracking the time students look at the others' submissions

2016-11-14T23:21:00Z

Rbhatt: /*Changed the flow diagram */

=='''Introduction'''==
==='''Purpose'''===
Expertiza provides the functionality of peer reviews. The best advantage of peer review for the students is that it allows students to learn from each other work.
#It provides a dual benefit for both the reviewer and the writer as they are introduced to a different set of eyes on the code
#It might expose edge cases not previously thought of
#It helps instructors review a project faster
#It emphasizes the importance of writing in such a way that it's easy for a third person to read and understand
In order to assess and analyze quality of reviews, we want to be able to track the time that students spend observing the other's work. Unfortunately, most peer assessment systems do not manage the content of students’ submission within the systems. They usually allow the authors submit external links to the submission, which makes it difficult for the system to track the time that the reviewers spend on the submissions. To assess and improve review qualities, the purpose of the project is to be able to successfully track the time that each student spends on peer reviewing the work.

==='''What needs to be done'''===
#Design and implement a solution that handles the use case, where students’ submissions are hosted on an external website e.g. GitHub and Youtube use cases
#Modify the reviewer interface in expertiza to accommodate your solution e.g., change the link that opens submitted files in views/response/_submitted_files.html.erb so that when the user clicks on the link, it opens a popup window that shows the submission, record time when it opens and closes
#Design a database schema for logging the time a reviewer spend on a submission
#Modify Review report (views/review_mapping/_review_report.html.erb) to show the time spent on each submission

=='''Approach and Implementation'''==
==='''Types of submissions'''===

Based on each submission type, we need to handle the tracking functionalities differently. Generally, the submission links can be one of the following:
#GitHub project/repository link , GitHub Pull requests link or Deployment link
#Youtube videos
#Wikipages
#Text document/doc/pdf/ppt
#Images - png/jpg
#Downloadable contents

==='''Steps to follow for all external links (Github, YouTube etc)'''===
On clicking a submitted link available in '''submitted_content/submitted_files.html.erb''', a new window will pop-up that will keep track of the time spent on that new window. This can be a link to any of the above-mentioned submissions. 
Our solution is to embed the submissions (done on an external website) within the peer assessment system itself using e.g., '''IFrame''' or '''Embed''' tag.
We shall include two new javascript files - '''TimeMe.js''' and '''IfVisible.js''' to keep track of open submission links and time spent viewing them. The following are the steps that will be followed to keep track of the time:
#Start the time when a user clicks on the submitted link (a new window pops-up)
#We'll pause the time in the following cases:
##User idle for more than 30sec
##User switched tabs
##User minimized the window
#Resume time when:
##User switches back to this window
##User performs some activity after being idle
#Time is saved into the database when the user saves, submits review or closes the popped-up window
##If the corresponding entry already exists, the value of the time column is updated otherwise it is created 
'''Behaviour Diagram''' : 
[[File:Flow.png|center]]
 
Instructor can now view the times taken for reviewers by reviewer in the Review report summary. This report is rendered by partial '''review_mapping/_review_report.html.erb'''. We shall modify this view to record the times spent by the reviewer per review round for each assignment. For example - 15.32/12.67 indicates that reviewer spent 15.32 minutes on round 1 review and 12.67 minutes on round 2 review.
 
'''Modified View''' : [[File:ReviewReport1.png|center]] 

==='''Edge cases'''===

Edge cases that need to be handled :

#What happens when the user refreshes the window : It will set the timer back to 0 and the time spent on that page will be reset
#What happens when the user downloads the submission: If the user downloads any solution and then opens it in his/her local machine, then the time spent on that can't be tracked

==='''Database Design'''===
The following table review_submission_timing will be created to implement a solution for this project: 

[[File:Database table review submission timing.png]]

==='''Files to be modified/added'''===
#submitted_content/submitted_files.html.erb
#review_mapping/_review_report.html.erb
#review_mapping_helper.rb (method- get_data_for_review_report)
#Additionally, we will create a new model class corresponding to new database table
#TimeMe.js and IfVisible.js for handling timing counter

==='''Test Plan'''===
'''Functional Testing using RSpec:'''
 
To test if the time spent by the reviewer on the submitted links shows up in the response_report in Instructor View. 
# Login as a reviewer, for example (student5930). Click on the submitted links to start reviewing. Once review is done, the time spent is recorded in the background and saved in our database
# Login as an instructor. Click on assignments tab. Click on 'View Review Report' under actions for the particular assignment. In the view rendered we expect the new content of time spent by the reviewers to be visible
 
'''Manual Testing for Verification:'''
#When user clicks on a submitted link, it opens up in a new window.
#To verify if the time displayed in the response_report view matches with the actual time spent by the reviewer for all reviews.

File:Flow.png

2016-11-14T23:20:12Z

Rbhatt: uploaded a new version of "File:Flow.png"

CSC/ECE 517 Fall 2016/E1705. Tracking the time students look at the others' submissions

2016-11-09T01:34:35Z

Rbhatt: /* Edge cases */

=='''Introduction'''==
==='''Purpose'''===
Expertiza provides the functionality of peer reviews. The best advantage of peer review for the students is that it allows them to learn from each other work. In order to help them to do this, we have to be able to track the time that students spend observing the other's work. Unfortunately, most peer assessment systems do not manage the content of students’ submission within the systems. They usually allow the authors submit external links to the submission, which makes it difficult for the system to track the time that the reviewers spend on the submissions. The purpose of the project is to be able to successfully track the time that each student spends on peer reviewing the work.

==='''What needs to be done'''===
#Design a database schema for logging the time a reviewer spend on a submission
#Design and implement a solution that handles the use case, where students’ submissions are hosted on an external website e.g.,
#Modify the reviewer interface in expertiza to accommodate your solution e.g., change the link that opens submitted files in views/response/_submitted_files.html.erb so that when the user clicks on the link, it opens a popup window that shows the submission, record time when it opens and closes.
#Design and implement a solution that handles GitHub and Youtube use cases
#Modify Review report (views/review_mapping/_review_report.html.erb) to show the time spent on each submission

=='''Approach'''==
==='''Types of submissions'''===

Based on each submission type, we need to handle the tracking functionalities differently. Generally, the submission links can be one of the following:
#GitHub project/repository link , GitHub Pull requests link or Deployment link
#Youtube videos
#Wikipages
#Text document/doc/pdf/ppt
#Images - png/jpg
#Downloadable contents

==='''Steps'''===
On clicking a submitted link, a new window will pop-up that will keep track of the time spent on that new window. This can be a link to any of the above-mentioned submissions. Another approach of using an iframe, as mentioned in the design documents, was thought of but the non-user-friendly appearance of having to scroll through it in all directions to view the page properly was the primary reason for dropping it. The following are the steps that will be followed to keep track of the time:
#Start the time when a user clicks on the submitted link (a new window pops-up)
#We'll pause the time in the following cases:
##User idle for more than 30sec
##User switched tabs
##User minimized the window
#Resume time when:
##User switches back to this window
##User performs some activity after being idle
#Stop the time when the user closes the window or submits

==='''Edge cases'''===

Edge cases that need to be handled :

#What happens when the user refreshes the window : It will set the timer back to 0 and the time spent on that page will be reset.
#What happens when the user downloads the submission: If the user downloads any solution and then opens it in his/her local machine, then the time spent on that can't be tracked.

CSC/ECE 517 Fall 2016/E1705. Tracking the time students look at the others' submissions

2016-11-09T01:34:06Z

Rbhatt: /* Edge cases */

=='''Introduction'''==
==='''Purpose'''===
Expertiza provides the functionality of peer reviews. The best advantage of peer review for the students is that it allows them to learn from each other work. In order to help them to do this, we have to be able to track the time that students spend observing the other's work. Unfortunately, most peer assessment systems do not manage the content of students’ submission within the systems. They usually allow the authors submit external links to the submission, which makes it difficult for the system to track the time that the reviewers spend on the submissions. The purpose of the project is to be able to successfully track the time that each student spends on peer reviewing the work.

==='''What needs to be done'''===
#Design a database schema for logging the time a reviewer spend on a submission
#Design and implement a solution that handles the use case, where students’ submissions are hosted on an external website e.g.,
#Modify the reviewer interface in expertiza to accommodate your solution e.g., change the link that opens submitted files in views/response/_submitted_files.html.erb so that when the user clicks on the link, it opens a popup window that shows the submission, record time when it opens and closes.
#Design and implement a solution that handles GitHub and Youtube use cases
#Modify Review report (views/review_mapping/_review_report.html.erb) to show the time spent on each submission

=='''Approach'''==
==='''Types of submissions'''===

Based on each submission type, we need to handle the tracking functionalities differently. Generally, the submission links can be one of the following:
#GitHub project/repository link , GitHub Pull requests link or Deployment link
#Youtube videos
#Wikipages
#Text document/doc/pdf/ppt
#Images - png/jpg
#Downloadable contents

==='''Steps'''===
On clicking a submitted link, a new window will pop-up that will keep track of the time spent on that new window. This can be a link to any of the above-mentioned submissions. Another approach of using an iframe, as mentioned in the design documents, was thought of but the non-user-friendly appearance of having to scroll through it in all directions to view the page properly was the primary reason for dropping it. The following are the steps that will be followed to keep track of the time:
#Start the time when a user clicks on the submitted link (a new window pops-up)
#We'll pause the time in the following cases:
##User idle for more than 30sec
##User switched tabs
##User minimized the window
#Resume time when:
##User switches back to this window
##User performs some activity after being idle
#Stop the time when the user closes the window or submits

==='''Edge cases'''===

Some of the edge cases that needs to be handled :

#What happens when the user refreshes the window : It will set the timer back to 0 and the time spent on that page will be reset.
#What happens when the user downloads the submission: If the user downloads any solution and then opens it in his/her local machine, then the time spent on that can't be tracked.

CSC/ECE 517 Fall 2016/E1705. Tracking the time students look at the others' submissions

2016-11-09T01:33:35Z

Rbhatt: /* Edge cases */

=='''Introduction'''==
==='''Purpose'''===
Expertiza provides the functionality of peer reviews. The best advantage of peer review for the students is that it allows them to learn from each other work. In order to help them to do this, we have to be able to track the time that students spend observing the other's work. Unfortunately, most peer assessment systems do not manage the content of students’ submission within the systems. They usually allow the authors submit external links to the submission, which makes it difficult for the system to track the time that the reviewers spend on the submissions. The purpose of the project is to be able to successfully track the time that each student spends on peer reviewing the work.

==='''What needs to be done'''===
#Design a database schema for logging the time a reviewer spend on a submission
#Design and implement a solution that handles the use case, where students’ submissions are hosted on an external website e.g.,
#Modify the reviewer interface in expertiza to accommodate your solution e.g., change the link that opens submitted files in views/response/_submitted_files.html.erb so that when the user clicks on the link, it opens a popup window that shows the submission, record time when it opens and closes.
#Design and implement a solution that handles GitHub and Youtube use cases
#Modify Review report (views/review_mapping/_review_report.html.erb) to show the time spent on each submission

=='''Approach'''==
==='''Types of submissions'''===

Based on each submission type, we need to handle the tracking functionalities differently. Generally, the submission links can be one of the following:
#GitHub project/repository link , GitHub Pull requests link or Deployment link
#Youtube videos
#Wikipages
#Text document/doc/pdf/ppt
#Images - png/jpg
#Downloadable contents

==='''Steps'''===
On clicking a submitted link, a new window will pop-up that will keep track of the time spent on that new window. This can be a link to any of the above-mentioned submissions. Another approach of using an iframe, as mentioned in the design documents, was thought of but the non-user-friendly appearance of having to scroll through it in all directions to view the page properly was the primary reason for dropping it. The following are the steps that will be followed to keep track of the time:
#Start the time when a user clicks on the submitted link (a new window pops-up)
#We'll pause the time in the following cases:
##User idle for more than 30sec
##User switched tabs
##User minimized the window
#Resume time when:
##User switches back to this window
##User performs some activity after being idle
#Stop the time when the user closes the window or submits

==='''Edge cases'''===

Some of the edge cases that needs to be handled :

#What happens when the user refreshes the window : It will set the timer back to 0 and the time spent on that page will be reset.

#What happens when the user downloads the submission: If the user downloads any solution and then opens it in his/her local machine, then the time spent on that can't be tracked.

CSC/ECE 517 Fall 2016/E1705. Tracking the time students look at the others' submissions

2016-11-09T00:41:47Z

Rbhatt: /* Types of submissions */

CSC/ECE 517 Fall 2016/E1705. Tracking the time students look at the others' submissions

2016-11-09T00:41:03Z

Rbhatt: /* Types of submissions */

File:Self review 1.png

2016-10-28T20:44:11Z

Rbhatt:

File:Saving 1.png

2016-10-28T20:43:54Z

Rbhatt:

File:Self review.png

2016-10-28T20:42:04Z

Rbhatt: uploaded a new version of "File:Self review.png": self-review.png -resized

Changes in _self_review partial

File:Saving.png

2016-10-28T20:41:22Z

Rbhatt: uploaded a new version of "File:Saving.png": Saving file- resized

changes in saving method

CSC/ECE 517 Fall 2016/oss E1639

2016-10-28T16:11:14Z

Rbhatt: added file names

This wiki page describes changes made under E1639 OSS project assignment for Fall 2016, CSC/ECE 517.

== Expertiza Background==

Expertiza is a web application for educational purposes. It is an open source project based on Ruby on Rails framework. Expertiza has been created and maintained by faculty and students of NCSU. It helps teachers set up assignments for students who can then make submissions. Students can also review work of other students and give feedback to help incorporate improvements.

== Project Description ==

The following OSS project deals mainly with the ResponseController. The goal of this project is make the code more readable, maintainable and to improve elegance of the code. We would like ResponseController to adhere to the DRY principle.
It focuses on refactoring some of the more complex methods and removing some redundant code. At present, ResponseController has methods that would better be located in other controllers. The project relocates such methods to its appropriate Controller class.

== Files modified ==

Following files were mainly modified for this project namely: 
1. response_controller.rb 
2. response_controller_spec.rb 
3. review_mapping_controller.rb 
4. review_mapping_controller_spec.rb 
5. routes.rb 
6. _reviews.html.erb 
7. _scores_submitted_work.html.erb 
8. _self_review.html.erb

== ResponseController ==

Response controller manages the responses entered by users. When a user fills out any kind of rubric (review rubrics,author-feedback rubrics,teammate-review rubrics,quizzes,surveys), a response is generated. Responses come in different versions. Any time an author revises his/her work, and the reviewer reviews it again, a separate Response object is generated.Each Response object points to a particular ResponseMap, which provides details about reviewer, reviewee and reviewed entity.

== What needs to be done ==
1) Refactor the update method which is too long and hard to read. 
2) Refactor the saving method to improve the case handling of selfReviewResponseMap 
3) Move new_feedback method from ResponseController to ReviewMappingController - ResponseController should only handle one kind of object 
4) Modified functional tests for new_feedback method 
5) Added functional test for update_method of response controller 

== Solutions Implemented and Delivered ==

==='''Refactor the update method'''===

Update method is called when any kind of response is edited by the user. This method was very long and unreadable. It was checking the type of @map and round parameter to find out questionnaire using long if..elseif..else ladder, which did not look neat and elegant. There was a helper method 'set_questionnaire' which was being called indirectly by the edit method for retrieving the questionnaire.We called the same function. The intuition behind using this same method was that if it is an update, user is not filling a new rubric and the response object should be available.We can find the questionnaire from the question_id in answers.Hence, in this way the if-else block was eliminated by calling the already available function.
Similarly, there were lines of code,which were creating score if not found or updating if an entry exists. The function 'create_answers' does exactly the same. Abiding by the DRY principle, we called this function which made the update method look concise and simplified. 

==='''Refactor the saving method'''===

Saving method is called to save the response when a user edits any particular response or creates one. It was assigning params[:returs] to 'selfview' if the @map type is selfReponseMap. This params[:return] value was then further used in redirection method to handle the selfReviewResponseMap separately. We removed the assignment params[:return]= "selfreview" from save method. Rather we are directly passing the :return parameter value from edit and new methods of _self_review.html.erb, a view of SubmittedContent controller which handles the selfReview functionality. 
 
app -> controllers -> respose_controller.rb -> def saving 
[[File:saving.png]]

app -> views -> submitted_content -> _self_review.html.erb 
[[File:_self_review.png]]

==='''Move new_feedback method from ResponseController to ReviewMappingController'''===

new_feedback method is called when a user provides author feedback for any review. It was defined in the ResponseController earlier which was rather suspect. We moved the method to ReviewMappingController since ResponseController should only handle Response object, while new_feedback is dealing with FeedbackResponseMap object. 

[[File:Response_controller_rb.png]]

 
[[File:Review mapping controller.png]]

==='''Modified functional tests for new_feedback method'''===

We modified the test cases to accommodate changes of the new_feedback method and created new rspec file review_mapping_controller_rspec.rb 
Also added new test case for update method to test if it located the requested response.

CSC/ECE 517 Fall 2016/oss E1639

2016-10-28T16:08:20Z

Rbhatt: /* Added screenshots */

This wiki page describes changes made under E1639 OSS project assignment for Fall 2016, CSC/ECE 517.

== Expertiza Background==

Expertiza is a web application for educational purposes. It is an open source project based on Ruby on Rails framework. Expertiza has been created and maintained by faculty and students of NCSU. It helps teachers set up assignments for students who can then make submissions. Students can also review work of other students and give feedback to help incorporate improvements.

== Project Description ==

The following OSS project deals mainly with the ResponseController. The goal of this project is make the code more readable, maintainable and to improve elegance of the code. We would like ResponseController to adhere to the DRY principle.
It focuses on refactoring some of the more complex methods and removing some redundant code. At present, ResponseController has methods that would better be located in other controllers. The project relocates such methods to its appropriate Controller class.

== Files modified ==

Following files were mainly modified for this project namely: 
1. response_controller.rb 
2. response_controller_spec.rb 
3. review_mapping_controller.rb 
4. review_mapping_controller_spec.rb 
5. routes.rb 
6. _reviews.html.erb 
7. _scores_submitted_work.html.erb 
8. _self_review.html.erb

== ResponseController ==

Response controller manages the responses entered by users. When a user fills out any kind of rubric (review rubrics,author-feedback rubrics,teammate-review rubrics,quizzes,surveys), a response is generated. Responses come in different versions. Any time an author revises his/her work, and the reviewer reviews it again, a separate Response object is generated.Each Response object points to a particular ResponseMap, which provides details about reviewer, reviewee and reviewed entity.

== What needs to be done ==
1) Refactor the update method which is too long and hard to read. 
2) Refactor the saving method to improve the case handling of selfReviewResponseMap 
3) Move new_feedback method from ResponseController to ReviewMappingController - ResponseController should only handle one kind of object 
4) Modified functional tests for new_feedback method 
5) Added functional test for update_method of response controller 

== Solutions Implemented and Delivered ==

==='''Refactor the update method'''===

Update method is called when any kind of response is edited by the user. This method was very long and unreadable. It was checking the type of @map and round parameter to find out questionnaire using long if..elseif..else ladder, which did not look neat and elegant. There was a helper method 'set_questionnaire' which was being called indirectly by the edit method for retrieving the questionnaire.We called the same function. The intuition behind using this same method was that if it is an update, user is not filling a new rubric and the response object should be available.We can find the questionnaire from the question_id in answers.Hence, in this way the if-else block was eliminated by calling the already available function.
Similarly, there were lines of code,which were creating score if not found or updating if an entry exists. The function 'create_answers' does exactly the same. Abiding by the DRY principle, we called this function which made the update method look concise and simplified. 

==='''Refactor the saving method'''===

Saving method is called to save the response when a user edits any particular response or creates one. It was assigning params[:returs] to 'selfview' if the @map type is selfReponseMap. This params[:return] value was then further used in redirection method to handle the selfReviewResponseMap separately. We removed the assignment params[:return]= "selfreview" from save method. Rather we are directly passing the :return parameter value from edit and new methods of _self_review.html.erb, a view of SubmittedContent controller which handles the selfReview functionality. 
controllers -> respose_controller.rb -> def saving 
[[File:saving.png]]

Views -> submitted_content -> _self_review.html.erb 
[[File:_self_review.png]]

==='''Move new_feedback method from ResponseController to ReviewMappingController'''===

new_feedback method is called when a user provides author feedback for any review. It was defined in the ResponseController earlier which was rather suspect. We moved the method to ReviewMappingController since ResponseController should only handle Response object, while new_feedback is dealing with FeedbackResponseMap object. 

[[File:Response_controller_rb.png]]

 
[[File:Review mapping controller.png]]

==='''Modified functional tests for new_feedback method'''===

We modified the test cases to accommodate changes of the new_feedback method and created new rspec file review_mapping_controller_rspec.rb 
Also added new test case for update method to test if it located the requested response.

CSC/ECE 517 Fall 2016/oss E1639

2016-10-28T16:04:34Z

Rbhatt: /* Refactor the saving method */

This wiki page describes changes made under E1639 OSS project assignment for Fall 2016, CSC/ECE 517.

== Expertiza Background==

Expertiza is a web application for educational purposes. It is an open source project based on Ruby on Rails framework. Expertiza has been created and maintained by faculty and students of NCSU. It helps teachers set up assignments for students who can then make submissions. Students can also review work of other students and give feedback to help incorporate improvements.

== Project Description ==

The following OSS project deals mainly with the ResponseController. The goal of this project is make the code more readable, maintainable and to improve elegance of the code. We would like ResponseController to adhere to the DRY principle.
It focuses on refactoring some of the more complex methods and removing some redundant code. At present, ResponseController has methods that would better be located in other controllers. The project relocates such methods to its appropriate Controller class.

== Files modified ==

Following files were mainly modified for this project namely: 
1. response_controller.rb 
2. response_controller_spec.rb 
3. review_mapping_controller.rb 
4. review_mapping_controller_spec.rb 
5. routes.rb 
6. _reviews.html.erb 
7. _scores_submitted_work.html.erb 
8. _self_review.html.erb

== ResponseController ==

Response controller manages the responses entered by users. When a user fills out any kind of rubric (review rubrics,author-feedback rubrics,teammate-review rubrics,quizzes,surveys), a response is generated. Responses come in different versions. Any time an author revises his/her work, and the reviewer reviews it again, a separate Response object is generated.Each Response object points to a particular ResponseMap, which provides details about reviewer, reviewee and reviewed entity.

== What needs to be done ==
1) Refactor the update method which is too long and hard to read. 
2) Refactor the saving method to improve the case handling of selfReviewResponseMap 
3) Move new_feedback method from ResponseController to ReviewMappingController - ResponseController should only handle one kind of object 
4) Modified functional tests for new_feedback method 
5) Added functional test for update_method of response controller 

== Solutions Implemented and Delivered ==

==='''Refactor the update method'''===

Update method is called when any kind of response is edited by the user. This method was very long and unreadable. It was checking the type of @map and round parameter to find out questionnaire using long if..elseif..else ladder, which did not look neat and elegant. There was a helper method 'set_questionnaire' which was being called indirectly by the edit method for retrieving the questionnaire.We called the same function. The intuition behind using this same method was that if it is an update, user is not filling a new rubric and the response object should be available.We can find the questionnaire from the question_id in answers.Hence, in this way the if-else block was eliminated by calling the already available function.
Similarly, there were lines of code,which were creating score if not found or updating if an entry exists. The function 'create_answers' does exactly the same. Abiding by the DRY principle, we called this function which made the update method look concise and simplified. 

==='''Refactor the saving method'''===

Saving method is called to save the response when a user edits any particular response or creates one. It was assigning params[:returs] to 'selfview' if the @map type is selfReponseMap. This params[:return] value was then further used in redirection method to handle the selfReviewResponseMap separately. We removed the assignment params[:return]= "selfreview" from save method. Rather we are directly passing the :return parameter value from edit and new methods of _self_review.html.erb, a view of SubmittedContent controller which handles the selfReview functionality. 
[[File:saving.png]]

==='''Move new_feedback method from ResponseController to ReviewMappingController'''===

new_feedback method is called when a user provides author feedback for any review. It was defined in the ResponseController earlier which was rather suspect. We moved the method to ReviewMappingController since ResponseController should only handle Response object, while new_feedback is dealing with FeedbackResponseMap object. 

[[File:Response_controller_rb.png]]

 
[[File:Review mapping controller.png]]

==='''Modified functional tests for new_feedback method'''===

We modified the test cases to accommodate changes of the new_feedback method and created new rspec file review_mapping_controller_rspec.rb 
Also added new test case for update method to test if it located the requested response.

File:Self review.png

2016-10-28T16:00:36Z

Rbhatt: Changes in _self_review partial

Changes in _self_review partial

File:Saving.png

2016-10-28T15:57:59Z

Rbhatt: changes in saving method

changes in saving method

CSC/ECE 517 Fall 2016/oss E1639

2016-10-27T23:46:51Z

Rbhatt: /* Testing Details_removed */

CSC/ECE 517 Fall 2016/oss E1639

2016-10-27T21:26:42Z

Rbhatt: /* Scope for future improvement_removed */

This wiki page describes changes made under E1639 OSS project assignment for Fall 2016, CSC/ECE 517.

== Expertiza Background==

Expertiza is a web application for educational purposes. It is an open source project based on Ruby on Rails framework. Expertiza has been created and maintained by faculty and students of NCSU. It helps teachers set up assignments for students who can then make submissions. Students can also review work of other students and give feedback to help incorporate improvements.

== Project Description ==

The following OSS project deals mainly with the ResponseController. The goal of this project is make the code more readable, maintainable and to improve elegance of the code. We would like ResponseController to adhere to the DRY principle.
It focuses on refactoring some of the more complex methods and removing some redundant code. At present, ResponseController has methods that would better be located in other controllers. The project relocates such methods to its appropriate Controller class.

== Files modified ==

Following files were mainly modified for this project namely: 
1. response_controller.rb 
2. response_controller_spec.rb 
3. review_mapping_controller.rb 
4. review_mapping_controller_spec.rb 
5. routes.rb 
6. _reviews.html.erb 
7. _scores_submitted_work.html.erb 
8. _self_review.html.erb

== ResponseController ==

Response controller manages the responses entered by users. When a user fills out any kind of rubric (review rubrics,author-feedback rubrics,teammate-review rubrics,quizzes,surveys), a response is generated. Responses come in different versions. Any time an author revises his/her work, and the reviewer reviews it again, a separate Response object is generated.Each Response object points to a particular ResponseMap, which provides details about reviewer, reviewee and reviewed entity.

== What needs to be done ==
1) Refactor the update method to improve the functionality of checking the @map type. 
2) Refactor the saving method to improve the case handling of selfReviewResponseMap 
3) Move new_feedback method from ResponseController to ReviewMappingController - ResponseController should only handle one kind of object 
4) Modified functional tests for new_feedback method 

=== Solutions Implemented and Delivered ===

*Refactor the update method 

Update method is called when any kind of response is edited by the user. This method was very long and hard to read. It was checking the type of @map and performing various operations based on it using long if..elseif..else ladder. We implemented a function call to perform the type check operation, thus simplified the update method 

*Refactor the saving method 

Saving method is called to save the response when user edits any particular response or creates one. It was assigning params[:returs] to 'selfview' if the @map type is selfReponseMap. This params[:return] value was then further used in redirection method to handle the selfReviewResponseMap separately. We removed the assignment params[:return]= "selfreview" from save method. Rather we are directly passing the :return parameter value from edit and new methods of _self_review.html.erb, a view of SubmittedContent controller which handles the selfReview functionality. 

*Move new_feedback method from ResponseController to ReviewMappingController 

new_feedback method is called when a user provides author feedback for any review. It was defined in the ResponseController earlier. We moved the method to ReviewMappingController since ResponseController should only handle Response object, while new_feedback is dealing with feedbackResponseMap object. 

*Modified functional tests for new_feedback method 

We modified the test cases to accommodate changes of the new_feedback method and created new rspec file review_mapping_controller_rspec.rb 

== Testing Details==

=== RSpec ===
There were no existing test cases for the GradesController. We have added a new spec file 'grades_spec.rb' which covers testing scenario for the newly added method. The specs were run on the previous and current files and they return the same results implying that the refactored code does not break anything.
As the model was not changed, no test cases were added for the model.

=== UI Testing ===

Following steps needs to be performed to test this code from UI: 
1. Login as instructor. Create a course and an assignment under that course. 
2. Keep the has team checkbox checked while creating the assignment. Add a grading rubric to it. Add at least two students as participants to the assignment. 
3. Create topics for the assignment. 
4. Sign in as one of the students who were added to the assignment. 
5. Go to the assignment and sign up for a topic. 
6. Submit student's work by clicking 'Your work' under that assignment. 
7. Sign in as a different student which is participant of the assignment. 
8. Go to Assignments--><assignment name>-->Others' work (If the link is disabled, login as instructor and change the due date of the assignment to current time). 
9. Give reviews on first student's work. 
10. Login as instructor or first student to look at the review grades.

CSC/ECE 517 Fall 2016/oss E1639

2016-10-27T21:23:53Z

Rbhatt: /* What needs to be done */

This wiki page describes changes made under E1639 OSS project assignment for Fall 2016, CSC/ECE 517.

== Expertiza Background==

Expertiza is a web application for educational purposes. It is an open source project based on Ruby on Rails framework. Expertiza has been created and maintained by faculty and students of NCSU. It helps teachers set up assignments for students who can then make submissions. Students can also review work of other students and give feedback to help incorporate improvements.

== Project Description ==

The following OSS project deals mainly with the ResponseController. The goal of this project is make the code more readable, maintainable and to improve elegance of the code. We would like ResponseController to adhere to the DRY principle.
It focuses on refactoring some of the more complex methods and removing some redundant code. At present, ResponseController has methods that would better be located in other controllers. The project relocates such methods to its appropriate Controller class.

== Files modified ==

Following files were mainly modified for this project namely: 
1. response_controller.rb 
2. response_controller_spec.rb 
3. review_mapping_controller.rb 
4. review_mapping_controller_spec.rb 
5. routes.rb 
6. _reviews.html.erb 
7. _scores_submitted_work.html.erb 
8. _self_review.html.erb

== ResponseController ==

Response controller manages the responses entered by users. When a user fills out any kind of rubric (review rubrics,author-feedback rubrics,teammate-review rubrics,quizzes,surveys), a response is generated. Responses come in different versions. Any time an author revises his/her work, and the reviewer reviews it again, a separate Response object is generated.Each Response object points to a particular ResponseMap, which provides details about reviewer, reviewee and reviewed entity.

== What needs to be done ==
1) Refactor the update method -to improve the functionality of checking the @map type. 
2) Refactor the saving method -to improve the case handling of selfReviewResponseMap 
3) Move new_feedback method from ResponseController to ReviewMappingController - ResponseController should only handle one kind of object 
4) Modified functional tests for new_feedback method 

=== Solutions Implemented and Delivered ===

*Refactor the update method 

Update method is called when any kind of response is edited by the user. This method was very long and hard to read. It was checking the type of @map and performing various operations based on it using long if..elseif..else ladder. We implemented a function call to perform the type check operation, thus simplified the update method 

*Refactor the saving method 

Saving method is called to save the response when user edits any particular response or creates one. It was assigning params[:returs] to 'selfview' if the @map type is selfReponseMap. This params[:return] value was then further used in redirection method to handle the selfReviewResponseMap separately. We removed the assignment params[:return]= "selfreview" from save method. Rather we are directly passing the :return parameter value from edit and new methods of _self_review.html.erb, a view of SubmittedContent controller which handles the selfReview functionality. 

*Move new_feedback method from ResponseController to ReviewMappingController 

new_feedback method is called when a user provides author feedback for any review. It was defined in the ResponseController earlier. We moved the method to ReviewMappingController since ResponseController should only handle Response object, while new_feedback is dealing with feedbackResponseMap object. 

*Modified functional tests for new_feedback method 

We modified the test cases to accommodate changes of the new_feedback method and created new rspec file review_mapping_controller_rspec.rb 

== Testing Details==

=== RSpec ===
There were no existing test cases for the GradesController. We have added a new spec file 'grades_spec.rb' which covers testing scenario for the newly added method. The specs were run on the previous and current files and they return the same results implying that the refactored code does not break anything.
As the model was not changed, no test cases were added for the model.

=== UI Testing ===

Following steps needs to be performed to test this code from UI: 
1. Login as instructor. Create a course and an assignment under that course. 
2. Keep the has team checkbox checked while creating the assignment. Add a grading rubric to it. Add at least two students as participants to the assignment. 
3. Create topics for the assignment. 
4. Sign in as one of the students who were added to the assignment. 
5. Go to the assignment and sign up for a topic. 
6. Submit student's work by clicking 'Your work' under that assignment. 
7. Sign in as a different student which is participant of the assignment. 
8. Go to Assignments--><assignment name>-->Others' work (If the link is disabled, login as instructor and change the due date of the assignment to current time). 
9. Give reviews on first student's work. 
10. Login as instructor or first student to look at the review grades. 

== Scope for future improvement ==
1. The construct_table method in GradesHelper is not used anywhere. It has no reference in the project. So we feel it can be safely removed. 
2. The has_team_and_metareview? method in GradesHelper can be broken down into separate methods, one each for team and metareview. This will provide improved flexibility. It needs some analysis though, as both the entities(team & metareview) are currently checked in conjuction from all the views they are referenced from.

CSC/ECE 517 Fall 2016/oss E1639

2016-10-27T21:22:24Z

Rbhatt: /* What we changed */

This wiki page describes changes made under E1639 OSS project assignment for Fall 2016, CSC/ECE 517.

== Expertiza Background==

Expertiza is a web application for educational purposes. It is an open source project based on Ruby on Rails framework. Expertiza has been created and maintained by faculty and students of NCSU. It helps teachers set up assignments for students who can then make submissions. Students can also review work of other students and give feedback to help incorporate improvements.

== Project Description ==

The following OSS project deals mainly with the ResponseController. The goal of this project is make the code more readable, maintainable and to improve elegance of the code. We would like ResponseController to adhere to the DRY principle.
It focuses on refactoring some of the more complex methods and removing some redundant code. At present, ResponseController has methods that would better be located in other controllers. The project relocates such methods to its appropriate Controller class.

== Files modified ==

Following files were mainly modified for this project namely: 
1. response_controller.rb 
2. response_controller_spec.rb 
3. review_mapping_controller.rb 
4. review_mapping_controller_spec.rb 
5. routes.rb 
6. _reviews.html.erb 
7. _scores_submitted_work.html.erb 
8. _self_review.html.erb

== ResponseController ==

Response controller manages the responses entered by users. When a user fills out any kind of rubric (review rubrics,author-feedback rubrics,teammate-review rubrics,quizzes,surveys), a response is generated. Responses come in different versions. Any time an author revises his/her work, and the reviewer reviews it again, a separate Response object is generated.Each Response object points to a particular ResponseMap, which provides details about reviewer, reviewee and reviewed entity.

== What needs to be done ==
1) : Refactor the update method -to improve the functionality of checking the @map type. 
2) : Refactor the saving method -to improve the case handling of selfReviewResponseMap 
3) : Move new_feedback method from ResponseController to ReviewMappingController - ResponseController should only handle one kind of object 
4) : Modified functional tests for new_feedback method 

=== Solutions Implemented and Delivered ===

*Refactor the update method 

Update method is called when any kind of response is edited by the user. This method was very long and hard to read. It was checking the type of @map and performing various operations based on it using long if..elseif..else ladder. We implemented a function call to perform the type check operation, thus simplified the update method 

*Refactor the saving method 

Saving method is called to save the response when user edits any particular response or creates one. It was assigning params[:returs] to 'selfview' if the @map type is selfReponseMap. This params[:return] value was then further used in redirection method to handle the selfReviewResponseMap separately. We removed the assignment params[:return]= "selfreview" from save method. Rather we are directly passing the :return parameter value from edit and new methods of _self_review.html.erb, a view of SubmittedContent controller which handles the selfReview functionality. 

*Move new_feedback method from ResponseController to ReviewMappingController 

new_feedback method is called when a user provides author feedback for any review. It was defined in the ResponseController earlier. We moved the method to ReviewMappingController since ResponseController should only handle Response object, while new_feedback is dealing with feedbackResponseMap object. 

*Modified functional tests for new_feedback method 

We modified the test cases to accommodate changes of the new_feedback method and created new rspec file review_mapping_controller_rspec.rb 

== Testing Details==

=== RSpec ===
There were no existing test cases for the GradesController. We have added a new spec file 'grades_spec.rb' which covers testing scenario for the newly added method. The specs were run on the previous and current files and they return the same results implying that the refactored code does not break anything.
As the model was not changed, no test cases were added for the model.

=== UI Testing ===

Following steps needs to be performed to test this code from UI: 
1. Login as instructor. Create a course and an assignment under that course. 
2. Keep the has team checkbox checked while creating the assignment. Add a grading rubric to it. Add at least two students as participants to the assignment. 
3. Create topics for the assignment. 
4. Sign in as one of the students who were added to the assignment. 
5. Go to the assignment and sign up for a topic. 
6. Submit student's work by clicking 'Your work' under that assignment. 
7. Sign in as a different student which is participant of the assignment. 
8. Go to Assignments--><assignment name>-->Others' work (If the link is disabled, login as instructor and change the due date of the assignment to current time). 
9. Give reviews on first student's work. 
10. Login as instructor or first student to look at the review grades. 

== Scope for future improvement ==
1. The construct_table method in GradesHelper is not used anywhere. It has no reference in the project. So we feel it can be safely removed. 
2. The has_team_and_metareview? method in GradesHelper can be broken down into separate methods, one each for team and metareview. This will provide improved flexibility. It needs some analysis though, as both the entities(team & metareview) are currently checked in conjuction from all the views they are referenced from.

CSC/ECE 517 Fall 2016/oss E1639

2016-10-27T20:08:30Z

Rbhatt: /* ResponseController */

== '''E1639 - Refactor response_controller.rb''' ==

This wiki page is for the description of changes made under E1555 OSS assignment for Fall 2015, CSC/ECE 517.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student4340, password -> password
* Student login: username -> student4405, password -> password

== Expertiza Background==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and it’s code is available on Github. It allows students to review each other’s work and improve their work upon this feedback.

== Description of the current project ==

The following is an Expertiza based OSS project which deals primarily with the GradesController and GradesHelper. It focusses on refactoring some of the more complex methods, modifying some of the language to make it more Ruby friendly, removing some redundant code. The goal of this project is to attempt to make this part of the application easier to read and maintain.

== Files modified in current project ==

A controller and a helper file were modified for this project namely: 
1. GradesController 
2. GradesHelper 

=== ResponseController ===

Response controller manages the responses entered by users. When a user fills out any kind of rubric (review rubrics,author-feedback rubrics,teammate-review rubrics,quizzes,surveys), a response is generated. Responses come in different versions. Any time an author revises his/her work, and the reviewer reviews it again, a separate Response object is generated.Each Response object points to a particular ReponseMap, which provides details about reviewer, reviewee and reviewed entity.

=== GradesHelper ===

This is a helper class which contains methods for constructing a table(construct_table) and to check whether an assignment has a team and metareveiw(has_team_and_metareview)

== List of changes ==
We worked on the following work items(WIs) 
WI1 : Refactor calculate_all_penalties method into smaller methods 
WI2 : Move the repeated code in conflict_notification & edit methods to a separate method list_questions. 
WI3 : Refactor the code as per the Ruby style guidelines and incorporate the good practices 
WI4 : Test the conflict_notification method to test the changes made. 
WI5 : Move the repeated code in view and view_my_scores methods to a separate method retrieve_questions

=== Solutions Implemented and Delivered ===

*Refactoring calculate_all_penalties method

This is used to calculate various penalty values for each assignment if penalty is applicable.

The following changes were made:

1. This method was very complex, performing too many functions within a single method and had to be broken into 3 smaller methods each having a more well defined function.
2. The following 3 methods were created after splitting the first method 
i. calculate_all_penalties 
ii. calculate_penatly_attributes 
iii. assign_all_penalties 
3. Changes were also made to make the code follow ruby style.The language was made more ruby friendly.
4. Finally some redundant code was commented out as it was non-functional.

Refactoring into smaller more specific methods:

[[File:Change6_new.png]]

Removal of non-functional code :

[[File:Change5_new.png]]

Change of language to make it more Ruby friendly:

[[File:Change1_new.png]]

*Move the redundant piece of code from conflict_notification & edit methods to a new method list_questions

The conflict_notification method is used to help the instructors decide if one of the reviews are unfair or inaccurate.
This was again split into 2 methods with some part of the code which is repeated in another method refactored into a new method.

[[File:Change3_new.png]]

Refactored #Created a method which was a duplicate in conflict_notification and edit methods

[[File:Change4_new.png]]

edit method:

This method is used to edit the questionnaires. This method again has code which is repeated in the conflict_notification method and thus the repeated section was split into a new method.

[[File:Change2_new.png]]

New method:
Refactored #Created a method which was a duplicate in conflict_notification and edit methods

[[File:Change4_new.png]]

Similar refactoring was performed to obtain the retrieve_questions method:

[[File:Latest1.png]]

This is the new method created after the above refactoring:

[[File:Latest2.png]]

== Testing Details==

=== RSpec ===
There were no existing test cases for the GradesController. We have added a new spec file 'grades_spec.rb' which covers testing scenario for the newly added method. The specs were run on the previous and current files and they return the same results implying that the refactored code does not break anything.
As the model was not changed, no test cases were added for the model.

=== UI Testing ===

Following steps needs to be performed to test this code from UI: 
1. Login as instructor. Create a course and an assignment under that course. 
2. Keep the has team checkbox checked while creating the assignment. Add a grading rubric to it. Add at least two students as participants to the assignment. 
3. Create topics for the assignment. 
4. Sign in as one of the students who were added to the assignment. 
5. Go to the assignment and sign up for a topic. 
6. Submit student's work by clicking 'Your work' under that assignment. 
7. Sign in as a different student which is participant of the assignment. 
8. Go to Assignments--><assignment name>-->Others' work (If the link is disabled, login as instructor and change the due date of the assignment to current time). 
9. Give reviews on first student's work. 
10. Login as instructor or first student to look at the review grades. 

== Scope for future improvement ==
1. The construct_table method in GradesHelper is not used anywhere. It has no reference in the project. So we feel it can be safely removed. 
2. The has_team_and_metareview? method in GradesHelper can be broken down into separate methods, one each for team and metareview. This will provide improved flexibility. It needs some analysis though, as both the entities(team & metareview) are currently checked in conjuction from all the views they are referenced from.