Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2015 E1586 AnonymousChatBetweenAuthorAndReviewer

2015-12-04T23:29:58Z

Rahuja:

'''E1586 AnonymousChatBetweenAuthorAndReviewer'''

This page provides a brief description of the '''Expertiza''' project. The project is aimed at developing an email based anonymous session between author and a reviewer so that reviewers can ask questions to the authors for any doubts related to the assignments during peer reviewing.

==Project==

=== Introduction to Expertiza ===
[http://expertiza.ncsu.edu/ Expertiza] is a peer review based system which provides an incremental class based learning together with the instructors and the peers. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza handles assignment submissions, team formations, assignment reviews and grades, etc.

=== Purpose ===
During reviews, many times reviewers will be having questions about the submitted material and if it's a blocker there is no way that the reviewer can progress further with the review. As a result, reviewers will end up submitting the empty or incomplete review.

=== Scope ===
This project is limited to an email based conversation for asking questions and answers. The reviewers would ask questions related to assignment submission doubts to which authors can respond. All this would be taken care as email responses using a link provided in the email. This project does not cater to any live interactive session with spontaneous back-to-back questions and responses.

Following tasks would be incorporated in the project:
* Provide a ‘TextArea’ input field on review forms, where any reviewer can type in their questions.
* Create a new button ‘Ask for Quick Help’ on the review forms.
* An email would be send to the author with the link where he can respond to the questions asked by the reviewers for their submitted work.
* Reviewers would be notified by an email when authors respond to the the questions.

== Design ==

=== Discussion of Resolution ===

We will make the following modifications to implement the chat feature:- 

*Create a new model which will help to extract, store and validate data in the database table which contains information about the interaction between the author/s and reviewer.

*Edit the view which is used by the response controller to incorporate the text area input field on the review form where the reviewer can ask his/her initial query.

*Create a new controller which will contain methods to send emails to the author and reviewers as well as retrieve and display the chat history between the two.

*Create a new view which will facilitate the author to respond to the queries asked by the reviewer. The reviewer can also use this view to ask any follow up questions.

=== Mock-Ups ===
The sample question box would look like:

[[File: ARSNMockup1.JPG]]

An interface with the question would be displayed on opening a link from the email.
The authors can reply the query which reviewers ask.

[[File: ARSNMockup2.JPG]]

=== Design Patterns ===
The implementation team expects that the following design patterns be used in the solution:

* '''Observer Pattern'''<ref>Observer Design Pattern https://en.wikipedia.org/wiki/Observer_pattern</ref>: The observer pattern is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. For example, we are notifying the team members whenever the reviewer submits the query.

* '''Iterator Pattern''': In our instance, we need to display the entire chat history of a particular interaction, hence we can use the iterator design pattern to iterate through the previous chat messages.

=== Database Design ===

[[File:Review_chats.png]]

The above figure shows the schema of a new table which will be created in Expertiza to store relevant information about the chat. It contains the following attributes:
* id: This attribute is auto-generated by rails when we create a table and is auto incremented with each record. It is also the primary key of our table.
* assignment_id: Stores the ID of the assignment for which the interaction between author and reviewer is taking place.
* reviewer_id: Stores the ID of the reviewer who asks the questions.
* team_id: Stores the ID of the team to which the topic belongs.
* type_flag: Flag which is used to indicate if the particular tuple contains a question or answer. It can take two values, 'Q' for question and 'A' for answer.
* content: Stores the question asked by the reviewer or the response given by the author/s depending on the value of the type flag.

Records for a particular interaction can be identified by using a combination of assignment_id, reviewer_id and team_id.

=== Use Cases ===
'''Name:''' Send a question to the author/s about their work. 
'''Actor:''' Reviewer. 
'''Description:''' The reviewer enters his question in the text area which is provided and clicks on the "Ask question" button which is provided as shown in the mock up. On clicking this button an email is sent to the author/s along which a link to answer the question. 
 
'''Name:''' Answer the question which has been asked by the reviewer. 
'''Actor:''' Author/s 
'''Description:''' The author/s click on the link received in their email and are redirected to a page where they can answer the question. Once they submit the answer, an email is sent to the reviewer notifying him/her that their question has been answered. 

[[File:ARSNUsecase.jpeg]]

=== Proposed Tests ===
1. For use case 1, test whether all the team members receive email with the question. 
2. For use case 2, test whether the reviewer receive email with the response. 
3. Test whether all the previous interactions are displayed as chat history. 
4. The 'Ask Question' button should not be enabled until some text has been entered in the text area.

== Implementation ==

'''Files created/modified'''

*Create a new model '''ReviewChat''' .

*Create a new controller '''ReviewChats'''.

*Create new views as discussed in the design.

*Modify view expertiza/app/views/response/response.html.erb to incorporate text box and corresponding submit button.

'''Flowchart'''

[[File: ARSNFlowchart1.png]]

'''Flow'''

*The reviewer enters his question in the text area provided and clicks on the "Submit" button.
[[File: FinalProject1.jpg]]
*On clicking this button the appropriate method is called in ReviewChats controller which sends an email to all the authors of the topic indicating that a question has been asked about their work. The email contains a link which when clicked on will redirect the author to the appropriate view where he/she can answer the question.
[[File: FinalProject4.jpg]]
*On answering the question, the reviewer receives an email indicating that his question has been answered. It also contains a link which redirects the reviewer to the appropriate view where the answer will be displayed.
*The authorized users will also be able to see a link to open existing chat interaction log.
[[File: FinalProject3.jpg]]
*This view also contains the chat history between the author/s and the reviewer for the entire duration of the interaction.
[[File: FinalProject2.jpg]]

== Suggestions for Future Improvements ==

* This can be extended to a live interactive author-reviewer anonymous chat session inside the Expertiza reviews window.
* A purging script can be developed which will clear all the interaction records every semester.

==Resources==

* Expertiza Github repository<ref>Expertiza Github repository https://github.com/expertiza/expertiza</ref>

==References==
<references/>

File:Review chats.png

2015-12-04T23:29:07Z

Rahuja:

CSC/ECE 517 Fall 2015 E1586 AnonymousChatBetweenAuthorAndReviewer

2015-11-10T00:44:45Z

Rahuja: /* Use Cases */

Intro

== Assignment ==

=== Description ===
This project aims at developing an email based anonymous session between author and a reviewer so that reviewers can ask questions to the authors for any doubts related to the assignments during peer reviewing.

=== Purpose ===
During reviews, many times reviewers will be having questions about the submitted material and if it's a blocker there is no way that the reviewer can progress further with the review. As a result, reviewers will end up submitting the empty or incomplete review.

=== Scope ===
This project is limited to an email based conversation for asking questions and answers. The reviewers would ask questions related to assignment submission doubts to which authors can respond. All this would be taken care as email responses using a link provided in the email. This project does not cater to any live interactive session with spontaneous back-to-back questions and responses.

Following tasks would be incorporated in the project:
* Provide a ‘TextArea’ input field on review forms, where any reviewer can type in their questions.
* Create a new button ‘Ask for Quick Help’ on the review forms.
* An email would be send to the author with the link where he can respond to the questions asked by the reviewers for their submitted work.
* Reviewers would be notified by an email when authors respond to the the questions.

== Design ==

=== Discussion of Resolution ===

We will make the following modifications to implement the chat feature:- 

*Create a new model which will help extract,store and validate data in the database table which contains information about the interaction between the author/s and reviewer.

*Edit the view which is used by the response controller to incorporate the text area input field on the review form where the reviewer can ask his/her initial query.

*Create a new controller which will contain methods to send emails to the author and reviewers as well as retrieve and display the chat history between the two.

*Create a new view which will facilitate the author to respond to the queries asked by the reviewer. The reviewer can also use this view to ask any follow up questions.

=== Mock-Ups ===
The sample question box would look like:

[[File: ARSNMockup1.JPG]]

An interface with the question would be displayed on opening a link from the email.
The authors can reply the query which reviewers ask.

[[File: ARSNMockup2.JPG]]

=== Design Patterns ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

=== Database Design ===

[[File:DatabaseTable.jpg]]

The above figure shows the schema of a new table which will be created in Expertiza to store relevant information about the chat. It contains the following attributes:
* id: This attribute is auto-generated by rails when we create a table and is auto incremented with each record. It is also the primary key of our table.
* assignment_id: Stores the ID of the assignment for which the interaction between author and reviewer is taking place.
* reviewer_id: Stores the ID of the reviewer who asks the questions.
* team_id: Stores the ID of the team to which the topic belongs.
* type_flag: Flag which is used to indicate if the particular tuple contains a question or answer. It can take two values, 'Q' for question and 'A' for answer.
* content: Stores the question asked by the reviewer or the response given by the author/s depending on the value of the type flag.

Records for a particular interaction can be identified by using a combination of assignment_id, reviewer_id and team_id.

=== Use Cases ===
'''Name:''' Send a question to the author/s about their work. 
'''Actor:''' Reviewer. 
'''Description:''' The reviewer enters his question in the text area which is provided and clicks on the "Ask question" button which is provided as shown in the mock up. On clicking this button an email is sent to the author/s along which a link to answer the question. 
 
'''Name:''' Answer the question which has been asked by the reviewer. 
'''Actor:''' Author/s 
'''Description:''' The author/s click on the link received in their email and are redirected to a page where they can answer the question. Once they submit the answer, an email is sent to the reviewer notifying him/her that their question has been answered. 

=== Proposed Tests ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

== Implementation ==

'''Files created/modified:-'''

*Create a new model chat_feedback.rb

*Create a new controller review_interactions_controller.rb

*Create new views as discussed in the design.

*Modify view expertiza/app/views/response/response.html.erb to incorporate text box and corresponding submit button.

'''Flow:-'''

*The reviewer enters his question in the text area provided and clicks on the "Ask Question" button.
*On clicking this button the appropriate method is called in review_interactions_controller.rb which sends an email to all the authors of the topic indicating that a question has been asked about their work. The email contains a link which when clicked on will redirect the author to the appropriate view where he/she can answer the question.
*On answering the question, the reviewer receives an email indicating that his question has been answered. It also contains a link which redirects the reviewer to the appropriate view where the answer will be displayed.
*This view also contains the chat history between the author/s and the reviewer for the entire duration of the interaction.

== Suggestions for Future Improvements ==

* This can be extended to a live interactive author-reviewer anonymous chat session inside the Expertiza reviews window.
* A purging script can be developed which will clear all the interaction records every semester.

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1586 AnonymousChatBetweenAuthorAndReviewer

2015-11-10T00:44:06Z

Rahuja: /* Implementation */

Intro

== Assignment ==

=== Description ===
This project aims at developing an email based anonymous session between author and a reviewer so that reviewers can ask questions to the authors for any doubts related to the assignments during peer reviewing.

=== Purpose ===
During reviews, many times reviewers will be having questions about the submitted material and if it's a blocker there is no way that the reviewer can progress further with the review. As a result, reviewers will end up submitting the empty or incomplete review.

=== Scope ===
This project is limited to an email based conversation for asking questions and answers. The reviewers would ask questions related to assignment submission doubts to which authors can respond. All this would be taken care as email responses using a link provided in the email. This project does not cater to any live interactive session with spontaneous back-to-back questions and responses.

Following tasks would be incorporated in the project:
* Provide a ‘TextArea’ input field on review forms, where any reviewer can type in their questions.
* Create a new button ‘Ask for Quick Help’ on the review forms.
* An email would be send to the author with the link where he can respond to the questions asked by the reviewers for their submitted work.
* Reviewers would be notified by an email when authors respond to the the questions.

== Design ==

=== Discussion of Resolution ===

We will make the following modifications to implement the chat feature:- 

*Create a new model which will help extract,store and validate data in the database table which contains information about the interaction between the author/s and reviewer.

*Edit the view which is used by the response controller to incorporate the text area input field on the review form where the reviewer can ask his/her initial query.

*Create a new controller which will contain methods to send emails to the author and reviewers as well as retrieve and display the chat history between the two.

*Create a new view which will facilitate the author to respond to the queries asked by the reviewer. The reviewer can also use this view to ask any follow up questions.

=== Mock-Ups ===
The sample question box would look like:

[[File: ARSNMockup1.JPG]]

An interface with the question would be displayed on opening a link from the email.
The authors can reply the query which reviewers ask.

[[File: ARSNMockup2.JPG]]

=== Design Patterns ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

=== Database Design ===

[[File:DatabaseTable.jpg]]

The above figure shows the schema of a new table which will be created in Expertiza to store relevant information about the chat. It contains the following attributes:
* id: This attribute is auto-generated by rails when we create a table and is auto incremented with each record. It is also the primary key of our table.
* assignment_id: Stores the ID of the assignment for which the interaction between author and reviewer is taking place.
* reviewer_id: Stores the ID of the reviewer who asks the questions.
* team_id: Stores the ID of the team to which the topic belongs.
* type_flag: Flag which is used to indicate if the particular tuple contains a question or answer. It can take two values, 'Q' for question and 'A' for answer.
* content: Stores the question asked by the reviewer or the response given by the author/s depending on the value of the type flag.

Records for a particular interaction can be identified by using a combination of assignment_id, reviewer_id and team_id.

=== Use Cases ===
Name: Send a question to the author/s about their work. 
Actor: Reviewer. 
Description: The reviewer enters his question in the text area which is provided and clicks on the "Ask question" button which is provided as shown in the mock up. On clicking this button an email is sent to the author/s along which a link to answer the question. 
 
Name: Answer the question which has been asked by the reviewer. 
Actor: Author/s 
Description: The author/s click on the link received in their email and are redirected to a page where they can answer the question. Once they submit the answer, an email is sent to the reviewer notifying him/her that their question has been answered. 

=== Proposed Tests ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

== Implementation ==

'''Files created/modified:-'''

*Create a new model chat_feedback.rb

*Create a new controller review_interactions_controller.rb

*Create new views as discussed in the design.

*Modify view expertiza/app/views/response/response.html.erb to incorporate text box and corresponding submit button.

'''Flow:-'''

*The reviewer enters his question in the text area provided and clicks on the "Ask Question" button.
*On clicking this button the appropriate method is called in review_interactions_controller.rb which sends an email to all the authors of the topic indicating that a question has been asked about their work. The email contains a link which when clicked on will redirect the author to the appropriate view where he/she can answer the question.
*On answering the question, the reviewer receives an email indicating that his question has been answered. It also contains a link which redirects the reviewer to the appropriate view where the answer will be displayed.
*This view also contains the chat history between the author/s and the reviewer for the entire duration of the interaction.

== Suggestions for Future Improvements ==

* This can be extended to a live interactive author-reviewer anonymous chat session inside the Expertiza reviews window.
* A purging script can be developed which will clear all the interaction records every semester.

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1586 AnonymousChatBetweenAuthorAndReviewer

2015-11-10T00:43:46Z

Rahuja: /* Implementation */

Intro

== Assignment ==

=== Description ===
This project aims at developing an email based anonymous session between author and a reviewer so that reviewers can ask questions to the authors for any doubts related to the assignments during peer reviewing.

=== Purpose ===
During reviews, many times reviewers will be having questions about the submitted material and if it's a blocker there is no way that the reviewer can progress further with the review. As a result, reviewers will end up submitting the empty or incomplete review.

=== Scope ===
This project is limited to an email based conversation for asking questions and answers. The reviewers would ask questions related to assignment submission doubts to which authors can respond. All this would be taken care as email responses using a link provided in the email. This project does not cater to any live interactive session with spontaneous back-to-back questions and responses.

Following tasks would be incorporated in the project:
* Provide a ‘TextArea’ input field on review forms, where any reviewer can type in their questions.
* Create a new button ‘Ask for Quick Help’ on the review forms.
* An email would be send to the author with the link where he can respond to the questions asked by the reviewers for their submitted work.
* Reviewers would be notified by an email when authors respond to the the questions.

== Design ==

=== Discussion of Resolution ===

We will make the following modifications to implement the chat feature:- 

*Create a new model which will help extract,store and validate data in the database table which contains information about the interaction between the author/s and reviewer.

*Edit the view which is used by the response controller to incorporate the text area input field on the review form where the reviewer can ask his/her initial query.

*Create a new controller which will contain methods to send emails to the author and reviewers as well as retrieve and display the chat history between the two.

*Create a new view which will facilitate the author to respond to the queries asked by the reviewer. The reviewer can also use this view to ask any follow up questions.

=== Mock-Ups ===
The sample question box would look like:

[[File: ARSNMockup1.JPG]]

An interface with the question would be displayed on opening a link from the email.
The authors can reply the query which reviewers ask.

[[File: ARSNMockup2.JPG]]

=== Design Patterns ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

=== Database Design ===

[[File:DatabaseTable.jpg]]

The above figure shows the schema of a new table which will be created in Expertiza to store relevant information about the chat. It contains the following attributes:
* id: This attribute is auto-generated by rails when we create a table and is auto incremented with each record. It is also the primary key of our table.
* assignment_id: Stores the ID of the assignment for which the interaction between author and reviewer is taking place.
* reviewer_id: Stores the ID of the reviewer who asks the questions.
* team_id: Stores the ID of the team to which the topic belongs.
* type_flag: Flag which is used to indicate if the particular tuple contains a question or answer. It can take two values, 'Q' for question and 'A' for answer.
* content: Stores the question asked by the reviewer or the response given by the author/s depending on the value of the type flag.

Records for a particular interaction can be identified by using a combination of assignment_id, reviewer_id and team_id.

=== Use Cases ===
Name: Send a question to the author/s about their work. 
Actor: Reviewer. 
Description: The reviewer enters his question in the text area which is provided and clicks on the "Ask question" button which is provided as shown in the mock up. On clicking this button an email is sent to the author/s along which a link to answer the question. 
 
Name: Answer the question which has been asked by the reviewer. 
Actor: Author/s 
Description: The author/s click on the link received in their email and are redirected to a page where they can answer the question. Once they submit the answer, an email is sent to the reviewer notifying him/her that their question has been answered. 

=== Proposed Tests ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

== Implementation ==

Files created/modified:-

*Create a new model chat_feedback.rb

*Create a new controller review_interactions_controller.rb

*Create new views as discussed in the design.

*Modify view expertiza/app/views/response/response.html.erb to incorporate text box and corresponding submit button.

Flow:-

*The reviewer enters his question in the text area provided and clicks on the "Ask Question" button.
*On clicking this button the appropriate method is called in review_interactions_controller.rb which sends an email to all the authors of the topic indicating that a question has been asked about their work. The email contains a link which when clicked on will redirect the author to the appropriate view where he/she can answer the question.
*On answering the question, the reviewer receives an email indicating that his question has been answered. It also contains a link which redirects the reviewer to the appropriate view where the answer will be displayed.
*This view also contains the chat history between the author/s and the reviewer for the entire duration of the interaction.

== Suggestions for Future Improvements ==

* This can be extended to a live interactive author-reviewer anonymous chat session inside the Expertiza reviews window.
* A purging script can be developed which will clear all the interaction records every semester.

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1586 AnonymousChatBetweenAuthorAndReviewer

2015-11-10T00:21:22Z

Rahuja: /* Discussion of Resolution */

Intro

== Assignment ==

=== Description ===
This project aims at developing an email based anonymous session between author and a reviewer so that reviewers can ask questions to the authors for any doubts related to the assignments during peer reviewing.

=== Purpose ===
During reviews, many times reviewers will be having questions about the submitted material and if it's a blocker there is no way that the reviewer can progress further with the review. As a result, reviewers will end up submitting the empty or incomplete review.

=== Scope ===
This project is limited to an email based conversation for asking questions and answers. The reviewers would ask questions related to assignment submission doubts to which authors can respond. All this would be taken care as email responses using a link provided in the email. This project does not cater to any live interactive session with spontaneous back-to-back questions and responses.

Following tasks would be incorporated in the project:
* Provide a ‘TextArea’ input field on review forms, where any reviewer can type in their questions.
* Create a new button ‘Ask for Quick Help’ on the review forms.
* An email would be send to the author with the link where he can respond to the questions asked by the reviewers for their submitted work.
* Reviewers would be notified by an email when authors respond to the the questions.

== Design ==

=== Discussion of Resolution ===

We will make the following modifications to implement the chat feature:- 

*Create a new model which will help extract,store and validate data in the database table which contains information about the interaction between the author/s and reviewer.

*Edit the view which is used by the response controller to incorporate the text area input field on the review form where the reviewer can ask his/her initial query.

*Create a new controller which will contain methods to send emails to the author and reviewers as well as retrieve and display the chat history between the two.

*Create a new view which will facilitate the author to respond to the queries asked by the reviewer. The reviewer can also use this view to ask any follow up questions.

=== Mock-Ups ===
The sample question box would look like:

[[File: ARSNMockup1.JPG]]

An interface with the question would be displayed on opening a link from the email.
The authors can reply the query which reviewers ask.

[[File: ARSNMockup2.JPG]]

=== Design Patterns ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

=== Database Design ===

[[File:DatabaseTable.jpg]]

The above figure shows the schema of a new table which will be created in Expertiza to store relevant information about the chat. It contains the following attributes:
* id: This attribute is auto-generated by rails when we create a table and is auto incremented with each record. It is also the primary key of our table.
* assignment_id: Stores the ID of the assignment for which the interaction between author and reviewer is taking place.
* reviewer_id: Stores the ID of the reviewer who asks the questions.
* team_id: Stores the ID of the team to which the topic belongs.
* type_flag: Flag which is used to indicate if the particular tuple contains a question or answer. It can take two values, 'Q' for question and 'A' for answer.
* content: Stores the question asked by the reviewer or the response given by the author/s depending on the value of the type flag.

Records for a particular interaction can be identified by using a combination of assignment_id, reviewer_id and team_id.

=== Use Cases ===
Name: Send a question to the author/s about their work. 
Actor: Reviewer. 
Description: The reviewer enters his question in the text area which is provided and clicks on the "Ask question" button which is provided as shown in the mock up. On clicking this button an email is sent to the author/s along which a link to answer the question. 
 
Name: Answer the question which has been asked by the reviewer. 
Actor: Author/s 
Description: The author/s click on the link received in their email and are redirected to a page where they can answer the question. Once they submit the answer, an email is sent to the reviewer notifying him/her that their question has been answered. 

=== Proposed Tests ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

== Implementation ==

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

== Suggestions for Future Improvements ==

* This can be extended to a live interactive author-reviewer anonymous chat session inside the Expertiza reviews window.
* A purging script can be developed which will clear all the interaction records every semester.

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1586 AnonymousChatBetweenAuthorAndReviewer

2015-11-09T16:56:57Z

Rahuja: /* Database Design */

Intro

== Assignment ==

=== Description ===
This project aims at developing an email based anonymous session between author and a reviewer so that reviewers can ask questions to the authors for any doubts related to the assignments during peer reviewing.

=== Purpose ===
During reviews, many times reviewers will be having questions about the submitted material and if it's a blocker there is no way that the reviewer can progress further with the review. As a result, reviewers will end up submitting the empty or incomplete review.

=== Scope ===
This project is limited to an email based conversation for asking questions and answers. The reviewers would ask questions related to assignment submission doubts to which authors can respond. All this would be taken care as email responses using a link provided in the email. This project does not cater to any live interactive session with spontaneous back-to-back questions and responses.

Following tasks would be incorporated in the project:
* Provide a ‘TextArea’ input field on review forms, where any reviewer can type in their questions.
* Create a new button ‘Ask for Quick Help’ on the review forms.
* An email would be send to the author with the link where he can respond to the questions asked by the reviewers for their submitted work.
* Reviewers would be notified by an email when authors respond to the the questions.

== Design ==

=== Discussion of Resolution ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

=== Mock-Ups ===
The sample question box would look like:

[[File: ARSNMockup1.JPG]]

An interface with the question would be displayed on opening a link from the email.
The authors can reply the query which reviewers ask.

[[File: ARSNMockup2.JPG]]

=== Design Patterns ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

=== Database Design ===

[[File:DatabaseTable.jpg]]

The above figure shows the schema of a new table which will be created in Expertiza to store relevant information about the chat. It contains the following attributes:
* id: This attribute is auto-generated by rails when we create a table and is auto incremented with each record. It is also the primary key of our table.
* assignment_id: Stores the ID of the assignment for which the interaction between author and reviewer is taking place.
* reviewer_id: Stores the ID of the reviewer who asks the questions.
* team_id: Stores the ID of the team to which the topic belongs.
* type_flag: Flag which is used to indicate if the particular tuple contains a question or answer. It can take two values, 'Q' for question and 'A' for answer.
* content: Stores the question asked by the reviewer or the response given by the author/s depending on the value of the type flag.

Records for a particular interaction can be identified by using a combination of assignment_id, reviewer_id and team_id.

=== Use Cases ===
Name: Send a question to the author/s about their work. 
Actor: Reviewer. 
Description: The reviewer enters his question in the text area which is provided and clicks on the "Ask question" button which is provided as shown in the mock up. On clicking this button an email is sent to the author/s along which a link to answer the question. 
 
Name: Answer the question which has been asked by the reviewer. 
Actor: Author/s 
Description: The author/s click on the link received in their email and are redirected to a page where they can answer the question. Once they submit the answer, an email is sent to the reviewer notifying him/her that their question has been answered. 

=== Proposed Tests ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

== Implementation ==

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

== Suggestions for Future Improvements ==

* This can be extended to a live interactive author-reviewer anonymous chat session inside the Expertiza reviews window.
* A purging script can be developed which will clear all the interaction records every semester.

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1586 AnonymousChatBetweenAuthorAndReviewer

2015-11-09T08:27:17Z

Rahuja: /* Database Design */

Intro

== Assignment ==

=== Description ===
This project aims at developing an email based anonymous session between author and a reviewer so that reviewers can ask questions to the authors for any doubts related to the assignments during peer reviewing.

=== Purpose ===
During reviews, many times reviewers will be having questions about the submitted material and if it's a blocker there is no way that the reviewer can progress further with the review. As a result, reviewers will end up submitting the empty or incomplete review.

=== Scope ===
This project is limited to an email based conversation for asking questions and answers. The reviewers would ask questions related to assignment submission doubts to which authors can respond. All this would be taken care as email responses using a link provided in the email. This project does not cater to any live interactive session with spontaneous back-to-back questions and responses.

Following tasks would be incorporated in the project:
* Provide a ‘TextArea’ input field on review forms, where any reviewer can type in their questions.
* Create a new button ‘Ask for Quick Help’ on the review forms.
* An email would be send to the author with the link where he can respond to the questions asked by the reviewers for their submitted work.
* Reviewers would be notified by an email when authors respond to the the questions.

== Design ==

=== Discussion of Resolution ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

=== Mock-Ups ===
The sample question box would look like:

[[File: ARSNMockup1.JPG]]

An interface with the question would be displayed on opening a link from the email.
The authors can reply the query which reviewers ask.

[[File: ARSNMockup2.JPG]]

=== Design Patterns ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

=== Database Design ===

[[File:DatabaseTable.jpg]]

The above figure shows the schema of a new table which will be created in Expertiza to store relevant information about the chat. It contains the following attributes:
* id: This attribute is auto-generated by rails when we create a table and is auto incremented with each record. It is also the primary key of our table.
* assignment_id: Stores the ID of the assignment for which the interaction between author and reviewer is taking place.
* reviwer_id: Stores the ID of the reviewer who asks the questions.
* team_id: Stores the ID of the team to which the topic belongs.
* type_flag: Flag which is used to indicate if the particular tuple contains a question or answer. It can take two values, 'Q' for question and 'A' for answer.
* content: Stores the question asked by the reviewer or the response given by the author/s depending on the value of the type flag.

Records for a particular interaction can be identified by using a combination of assignment_id, reviewer_id and team_id.

=== Use Cases ===
Name: Send a question to the author/s about their work. 
Actor: Reviewer. 
Description: The reviewer enters his question in the text area which is provided and clicks on the "Ask question" button which is provided as shown in the mock up. On clicking this button an email is sent to the author/s along which a link to answer the question. 
 
Name: Answer the question which has been asked by the reviewer. 
Actor: Author/s 
Description: The author/s click on the link received in their email and are redirected to a page where they can answer the question. Once they submit the answer, an email is sent to the reviewer notifying him/her that their question has been answered. 

=== Proposed Tests ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

== Implementation ==

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

== Suggestions for Future Improvements ==

* This can be extended to a live interactive author-reviewer anonymous chat session inside the Expertiza reviews window.
* A purging script can be developed which will clear all the interaction records every semester.

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1586 AnonymousChatBetweenAuthorAndReviewer

2015-11-09T08:19:59Z

Rahuja: /* Design */

File:DatabaseTable.jpg

2015-11-09T08:19:01Z

Rahuja:

CSC/ECE 517 Fall 2015 E1586 AnonymousChatBetweenAuthorAndReviewer

2015-11-09T07:50:59Z

Rahuja: /* Use Cases */

CSC/ECE 517 Fall 2015 E1586 AnonymousChatBetweenAuthorAndReviewer

2015-11-09T07:42:26Z

Rahuja: /* Use Cases */

CSC/ECE 517 Fall 2015/oss E1552 NFR

2015-11-07T05:02:01Z

Rahuja: /* Testing */

'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb'''
=='''Overview'''==
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure
<ref>Refactoring: Improving the Design of Existing Code -
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Robert
[https://books.google.com/books/about/Refactoring.html?id=HmrDHwgkbPsC&printsec=frontcover&source=kp_read_button#v=onepage&q&f=false]</ref>. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
There are many benefits of refactoring as follows:
<ref>Refactoring Software using Design Patterns - by Masatomo Noborikawa
[http://www.cs.uni.edu/~wallingf/miscellaneous/student-papers/noborikawa-paper.pdf]</ref>

* Refactoring improves the design of software. Refactoring often cleans up codes by deleting duplicates, divides a big chunk of codes into several methods, and makes the program more understandable.
* Because refactoring makes a design cleaner, it helps the programmers understand codes better and see things that may have not been seen before.
* Refactoring helps spot bugs since it makes the software more comprehensible.
* Refactoring turns an adverse design into a good design, which allows for rapid software development.

__TOC__

=='''Peer Reviewing'''==
It is the process of evaluating work done by an individual or a team by another team or an individual with expertise in the concerned area.
Types of Reviewing Strategies in Expertiza -

* Instructor Selected Reviewing - Using this strategy the instructor assigns reviews to all participants of the assignment. After selecting this strategy the instructor has the following two options -
** Set number of reviews done by each student.
** Set minimum number of reviews done for each submission.
Then the instructor can click on assign reviewers and map the students to the topics which should be reviewed by them.

[[File:editing_assignment.png‎ |frame|center|Instructor selected Reviewing]]

* Auto Selected Reviewing - If the instructor selects this strategy, students need to select reviews themselves. Either the student is given a list of topics to choose from and he selects which topic he wants to review, or he checks “I don’t care which topic I review” and he/she will be randomly assigned a topic to review. The instructor can also specify two parameters after selecting this strategy -
** Review topic threshold: - Let us assume Topic 1 has a submission than has not been reviewed. Topic 2 has submissions that has been reviewed atleast 2 times and k is set 2. Then the student will not be able to select topic 2 until all of topic 1’s submission has been reviewed atleast 2 times.
** Maximum number of reviews per submission: - This specifies the maximum number of times a particular top can be reviewed.

[[File:editing_assignment_2.png‎ |frame|center|Auto selected Reviewing]]

* Student Selected Reviewing -
In this strategy the student selects a particular submission to review instead of a particular topic. This feature had never been used and did not work correctly. Hence it has been removed from the system. However there are a lot of places where the code for student selected reviewing exists however it not being called anywhere.

=='''Project Resources'''==
* [https://github.com/rahuja910/expertiza GitHub Repository]
* [https://github.com/expertiza/expertiza/pull/602 GitHub Pull Request Link]
* [http://152.46.20.183:3000/ VCL Deployment Link] (For Instructor - username: instructor6, password: password. For student - username: student5700, password: password)

=='''Problem Statement'''==
==='''Classes involved'''===
dynamic_quiz_assignment_helper.rb
dynamic_review_assignment_helper.rb

==='''What it does''' ===
dynamic_review_assignment_helper.rb allows the system choose a team to review when a student chooses a topic to review. It helps the code choose topics that have submissions with fewer reviews than other topics. A threshold k is used to decide whether a particular topic can be chosen. If, e.g., Topic 1 has a submission that has not yet been reviewed, and Topic 2 has no submission that has been reviewed by fewer than 3 reviewers, then the incoming reviewer can only choose Topic 2 if k ≥ 3. This class does not actually decide what is reviewable, but it does make up a sorted list of the submissions by the number of the reviews they have. dynamic_quiz_assignment_helper.rb is similar, but for quizzes.

==='''What needed to be done'''===
* Keep only "auto selected" and "instructor selected reviewing".
* The find_submissions_in_current_cycle method returns a list of participants. It should return a list of teams.
* Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes
* The two classes have a lot of duplicated code. Remove all DRY problems.

==='''Change in problem statement'''===

While making changes to the helper classes to remove student selected reviewing, a commit was made to the expertiza repository which deleted the page for student selected reviewing.
https://github.com/expertiza/expertiza/commit/b62182b4bb42f563ba3cee88917119be378db439

In student-selected reviewing, a student was allowed to review a particular submission and not just a particular topic.The functionality for “student-selected” reviewing was never implemented successfully. Hence, the methods corresponding to the aforementioned functionality was needed to be removed.

=='''Modification of find_submissions_in_current_cycle method'''==

This function returns a list of participants for the particular assignment. This leads to redundant entries in the hash since most teams are made up of more than one member. Earlier the submissions belonged to participants rather than teams, however currently there is no need for this since if an instructor wants individual assignments he/she simply selects maximum number of size of a team as one. Correspondingly changes need to be made to the call sites.

* Before Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentParticipant.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
users = TeamsUser.where(team_id: signUp.team_id)
users.each do |user|
participant = Participant.where(user_id: user_id, parent_id: @assignment_id)
if participant
submissions_in_current_cycle << participant
end
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

* After Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentTeam.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
team=Team.where(team_id: signUp.team_id)
if team
submissions_in_current_cycle << team
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

As seen from the above code we have replaced AssignmentParticipant with AssignmentTeam. Now submissions_in_current_cycle will contain list of participants rather than a list of teams. Also note the model for AssignmentTeam contains the same methods which are present in the model for AssignmentParticipant. In the same helper class we had to modify code to handle the aspect that submissions_in_current_cycle now contains teams rather than participants. Hence we made changes in build_submissions_availability().

=='''Implementation of Criteria'''==
'''Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes.''' 
The helper classes while returning a list of teams should check the below set of conditions. Each of the below conditions need to be checked at one place to ensure better code readability and maintainability.

* The article was not written by the potential reviewer.
The potential reviewer should not be able to review its own submission and hence a check for this condition is required. However, it was already implemented in the code beforehand.

* The article was not already reviewed by the potential reviewer.
The potential reviewer should not be able to review a topic which is already reviewed by him/her. The same was also implemented along with the above condition.

* The article is not on the same topic as the potential reviewer has previously written about.
The reviewer should not be able to review on the same topic that he/she submitted as the reviewer could give biased reviews to make his/her own submission seem better. This was not implemented previously and was implemented in the code changes by checking the topic id.

'''Implementation :''' 
<pre>
def self.build_submissions_availability()
least_review_count = -1;
max_no_reviews = 5
reviewer_teams=TeamsUser.where(user_id: @reviewer_id)

@submissions_availability = Hash.new
unless @submissions_in_current_cycle.nil?
@submissions_in_current_cycle.each { |submission|
team_check=false
if( least_review_count == -1)
least_review_count = submission[1]
end
reviewer_teams.each do |reviewer_team|
if submission[0] == reviewer_team.team_id
team_check=true
end
end

if !team_check
@submissions_availability[submission[0]] = get_state(least_review_count,submission[1],max_no_reviews)
end
}
end
return @submissions_availability
end
</pre>

* The article does not already have the maximum number of potential reviews in progress.
The reviewer should only be able to review topics that have not reached the maximum number of reviews. The check for the same is done in get_state method where the current_review_count is compared with max_review_count and make it unavailable.

* The article has the minimum number of reviews for that assignment.
The article is made available if it has the minimum number of reviews for the assignment and the same is checked in get_state method where the current_review_count is compared with least_review_count and make it available.

'''Implementation:''' 
<pre>
def self.get_state(least_review_count,current_review_count,max_review_count)
if(current_review_count != -1 && current_review_count == max_review_count)
return -1
elsif(current_review_count != -1 && current_review_count > least_review_count)
return 1
elsif(current_review_count != -1 && current_review_count == least_review_count)
return 0
end
end
</pre>

=='''Deletion of "student-selected" reviewing'''==
The following files had code for “student-selected” reviewing which needs to be removed.

* dynamic_quiz_assignment_helper.rb (Entire file deleted)
* dynamic_review_assignment_helper.rb (Entire file deleted)
* review_mapping_controller.rb (Only specific method mentioned below deleted)

The method show_available_submissions() in review_mapping_controller.rb was calling student selected reviewing. Since this was the only place the method was being called we decided to delete the below code snippet.

def show_available_submissions
assignment = Assignment.find(params[:assignment_id])
reviewer = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
requested_topic_id = params[:topic_id]
@available_submissions = Hash.new
@available_submissions = DynamicReviewAssignmentHelper::review_assignment(assignment.id ,
reviewer.id,
requested_topic_id ,
Assignment::RS_STUDENT_SELECTED)

Also, this was the only call being made to dynamic_review_assignment_helper.rb and this helper is not used in instructor selected and auto selected reviewing strategies. For these strategies another view is being rendered specifically _set_dynamic_review.html.erb.
Similarly dynamic_quiz_assignment_helper.rb is also not being used by any controller.
Hence the two helper files have been deleted after confirmation from the developer.

=='''Design Patterns'''==

The project involved refactoring code which was used for student selected reviewing. However since this feature was removed from Expertiza during the refactoring, we had to delete the code and hence no design pattern is applicable.

=='''Testing'''==

Since we have deleted the entire helper classes and there has been no code addition, we cannot add any new test cases for deleted code. However, we can manually test to ensure that the code deletion did not cause any broken links by following the steps mentioned below.

Creating an Assignment:
#Login using instructor.
# Go to Manage-->Assignments-->New Public Assignment
# Add couple of topics to the assignments from the topics tab.
# Check “Allow reviewer to choose which topic to review” and “Enable authors to review others working on same topic” in the same tab.
# Choose the review strategy as Auto-Selected in Review Strategy tab.
# Choose appropriate deadlines in the due dates tab.
# Go to Manage-->Assignments--><Your Assignment Name>
# Add participants to the assignment.

Signing up and submitting the Assignment:
# Login using participant1. Select the Assignment from the list of assignments.
# Sign up for a topic.
# Submit your work before the deadline.
# Repeat the same for all participants.

Reviewing work of other Participants:
# Login using participants. Select the Assignment from the list of assignments.
# Click on Other’s Work. You will see a list of topics which are eligible for reviewing.

Validation Criteria:
# You should not be able to review your own submission
# You can review other submissions of the topic if you have checked “Enable authors to review others working on the same topic” while creating the assignment.
# You should not be able to review a submission which has already been reviewed by you.
# You should not be able to review a submission which has reached maximum number of potential reviews.

=='''References'''==
<references/>

CSC/ECE 517 Fall 2015/oss E1552 NFR

2015-11-07T04:59:58Z

Rahuja: /* Deletion of "student-selected" reviewing */

'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb'''
=='''Overview'''==
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure
<ref>Refactoring: Improving the Design of Existing Code -
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Robert
[https://books.google.com/books/about/Refactoring.html?id=HmrDHwgkbPsC&printsec=frontcover&source=kp_read_button#v=onepage&q&f=false]</ref>. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
There are many benefits of refactoring as follows:
<ref>Refactoring Software using Design Patterns - by Masatomo Noborikawa
[http://www.cs.uni.edu/~wallingf/miscellaneous/student-papers/noborikawa-paper.pdf]</ref>

* Refactoring improves the design of software. Refactoring often cleans up codes by deleting duplicates, divides a big chunk of codes into several methods, and makes the program more understandable.
* Because refactoring makes a design cleaner, it helps the programmers understand codes better and see things that may have not been seen before.
* Refactoring helps spot bugs since it makes the software more comprehensible.
* Refactoring turns an adverse design into a good design, which allows for rapid software development.

__TOC__

=='''Peer Reviewing'''==
It is the process of evaluating work done by an individual or a team by another team or an individual with expertise in the concerned area.
Types of Reviewing Strategies in Expertiza -

* Instructor Selected Reviewing - Using this strategy the instructor assigns reviews to all participants of the assignment. After selecting this strategy the instructor has the following two options -
** Set number of reviews done by each student.
** Set minimum number of reviews done for each submission.
Then the instructor can click on assign reviewers and map the students to the topics which should be reviewed by them.

[[File:editing_assignment.png‎ |frame|center|Instructor selected Reviewing]]

* Auto Selected Reviewing - If the instructor selects this strategy, students need to select reviews themselves. Either the student is given a list of topics to choose from and he selects which topic he wants to review, or he checks “I don’t care which topic I review” and he/she will be randomly assigned a topic to review. The instructor can also specify two parameters after selecting this strategy -
** Review topic threshold: - Let us assume Topic 1 has a submission than has not been reviewed. Topic 2 has submissions that has been reviewed atleast 2 times and k is set 2. Then the student will not be able to select topic 2 until all of topic 1’s submission has been reviewed atleast 2 times.
** Maximum number of reviews per submission: - This specifies the maximum number of times a particular top can be reviewed.

[[File:editing_assignment_2.png‎ |frame|center|Auto selected Reviewing]]

* Student Selected Reviewing -
In this strategy the student selects a particular submission to review instead of a particular topic. This feature had never been used and did not work correctly. Hence it has been removed from the system. However there are a lot of places where the code for student selected reviewing exists however it not being called anywhere.

=='''Project Resources'''==
* [https://github.com/rahuja910/expertiza GitHub Repository]
* [https://github.com/expertiza/expertiza/pull/602 GitHub Pull Request Link]
* [http://152.46.20.183:3000/ VCL Deployment Link] (For Instructor - username: instructor6, password: password. For student - username: student5700, password: password)

=='''Problem Statement'''==
==='''Classes involved'''===
dynamic_quiz_assignment_helper.rb
dynamic_review_assignment_helper.rb

==='''What it does''' ===
dynamic_review_assignment_helper.rb allows the system choose a team to review when a student chooses a topic to review. It helps the code choose topics that have submissions with fewer reviews than other topics. A threshold k is used to decide whether a particular topic can be chosen. If, e.g., Topic 1 has a submission that has not yet been reviewed, and Topic 2 has no submission that has been reviewed by fewer than 3 reviewers, then the incoming reviewer can only choose Topic 2 if k ≥ 3. This class does not actually decide what is reviewable, but it does make up a sorted list of the submissions by the number of the reviews they have. dynamic_quiz_assignment_helper.rb is similar, but for quizzes.

==='''What needed to be done'''===
* Keep only "auto selected" and "instructor selected reviewing".
* The find_submissions_in_current_cycle method returns a list of participants. It should return a list of teams.
* Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes
* The two classes have a lot of duplicated code. Remove all DRY problems.

==='''Change in problem statement'''===

While making changes to the helper classes to remove student selected reviewing, a commit was made to the expertiza repository which deleted the page for student selected reviewing.
https://github.com/expertiza/expertiza/commit/b62182b4bb42f563ba3cee88917119be378db439

In student-selected reviewing, a student was allowed to review a particular submission and not just a particular topic.The functionality for “student-selected” reviewing was never implemented successfully. Hence, the methods corresponding to the aforementioned functionality was needed to be removed.

=='''Modification of find_submissions_in_current_cycle method'''==

This function returns a list of participants for the particular assignment. This leads to redundant entries in the hash since most teams are made up of more than one member. Earlier the submissions belonged to participants rather than teams, however currently there is no need for this since if an instructor wants individual assignments he/she simply selects maximum number of size of a team as one. Correspondingly changes need to be made to the call sites.

* Before Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentParticipant.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
users = TeamsUser.where(team_id: signUp.team_id)
users.each do |user|
participant = Participant.where(user_id: user_id, parent_id: @assignment_id)
if participant
submissions_in_current_cycle << participant
end
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

* After Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentTeam.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
team=Team.where(team_id: signUp.team_id)
if team
submissions_in_current_cycle << team
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

As seen from the above code we have replaced AssignmentParticipant with AssignmentTeam. Now submissions_in_current_cycle will contain list of participants rather than a list of teams. Also note the model for AssignmentTeam contains the same methods which are present in the model for AssignmentParticipant. In the same helper class we had to modify code to handle the aspect that submissions_in_current_cycle now contains teams rather than participants. Hence we made changes in build_submissions_availability().

=='''Implementation of Criteria'''==
'''Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes.''' 
The helper classes while returning a list of teams should check the below set of conditions. Each of the below conditions need to be checked at one place to ensure better code readability and maintainability.

* The article was not written by the potential reviewer.
The potential reviewer should not be able to review its own submission and hence a check for this condition is required. However, it was already implemented in the code beforehand.

* The article was not already reviewed by the potential reviewer.
The potential reviewer should not be able to review a topic which is already reviewed by him/her. The same was also implemented along with the above condition.

* The article is not on the same topic as the potential reviewer has previously written about.
The reviewer should not be able to review on the same topic that he/she submitted as the reviewer could give biased reviews to make his/her own submission seem better. This was not implemented previously and was implemented in the code changes by checking the topic id.

'''Implementation :''' 
<pre>
def self.build_submissions_availability()
least_review_count = -1;
max_no_reviews = 5
reviewer_teams=TeamsUser.where(user_id: @reviewer_id)

@submissions_availability = Hash.new
unless @submissions_in_current_cycle.nil?
@submissions_in_current_cycle.each { |submission|
team_check=false
if( least_review_count == -1)
least_review_count = submission[1]
end
reviewer_teams.each do |reviewer_team|
if submission[0] == reviewer_team.team_id
team_check=true
end
end

if !team_check
@submissions_availability[submission[0]] = get_state(least_review_count,submission[1],max_no_reviews)
end
}
end
return @submissions_availability
end
</pre>

* The article does not already have the maximum number of potential reviews in progress.
The reviewer should only be able to review topics that have not reached the maximum number of reviews. The check for the same is done in get_state method where the current_review_count is compared with max_review_count and make it unavailable.

* The article has the minimum number of reviews for that assignment.
The article is made available if it has the minimum number of reviews for the assignment and the same is checked in get_state method where the current_review_count is compared with least_review_count and make it available.

'''Implementation:''' 
<pre>
def self.get_state(least_review_count,current_review_count,max_review_count)
if(current_review_count != -1 && current_review_count == max_review_count)
return -1
elsif(current_review_count != -1 && current_review_count > least_review_count)
return 1
elsif(current_review_count != -1 && current_review_count == least_review_count)
return 0
end
end
</pre>

=='''Deletion of "student-selected" reviewing'''==
The following files had code for “student-selected” reviewing which needs to be removed.

* dynamic_quiz_assignment_helper.rb (Entire file deleted)
* dynamic_review_assignment_helper.rb (Entire file deleted)
* review_mapping_controller.rb (Only specific method mentioned below deleted)

The method show_available_submissions() in review_mapping_controller.rb was calling student selected reviewing. Since this was the only place the method was being called we decided to delete the below code snippet.

def show_available_submissions
assignment = Assignment.find(params[:assignment_id])
reviewer = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
requested_topic_id = params[:topic_id]
@available_submissions = Hash.new
@available_submissions = DynamicReviewAssignmentHelper::review_assignment(assignment.id ,
reviewer.id,
requested_topic_id ,
Assignment::RS_STUDENT_SELECTED)

Also, this was the only call being made to dynamic_review_assignment_helper.rb and this helper is not used in instructor selected and auto selected reviewing strategies. For these strategies another view is being rendered specifically _set_dynamic_review.html.erb.
Similarly dynamic_quiz_assignment_helper.rb is also not being used by any controller.
Hence the two helper files have been deleted after confirmation from the developer.

=='''Design Patterns'''==

The project involved refactoring code which was used for student selected reviewing. However since this feature was removed from Expertiza during the refactoring, we had to delete the code and hence no design pattern is applicable.

=='''Testing'''==

Since we have deleted t

Creating an Assignment:
#Login using instructor.
# Go to Manage-->Assignments-->New Public Assignment
# Add couple of topics to the assignments from the topics tab.
# Check “Allow reviewer to choose which topic to review” and “Enable authors to review others working on same topic” in the same tab.
# Choose the review strategy as Auto-Selected in Review Strategy tab.
# Choose appropriate deadlines in the due dates tab.
# Go to Manage-->Assignments--><Your Assignment Name>
# Add participants to the assignment.

Signing up and submitting the Assignment:
# Login using participant1. Select the Assignment from the list of assignments.
# Sign up for a topic.
# Submit your work before the deadline.
# Repeat the same for all participants.

Reviewing work of other Participants:
# Login using participants. Select the Assignment from the list of assignments.
# Click on Other’s Work. You will see a list of topics which are eligible for reviewing.

Validation Criteria:
# You should not be able to review your own submission
# You can review other submissions of the topic if you have checked “Enable authors to review others working on the same topic” while creating the assignment.
# You should not be able to review a submission which has already been reviewed by you.
# You should not be able to review a submission which has reached maximum number of potential reviews.

=='''References'''==
<references/>

CSC/ECE 517 Fall 2015/oss E1552 NFR

2015-11-07T04:55:06Z

Rahuja: /* What needed to be done */

'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb'''
=='''Overview'''==
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure
<ref>Refactoring: Improving the Design of Existing Code -
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Robert
[https://books.google.com/books/about/Refactoring.html?id=HmrDHwgkbPsC&printsec=frontcover&source=kp_read_button#v=onepage&q&f=false]</ref>. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
There are many benefits of refactoring as follows:
<ref>Refactoring Software using Design Patterns - by Masatomo Noborikawa
[http://www.cs.uni.edu/~wallingf/miscellaneous/student-papers/noborikawa-paper.pdf]</ref>

* Refactoring improves the design of software. Refactoring often cleans up codes by deleting duplicates, divides a big chunk of codes into several methods, and makes the program more understandable.
* Because refactoring makes a design cleaner, it helps the programmers understand codes better and see things that may have not been seen before.
* Refactoring helps spot bugs since it makes the software more comprehensible.
* Refactoring turns an adverse design into a good design, which allows for rapid software development.

__TOC__

=='''Peer Reviewing'''==
It is the process of evaluating work done by an individual or a team by another team or an individual with expertise in the concerned area.
Types of Reviewing Strategies in Expertiza -

* Instructor Selected Reviewing - Using this strategy the instructor assigns reviews to all participants of the assignment. After selecting this strategy the instructor has the following two options -
** Set number of reviews done by each student.
** Set minimum number of reviews done for each submission.
Then the instructor can click on assign reviewers and map the students to the topics which should be reviewed by them.

[[File:editing_assignment.png‎ |frame|center|Instructor selected Reviewing]]

* Auto Selected Reviewing - If the instructor selects this strategy, students need to select reviews themselves. Either the student is given a list of topics to choose from and he selects which topic he wants to review, or he checks “I don’t care which topic I review” and he/she will be randomly assigned a topic to review. The instructor can also specify two parameters after selecting this strategy -
** Review topic threshold: - Let us assume Topic 1 has a submission than has not been reviewed. Topic 2 has submissions that has been reviewed atleast 2 times and k is set 2. Then the student will not be able to select topic 2 until all of topic 1’s submission has been reviewed atleast 2 times.
** Maximum number of reviews per submission: - This specifies the maximum number of times a particular top can be reviewed.

[[File:editing_assignment_2.png‎ |frame|center|Auto selected Reviewing]]

* Student Selected Reviewing -
In this strategy the student selects a particular submission to review instead of a particular topic. This feature had never been used and did not work correctly. Hence it has been removed from the system. However there are a lot of places where the code for student selected reviewing exists however it not being called anywhere.

=='''Project Resources'''==
* [https://github.com/rahuja910/expertiza GitHub Repository]
* [https://github.com/expertiza/expertiza/pull/602 GitHub Pull Request Link]
* [http://152.46.20.183:3000/ VCL Deployment Link] (For Instructor - username: instructor6, password: password. For student - username: student5700, password: password)

=='''Problem Statement'''==
==='''Classes involved'''===
dynamic_quiz_assignment_helper.rb
dynamic_review_assignment_helper.rb

==='''What it does''' ===
dynamic_review_assignment_helper.rb allows the system choose a team to review when a student chooses a topic to review. It helps the code choose topics that have submissions with fewer reviews than other topics. A threshold k is used to decide whether a particular topic can be chosen. If, e.g., Topic 1 has a submission that has not yet been reviewed, and Topic 2 has no submission that has been reviewed by fewer than 3 reviewers, then the incoming reviewer can only choose Topic 2 if k ≥ 3. This class does not actually decide what is reviewable, but it does make up a sorted list of the submissions by the number of the reviews they have. dynamic_quiz_assignment_helper.rb is similar, but for quizzes.

==='''What needed to be done'''===
* Keep only "auto selected" and "instructor selected reviewing".
* The find_submissions_in_current_cycle method returns a list of participants. It should return a list of teams.
* Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes
* The two classes have a lot of duplicated code. Remove all DRY problems.

==='''Change in problem statement'''===

While making changes to the helper classes to remove student selected reviewing, a commit was made to the expertiza repository which deleted the page for student selected reviewing.
https://github.com/expertiza/expertiza/commit/b62182b4bb42f563ba3cee88917119be378db439

In student-selected reviewing, a student was allowed to review a particular submission and not just a particular topic.The functionality for “student-selected” reviewing was never implemented successfully. Hence, the methods corresponding to the aforementioned functionality was needed to be removed.

=='''Modification of find_submissions_in_current_cycle method'''==

This function returns a list of participants for the particular assignment. This leads to redundant entries in the hash since most teams are made up of more than one member. Earlier the submissions belonged to participants rather than teams, however currently there is no need for this since if an instructor wants individual assignments he/she simply selects maximum number of size of a team as one. Correspondingly changes need to be made to the call sites.

* Before Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentParticipant.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
users = TeamsUser.where(team_id: signUp.team_id)
users.each do |user|
participant = Participant.where(user_id: user_id, parent_id: @assignment_id)
if participant
submissions_in_current_cycle << participant
end
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

* After Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentTeam.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
team=Team.where(team_id: signUp.team_id)
if team
submissions_in_current_cycle << team
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

As seen from the above code we have replaced AssignmentParticipant with AssignmentTeam. Now submissions_in_current_cycle will contain list of participants rather than a list of teams. Also note the model for AssignmentTeam contains the same methods which are present in the model for AssignmentParticipant. In the same helper class we had to modify code to handle the aspect that submissions_in_current_cycle now contains teams rather than participants. Hence we made changes in build_submissions_availability().

=='''Implementation of Criteria'''==
'''Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes.''' 
The helper classes while returning a list of teams should check the below set of conditions. Each of the below conditions need to be checked at one place to ensure better code readability and maintainability.

* The article was not written by the potential reviewer.
The potential reviewer should not be able to review its own submission and hence a check for this condition is required. However, it was already implemented in the code beforehand.

* The article was not already reviewed by the potential reviewer.
The potential reviewer should not be able to review a topic which is already reviewed by him/her. The same was also implemented along with the above condition.

* The article is not on the same topic as the potential reviewer has previously written about.
The reviewer should not be able to review on the same topic that he/she submitted as the reviewer could give biased reviews to make his/her own submission seem better. This was not implemented previously and was implemented in the code changes by checking the topic id.

'''Implementation :''' 
<pre>
def self.build_submissions_availability()
least_review_count = -1;
max_no_reviews = 5
reviewer_teams=TeamsUser.where(user_id: @reviewer_id)

@submissions_availability = Hash.new
unless @submissions_in_current_cycle.nil?
@submissions_in_current_cycle.each { |submission|
team_check=false
if( least_review_count == -1)
least_review_count = submission[1]
end
reviewer_teams.each do |reviewer_team|
if submission[0] == reviewer_team.team_id
team_check=true
end
end

if !team_check
@submissions_availability[submission[0]] = get_state(least_review_count,submission[1],max_no_reviews)
end
}
end
return @submissions_availability
end
</pre>

* The article does not already have the maximum number of potential reviews in progress.
The reviewer should only be able to review topics that have not reached the maximum number of reviews. The check for the same is done in get_state method where the current_review_count is compared with max_review_count and make it unavailable.

* The article has the minimum number of reviews for that assignment.
The article is made available if it has the minimum number of reviews for the assignment and the same is checked in get_state method where the current_review_count is compared with least_review_count and make it available.

'''Implementation:''' 
<pre>
def self.get_state(least_review_count,current_review_count,max_review_count)
if(current_review_count != -1 && current_review_count == max_review_count)
return -1
elsif(current_review_count != -1 && current_review_count > least_review_count)
return 1
elsif(current_review_count != -1 && current_review_count == least_review_count)
return 0
end
end
</pre>

=='''Deletion of "student-selected" reviewing'''==
The following files had code for “student-selected” reviewing –

* dynamic_quiz_assignment_helper.rb
* dynamic_review_assignment_helper.rb
* review_mapping_controller.rb

In this page the method show_available_submissions() in review_mapping_controller.rb was being called. Since this was the only place the method was being called we decided to delete the below code snippet.

def show_available_submissions
assignment = Assignment.find(params[:assignment_id])
reviewer = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
requested_topic_id = params[:topic_id]
@available_submissions = Hash.new
@available_submissions = DynamicReviewAssignmentHelper::review_assignment(assignment.id ,
reviewer.id,
requested_topic_id ,
Assignment::RS_STUDENT_SELECTED)

Also, this is the only call being made to dynamic_review_assignment_helper.rb and this helper is not used in instructor selected and auto selected reviewing strategies. For these strategies another view is being rendered specifically _set_dynamic_review.html.erb.
Similarly dynamic_quiz_assignment_helper.rb is also not being used by any controller.
Hence the two helper files have been deleted after confirmation from the developer.

=='''Design Patterns'''==

The project involved refactoring code which was used for student selected reviewing. However since this feature was removed from Expertiza during the refactoring, we had to delete the code and hence no design pattern is applicable.

=='''Testing'''==

Since we have deleted t

Creating an Assignment:
#Login using instructor.
# Go to Manage-->Assignments-->New Public Assignment
# Add couple of topics to the assignments from the topics tab.
# Check “Allow reviewer to choose which topic to review” and “Enable authors to review others working on same topic” in the same tab.
# Choose the review strategy as Auto-Selected in Review Strategy tab.
# Choose appropriate deadlines in the due dates tab.
# Go to Manage-->Assignments--><Your Assignment Name>
# Add participants to the assignment.

Signing up and submitting the Assignment:
# Login using participant1. Select the Assignment from the list of assignments.
# Sign up for a topic.
# Submit your work before the deadline.
# Repeat the same for all participants.

Reviewing work of other Participants:
# Login using participants. Select the Assignment from the list of assignments.
# Click on Other’s Work. You will see a list of topics which are eligible for reviewing.

Validation Criteria:
# You should not be able to review your own submission
# You can review other submissions of the topic if you have checked “Enable authors to review others working on the same topic” while creating the assignment.
# You should not be able to review a submission which has already been reviewed by you.
# You should not be able to review a submission which has reached maximum number of potential reviews.

=='''References'''==
<references/>

CSC/ECE 517 Fall 2015/oss E1552 NFR

2015-11-07T04:53:53Z

Rahuja: /* Change in problem statement */

'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb'''
=='''Overview'''==
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure
<ref>Refactoring: Improving the Design of Existing Code -
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Robert
[https://books.google.com/books/about/Refactoring.html?id=HmrDHwgkbPsC&printsec=frontcover&source=kp_read_button#v=onepage&q&f=false]</ref>. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
There are many benefits of refactoring as follows:
<ref>Refactoring Software using Design Patterns - by Masatomo Noborikawa
[http://www.cs.uni.edu/~wallingf/miscellaneous/student-papers/noborikawa-paper.pdf]</ref>

* Refactoring improves the design of software. Refactoring often cleans up codes by deleting duplicates, divides a big chunk of codes into several methods, and makes the program more understandable.
* Because refactoring makes a design cleaner, it helps the programmers understand codes better and see things that may have not been seen before.
* Refactoring helps spot bugs since it makes the software more comprehensible.
* Refactoring turns an adverse design into a good design, which allows for rapid software development.

__TOC__

=='''Peer Reviewing'''==
It is the process of evaluating work done by an individual or a team by another team or an individual with expertise in the concerned area.
Types of Reviewing Strategies in Expertiza -

* Instructor Selected Reviewing - Using this strategy the instructor assigns reviews to all participants of the assignment. After selecting this strategy the instructor has the following two options -
** Set number of reviews done by each student.
** Set minimum number of reviews done for each submission.
Then the instructor can click on assign reviewers and map the students to the topics which should be reviewed by them.

[[File:editing_assignment.png‎ |frame|center|Instructor selected Reviewing]]

* Auto Selected Reviewing - If the instructor selects this strategy, students need to select reviews themselves. Either the student is given a list of topics to choose from and he selects which topic he wants to review, or he checks “I don’t care which topic I review” and he/she will be randomly assigned a topic to review. The instructor can also specify two parameters after selecting this strategy -
** Review topic threshold: - Let us assume Topic 1 has a submission than has not been reviewed. Topic 2 has submissions that has been reviewed atleast 2 times and k is set 2. Then the student will not be able to select topic 2 until all of topic 1’s submission has been reviewed atleast 2 times.
** Maximum number of reviews per submission: - This specifies the maximum number of times a particular top can be reviewed.

[[File:editing_assignment_2.png‎ |frame|center|Auto selected Reviewing]]

* Student Selected Reviewing -
In this strategy the student selects a particular submission to review instead of a particular topic. This feature had never been used and did not work correctly. Hence it has been removed from the system. However there are a lot of places where the code for student selected reviewing exists however it not being called anywhere.

=='''Project Resources'''==
* [https://github.com/rahuja910/expertiza GitHub Repository]
* [https://github.com/expertiza/expertiza/pull/602 GitHub Pull Request Link]
* [http://152.46.20.183:3000/ VCL Deployment Link] (For Instructor - username: instructor6, password: password. For student - username: student5700, password: password)

=='''Problem Statement'''==
==='''Classes involved'''===
dynamic_quiz_assignment_helper.rb
dynamic_review_assignment_helper.rb

==='''What it does''' ===
dynamic_review_assignment_helper.rb allows the system choose a team to review when a student chooses a topic to review. It helps the code choose topics that have submissions with fewer reviews than other topics. A threshold k is used to decide whether a particular topic can be chosen. If, e.g., Topic 1 has a submission that has not yet been reviewed, and Topic 2 has no submission that has been reviewed by fewer than 3 reviewers, then the incoming reviewer can only choose Topic 2 if k ≥ 3. This class does not actually decide what is reviewable, but it does make up a sorted list of the submissions by the number of the reviews they have. dynamic_quiz_assignment_helper.rb is similar, but for quizzes.

==='''What needed to be done'''===
* Remove the code for “student-selected” reviewing
* The find_submissions_in_current_cycle method returns a list of participants. It should return a list of teams.
* Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes
* The two classes have a lot of duplicated code. Remove all DRY problems.

==='''Change in problem statement'''===

While making changes to the helper classes to remove student selected reviewing, a commit was made to the expertiza repository which deleted the page for student selected reviewing.
https://github.com/expertiza/expertiza/commit/b62182b4bb42f563ba3cee88917119be378db439

In student-selected reviewing, a student was allowed to review a particular submission and not just a particular topic.The functionality for “student-selected” reviewing was never implemented successfully. Hence, the methods corresponding to the aforementioned functionality was needed to be removed.

=='''Modification of find_submissions_in_current_cycle method'''==

This function returns a list of participants for the particular assignment. This leads to redundant entries in the hash since most teams are made up of more than one member. Earlier the submissions belonged to participants rather than teams, however currently there is no need for this since if an instructor wants individual assignments he/she simply selects maximum number of size of a team as one. Correspondingly changes need to be made to the call sites.

* Before Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentParticipant.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
users = TeamsUser.where(team_id: signUp.team_id)
users.each do |user|
participant = Participant.where(user_id: user_id, parent_id: @assignment_id)
if participant
submissions_in_current_cycle << participant
end
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

* After Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentTeam.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
team=Team.where(team_id: signUp.team_id)
if team
submissions_in_current_cycle << team
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

As seen from the above code we have replaced AssignmentParticipant with AssignmentTeam. Now submissions_in_current_cycle will contain list of participants rather than a list of teams. Also note the model for AssignmentTeam contains the same methods which are present in the model for AssignmentParticipant. In the same helper class we had to modify code to handle the aspect that submissions_in_current_cycle now contains teams rather than participants. Hence we made changes in build_submissions_availability().

=='''Implementation of Criteria'''==
'''Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes.''' 
The helper classes while returning a list of teams should check the below set of conditions. Each of the below conditions need to be checked at one place to ensure better code readability and maintainability.

* The article was not written by the potential reviewer.
The potential reviewer should not be able to review its own submission and hence a check for this condition is required. However, it was already implemented in the code beforehand.

* The article was not already reviewed by the potential reviewer.
The potential reviewer should not be able to review a topic which is already reviewed by him/her. The same was also implemented along with the above condition.

* The article is not on the same topic as the potential reviewer has previously written about.
The reviewer should not be able to review on the same topic that he/she submitted as the reviewer could give biased reviews to make his/her own submission seem better. This was not implemented previously and was implemented in the code changes by checking the topic id.

'''Implementation :''' 
<pre>
def self.build_submissions_availability()
least_review_count = -1;
max_no_reviews = 5
reviewer_teams=TeamsUser.where(user_id: @reviewer_id)

@submissions_availability = Hash.new
unless @submissions_in_current_cycle.nil?
@submissions_in_current_cycle.each { |submission|
team_check=false
if( least_review_count == -1)
least_review_count = submission[1]
end
reviewer_teams.each do |reviewer_team|
if submission[0] == reviewer_team.team_id
team_check=true
end
end

if !team_check
@submissions_availability[submission[0]] = get_state(least_review_count,submission[1],max_no_reviews)
end
}
end
return @submissions_availability
end
</pre>

* The article does not already have the maximum number of potential reviews in progress.
The reviewer should only be able to review topics that have not reached the maximum number of reviews. The check for the same is done in get_state method where the current_review_count is compared with max_review_count and make it unavailable.

* The article has the minimum number of reviews for that assignment.
The article is made available if it has the minimum number of reviews for the assignment and the same is checked in get_state method where the current_review_count is compared with least_review_count and make it available.

'''Implementation:''' 
<pre>
def self.get_state(least_review_count,current_review_count,max_review_count)
if(current_review_count != -1 && current_review_count == max_review_count)
return -1
elsif(current_review_count != -1 && current_review_count > least_review_count)
return 1
elsif(current_review_count != -1 && current_review_count == least_review_count)
return 0
end
end
</pre>

=='''Deletion of "student-selected" reviewing'''==
The following files had code for “student-selected” reviewing –

* dynamic_quiz_assignment_helper.rb
* dynamic_review_assignment_helper.rb
* review_mapping_controller.rb

In this page the method show_available_submissions() in review_mapping_controller.rb was being called. Since this was the only place the method was being called we decided to delete the below code snippet.

def show_available_submissions
assignment = Assignment.find(params[:assignment_id])
reviewer = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
requested_topic_id = params[:topic_id]
@available_submissions = Hash.new
@available_submissions = DynamicReviewAssignmentHelper::review_assignment(assignment.id ,
reviewer.id,
requested_topic_id ,
Assignment::RS_STUDENT_SELECTED)

Also, this is the only call being made to dynamic_review_assignment_helper.rb and this helper is not used in instructor selected and auto selected reviewing strategies. For these strategies another view is being rendered specifically _set_dynamic_review.html.erb.
Similarly dynamic_quiz_assignment_helper.rb is also not being used by any controller.
Hence the two helper files have been deleted after confirmation from the developer.

=='''Design Patterns'''==

The project involved refactoring code which was used for student selected reviewing. However since this feature was removed from Expertiza during the refactoring, we had to delete the code and hence no design pattern is applicable.

=='''Testing'''==

Since we have deleted t

Creating an Assignment:
#Login using instructor.
# Go to Manage-->Assignments-->New Public Assignment
# Add couple of topics to the assignments from the topics tab.
# Check “Allow reviewer to choose which topic to review” and “Enable authors to review others working on same topic” in the same tab.
# Choose the review strategy as Auto-Selected in Review Strategy tab.
# Choose appropriate deadlines in the due dates tab.
# Go to Manage-->Assignments--><Your Assignment Name>
# Add participants to the assignment.

Signing up and submitting the Assignment:
# Login using participant1. Select the Assignment from the list of assignments.
# Sign up for a topic.
# Submit your work before the deadline.
# Repeat the same for all participants.

Reviewing work of other Participants:
# Login using participants. Select the Assignment from the list of assignments.
# Click on Other’s Work. You will see a list of topics which are eligible for reviewing.

Validation Criteria:
# You should not be able to review your own submission
# You can review other submissions of the topic if you have checked “Enable authors to review others working on the same topic” while creating the assignment.
# You should not be able to review a submission which has already been reviewed by you.
# You should not be able to review a submission which has reached maximum number of potential reviews.

=='''References'''==
<references/>

CSC/ECE 517 Fall 2015/oss E1552 NFR

2015-11-07T04:53:13Z

Rahuja: /* Change in problem statement */

'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb'''
=='''Overview'''==
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure
<ref>Refactoring: Improving the Design of Existing Code -
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Robert
[https://books.google.com/books/about/Refactoring.html?id=HmrDHwgkbPsC&printsec=frontcover&source=kp_read_button#v=onepage&q&f=false]</ref>. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
There are many benefits of refactoring as follows:
<ref>Refactoring Software using Design Patterns - by Masatomo Noborikawa
[http://www.cs.uni.edu/~wallingf/miscellaneous/student-papers/noborikawa-paper.pdf]</ref>

* Refactoring improves the design of software. Refactoring often cleans up codes by deleting duplicates, divides a big chunk of codes into several methods, and makes the program more understandable.
* Because refactoring makes a design cleaner, it helps the programmers understand codes better and see things that may have not been seen before.
* Refactoring helps spot bugs since it makes the software more comprehensible.
* Refactoring turns an adverse design into a good design, which allows for rapid software development.

__TOC__

=='''Peer Reviewing'''==
It is the process of evaluating work done by an individual or a team by another team or an individual with expertise in the concerned area.
Types of Reviewing Strategies in Expertiza -

* Instructor Selected Reviewing - Using this strategy the instructor assigns reviews to all participants of the assignment. After selecting this strategy the instructor has the following two options -
** Set number of reviews done by each student.
** Set minimum number of reviews done for each submission.
Then the instructor can click on assign reviewers and map the students to the topics which should be reviewed by them.

[[File:editing_assignment.png‎ |frame|center|Instructor selected Reviewing]]

* Auto Selected Reviewing - If the instructor selects this strategy, students need to select reviews themselves. Either the student is given a list of topics to choose from and he selects which topic he wants to review, or he checks “I don’t care which topic I review” and he/she will be randomly assigned a topic to review. The instructor can also specify two parameters after selecting this strategy -
** Review topic threshold: - Let us assume Topic 1 has a submission than has not been reviewed. Topic 2 has submissions that has been reviewed atleast 2 times and k is set 2. Then the student will not be able to select topic 2 until all of topic 1’s submission has been reviewed atleast 2 times.
** Maximum number of reviews per submission: - This specifies the maximum number of times a particular top can be reviewed.

[[File:editing_assignment_2.png‎ |frame|center|Auto selected Reviewing]]

* Student Selected Reviewing -
In this strategy the student selects a particular submission to review instead of a particular topic. This feature had never been used and did not work correctly. Hence it has been removed from the system. However there are a lot of places where the code for student selected reviewing exists however it not being called anywhere.

=='''Project Resources'''==
* [https://github.com/rahuja910/expertiza GitHub Repository]
* [https://github.com/expertiza/expertiza/pull/602 GitHub Pull Request Link]
* [http://152.46.20.183:3000/ VCL Deployment Link] (For Instructor - username: instructor6, password: password. For student - username: student5700, password: password)

=='''Problem Statement'''==
==='''Classes involved'''===
dynamic_quiz_assignment_helper.rb
dynamic_review_assignment_helper.rb

==='''What it does''' ===
dynamic_review_assignment_helper.rb allows the system choose a team to review when a student chooses a topic to review. It helps the code choose topics that have submissions with fewer reviews than other topics. A threshold k is used to decide whether a particular topic can be chosen. If, e.g., Topic 1 has a submission that has not yet been reviewed, and Topic 2 has no submission that has been reviewed by fewer than 3 reviewers, then the incoming reviewer can only choose Topic 2 if k ≥ 3. This class does not actually decide what is reviewable, but it does make up a sorted list of the submissions by the number of the reviews they have. dynamic_quiz_assignment_helper.rb is similar, but for quizzes.

==='''What needed to be done'''===
* Remove the code for “student-selected” reviewing
* The find_submissions_in_current_cycle method returns a list of participants. It should return a list of teams.
* Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes
* The two classes have a lot of duplicated code. Remove all DRY problems.

==='''Change in problem statement'''===

While making changes to the helper classes to remove student selected reviewing, a commit was made to the expertiza repository which deleted the page for student selected reviewing.
https://github.com/expertiza/expertiza/commit/b62182b4bb42f563ba3cee88917119be378db439

In student-selected reviewing, a student was allowed to review a particular submission and not just a particular topic.The functionality for “student-selected” reviewing was never implemented successfully. Hence, the methods corresponding to the aforementioned functionality were removed from respective files.

=='''Modification of find_submissions_in_current_cycle method'''==

This function returns a list of participants for the particular assignment. This leads to redundant entries in the hash since most teams are made up of more than one member. Earlier the submissions belonged to participants rather than teams, however currently there is no need for this since if an instructor wants individual assignments he/she simply selects maximum number of size of a team as one. Correspondingly changes need to be made to the call sites.

* Before Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentParticipant.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
users = TeamsUser.where(team_id: signUp.team_id)
users.each do |user|
participant = Participant.where(user_id: user_id, parent_id: @assignment_id)
if participant
submissions_in_current_cycle << participant
end
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

* After Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentTeam.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
team=Team.where(team_id: signUp.team_id)
if team
submissions_in_current_cycle << team
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

As seen from the above code we have replaced AssignmentParticipant with AssignmentTeam. Now submissions_in_current_cycle will contain list of participants rather than a list of teams. Also note the model for AssignmentTeam contains the same methods which are present in the model for AssignmentParticipant. In the same helper class we had to modify code to handle the aspect that submissions_in_current_cycle now contains teams rather than participants. Hence we made changes in build_submissions_availability().

=='''Implementation of Criteria'''==
'''Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes.''' 
The helper classes while returning a list of teams should check the below set of conditions. Each of the below conditions need to be checked at one place to ensure better code readability and maintainability.

* The article was not written by the potential reviewer.
The potential reviewer should not be able to review its own submission and hence a check for this condition is required. However, it was already implemented in the code beforehand.

* The article was not already reviewed by the potential reviewer.
The potential reviewer should not be able to review a topic which is already reviewed by him/her. The same was also implemented along with the above condition.

* The article is not on the same topic as the potential reviewer has previously written about.
The reviewer should not be able to review on the same topic that he/she submitted as the reviewer could give biased reviews to make his/her own submission seem better. This was not implemented previously and was implemented in the code changes by checking the topic id.

'''Implementation :''' 
<pre>
def self.build_submissions_availability()
least_review_count = -1;
max_no_reviews = 5
reviewer_teams=TeamsUser.where(user_id: @reviewer_id)

@submissions_availability = Hash.new
unless @submissions_in_current_cycle.nil?
@submissions_in_current_cycle.each { |submission|
team_check=false
if( least_review_count == -1)
least_review_count = submission[1]
end
reviewer_teams.each do |reviewer_team|
if submission[0] == reviewer_team.team_id
team_check=true
end
end

if !team_check
@submissions_availability[submission[0]] = get_state(least_review_count,submission[1],max_no_reviews)
end
}
end
return @submissions_availability
end
</pre>

* The article does not already have the maximum number of potential reviews in progress.
The reviewer should only be able to review topics that have not reached the maximum number of reviews. The check for the same is done in get_state method where the current_review_count is compared with max_review_count and make it unavailable.

* The article has the minimum number of reviews for that assignment.
The article is made available if it has the minimum number of reviews for the assignment and the same is checked in get_state method where the current_review_count is compared with least_review_count and make it available.

'''Implementation:''' 
<pre>
def self.get_state(least_review_count,current_review_count,max_review_count)
if(current_review_count != -1 && current_review_count == max_review_count)
return -1
elsif(current_review_count != -1 && current_review_count > least_review_count)
return 1
elsif(current_review_count != -1 && current_review_count == least_review_count)
return 0
end
end
</pre>

=='''Deletion of "student-selected" reviewing'''==
The following files had code for “student-selected” reviewing –

* dynamic_quiz_assignment_helper.rb
* dynamic_review_assignment_helper.rb
* review_mapping_controller.rb

In this page the method show_available_submissions() in review_mapping_controller.rb was being called. Since this was the only place the method was being called we decided to delete the below code snippet.

def show_available_submissions
assignment = Assignment.find(params[:assignment_id])
reviewer = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
requested_topic_id = params[:topic_id]
@available_submissions = Hash.new
@available_submissions = DynamicReviewAssignmentHelper::review_assignment(assignment.id ,
reviewer.id,
requested_topic_id ,
Assignment::RS_STUDENT_SELECTED)

Also, this is the only call being made to dynamic_review_assignment_helper.rb and this helper is not used in instructor selected and auto selected reviewing strategies. For these strategies another view is being rendered specifically _set_dynamic_review.html.erb.
Similarly dynamic_quiz_assignment_helper.rb is also not being used by any controller.
Hence the two helper files have been deleted after confirmation from the developer.

=='''Design Patterns'''==

The project involved refactoring code which was used for student selected reviewing. However since this feature was removed from Expertiza during the refactoring, we had to delete the code and hence no design pattern is applicable.

=='''Testing'''==

Since we have deleted t

Creating an Assignment:
#Login using instructor.
# Go to Manage-->Assignments-->New Public Assignment
# Add couple of topics to the assignments from the topics tab.
# Check “Allow reviewer to choose which topic to review” and “Enable authors to review others working on same topic” in the same tab.
# Choose the review strategy as Auto-Selected in Review Strategy tab.
# Choose appropriate deadlines in the due dates tab.
# Go to Manage-->Assignments--><Your Assignment Name>
# Add participants to the assignment.

Signing up and submitting the Assignment:
# Login using participant1. Select the Assignment from the list of assignments.
# Sign up for a topic.
# Submit your work before the deadline.
# Repeat the same for all participants.

Reviewing work of other Participants:
# Login using participants. Select the Assignment from the list of assignments.
# Click on Other’s Work. You will see a list of topics which are eligible for reviewing.

Validation Criteria:
# You should not be able to review your own submission
# You can review other submissions of the topic if you have checked “Enable authors to review others working on the same topic” while creating the assignment.
# You should not be able to review a submission which has already been reviewed by you.
# You should not be able to review a submission which has reached maximum number of potential reviews.

=='''References'''==
<references/>

CSC/ECE 517 Fall 2015/oss E1552 NFR

2015-11-07T04:52:15Z

Rahuja:

'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb'''
=='''Overview'''==
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure
<ref>Refactoring: Improving the Design of Existing Code -
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Robert
[https://books.google.com/books/about/Refactoring.html?id=HmrDHwgkbPsC&printsec=frontcover&source=kp_read_button#v=onepage&q&f=false]</ref>. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
There are many benefits of refactoring as follows:
<ref>Refactoring Software using Design Patterns - by Masatomo Noborikawa
[http://www.cs.uni.edu/~wallingf/miscellaneous/student-papers/noborikawa-paper.pdf]</ref>

* Refactoring improves the design of software. Refactoring often cleans up codes by deleting duplicates, divides a big chunk of codes into several methods, and makes the program more understandable.
* Because refactoring makes a design cleaner, it helps the programmers understand codes better and see things that may have not been seen before.
* Refactoring helps spot bugs since it makes the software more comprehensible.
* Refactoring turns an adverse design into a good design, which allows for rapid software development.

__TOC__

=='''Peer Reviewing'''==
It is the process of evaluating work done by an individual or a team by another team or an individual with expertise in the concerned area.
Types of Reviewing Strategies in Expertiza -

* Instructor Selected Reviewing - Using this strategy the instructor assigns reviews to all participants of the assignment. After selecting this strategy the instructor has the following two options -
** Set number of reviews done by each student.
** Set minimum number of reviews done for each submission.
Then the instructor can click on assign reviewers and map the students to the topics which should be reviewed by them.

[[File:editing_assignment.png‎ |frame|center|Instructor selected Reviewing]]

* Auto Selected Reviewing - If the instructor selects this strategy, students need to select reviews themselves. Either the student is given a list of topics to choose from and he selects which topic he wants to review, or he checks “I don’t care which topic I review” and he/she will be randomly assigned a topic to review. The instructor can also specify two parameters after selecting this strategy -
** Review topic threshold: - Let us assume Topic 1 has a submission than has not been reviewed. Topic 2 has submissions that has been reviewed atleast 2 times and k is set 2. Then the student will not be able to select topic 2 until all of topic 1’s submission has been reviewed atleast 2 times.
** Maximum number of reviews per submission: - This specifies the maximum number of times a particular top can be reviewed.

[[File:editing_assignment_2.png‎ |frame|center|Auto selected Reviewing]]

* Student Selected Reviewing -
In this strategy the student selects a particular submission to review instead of a particular topic. This feature had never been used and did not work correctly. Hence it has been removed from the system. However there are a lot of places where the code for student selected reviewing exists however it not being called anywhere.

=='''Project Resources'''==
* [https://github.com/rahuja910/expertiza GitHub Repository]
* [https://github.com/expertiza/expertiza/pull/602 GitHub Pull Request Link]
* [http://152.46.20.183:3000/ VCL Deployment Link] (For Instructor - username: instructor6, password: password. For student - username: student5700, password: password)

=='''Problem Statement'''==
==='''Classes involved'''===
dynamic_quiz_assignment_helper.rb
dynamic_review_assignment_helper.rb

==='''What it does''' ===
dynamic_review_assignment_helper.rb allows the system choose a team to review when a student chooses a topic to review. It helps the code choose topics that have submissions with fewer reviews than other topics. A threshold k is used to decide whether a particular topic can be chosen. If, e.g., Topic 1 has a submission that has not yet been reviewed, and Topic 2 has no submission that has been reviewed by fewer than 3 reviewers, then the incoming reviewer can only choose Topic 2 if k ≥ 3. This class does not actually decide what is reviewable, but it does make up a sorted list of the submissions by the number of the reviews they have. dynamic_quiz_assignment_helper.rb is similar, but for quizzes.

==='''What needed to be done'''===
* Remove the code for “student-selected” reviewing
* The find_submissions_in_current_cycle method returns a list of participants. It should return a list of teams.
* Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes
* The two classes have a lot of duplicated code. Remove all DRY problems.

==='''Change in problem statement'''===

In student-selected reviewing, a student was allowed to review a particular submission and not just a particular topic.The functionality for “student-selected” reviewing was never implemented successfully. Hence, the methods corresponding to the aforementioned functionality were removed from respective files.

While making changes to the helper classes to remove student selected reviewing, a commit was made to the expertiza repository which deleted the page for student selected reviewing.
https://github.com/expertiza/expertiza/commit/b62182b4bb42f563ba3cee88917119be378db439

=='''Modification of find_submissions_in_current_cycle method'''==

This function returns a list of participants for the particular assignment. This leads to redundant entries in the hash since most teams are made up of more than one member. Earlier the submissions belonged to participants rather than teams, however currently there is no need for this since if an instructor wants individual assignments he/she simply selects maximum number of size of a team as one. Correspondingly changes need to be made to the call sites.

* Before Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentParticipant.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
users = TeamsUser.where(team_id: signUp.team_id)
users.each do |user|
participant = Participant.where(user_id: user_id, parent_id: @assignment_id)
if participant
submissions_in_current_cycle << participant
end
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

* After Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentTeam.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
team=Team.where(team_id: signUp.team_id)
if team
submissions_in_current_cycle << team
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

As seen from the above code we have replaced AssignmentParticipant with AssignmentTeam. Now submissions_in_current_cycle will contain list of participants rather than a list of teams. Also note the model for AssignmentTeam contains the same methods which are present in the model for AssignmentParticipant. In the same helper class we had to modify code to handle the aspect that submissions_in_current_cycle now contains teams rather than participants. Hence we made changes in build_submissions_availability().

=='''Implementation of Criteria'''==
'''Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes.''' 
The helper classes while returning a list of teams should check the below set of conditions. Each of the below conditions need to be checked at one place to ensure better code readability and maintainability.

* The article was not written by the potential reviewer.
The potential reviewer should not be able to review its own submission and hence a check for this condition is required. However, it was already implemented in the code beforehand.

* The article was not already reviewed by the potential reviewer.
The potential reviewer should not be able to review a topic which is already reviewed by him/her. The same was also implemented along with the above condition.

* The article is not on the same topic as the potential reviewer has previously written about.
The reviewer should not be able to review on the same topic that he/she submitted as the reviewer could give biased reviews to make his/her own submission seem better. This was not implemented previously and was implemented in the code changes by checking the topic id.

'''Implementation :''' 
<pre>
def self.build_submissions_availability()
least_review_count = -1;
max_no_reviews = 5
reviewer_teams=TeamsUser.where(user_id: @reviewer_id)

@submissions_availability = Hash.new
unless @submissions_in_current_cycle.nil?
@submissions_in_current_cycle.each { |submission|
team_check=false
if( least_review_count == -1)
least_review_count = submission[1]
end
reviewer_teams.each do |reviewer_team|
if submission[0] == reviewer_team.team_id
team_check=true
end
end

if !team_check
@submissions_availability[submission[0]] = get_state(least_review_count,submission[1],max_no_reviews)
end
}
end
return @submissions_availability
end
</pre>

* The article does not already have the maximum number of potential reviews in progress.
The reviewer should only be able to review topics that have not reached the maximum number of reviews. The check for the same is done in get_state method where the current_review_count is compared with max_review_count and make it unavailable.

* The article has the minimum number of reviews for that assignment.
The article is made available if it has the minimum number of reviews for the assignment and the same is checked in get_state method where the current_review_count is compared with least_review_count and make it available.

'''Implementation:''' 
<pre>
def self.get_state(least_review_count,current_review_count,max_review_count)
if(current_review_count != -1 && current_review_count == max_review_count)
return -1
elsif(current_review_count != -1 && current_review_count > least_review_count)
return 1
elsif(current_review_count != -1 && current_review_count == least_review_count)
return 0
end
end
</pre>

=='''Deletion of "student-selected" reviewing'''==
The following files had code for “student-selected” reviewing –

* dynamic_quiz_assignment_helper.rb
* dynamic_review_assignment_helper.rb
* review_mapping_controller.rb

In this page the method show_available_submissions() in review_mapping_controller.rb was being called. Since this was the only place the method was being called we decided to delete the below code snippet.

def show_available_submissions
assignment = Assignment.find(params[:assignment_id])
reviewer = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
requested_topic_id = params[:topic_id]
@available_submissions = Hash.new
@available_submissions = DynamicReviewAssignmentHelper::review_assignment(assignment.id ,
reviewer.id,
requested_topic_id ,
Assignment::RS_STUDENT_SELECTED)

Also, this is the only call being made to dynamic_review_assignment_helper.rb and this helper is not used in instructor selected and auto selected reviewing strategies. For these strategies another view is being rendered specifically _set_dynamic_review.html.erb.
Similarly dynamic_quiz_assignment_helper.rb is also not being used by any controller.
Hence the two helper files have been deleted after confirmation from the developer.

=='''Design Patterns'''==

The project involved refactoring code which was used for student selected reviewing. However since this feature was removed from Expertiza during the refactoring, we had to delete the code and hence no design pattern is applicable.

=='''Testing'''==

Since we have deleted t

Creating an Assignment:
#Login using instructor.
# Go to Manage-->Assignments-->New Public Assignment
# Add couple of topics to the assignments from the topics tab.
# Check “Allow reviewer to choose which topic to review” and “Enable authors to review others working on same topic” in the same tab.
# Choose the review strategy as Auto-Selected in Review Strategy tab.
# Choose appropriate deadlines in the due dates tab.
# Go to Manage-->Assignments--><Your Assignment Name>
# Add participants to the assignment.

Signing up and submitting the Assignment:
# Login using participant1. Select the Assignment from the list of assignments.
# Sign up for a topic.
# Submit your work before the deadline.
# Repeat the same for all participants.

Reviewing work of other Participants:
# Login using participants. Select the Assignment from the list of assignments.
# Click on Other’s Work. You will see a list of topics which are eligible for reviewing.

Validation Criteria:
# You should not be able to review your own submission
# You can review other submissions of the topic if you have checked “Enable authors to review others working on the same topic” while creating the assignment.
# You should not be able to review a submission which has already been reviewed by you.
# You should not be able to review a submission which has reached maximum number of potential reviews.

=='''References'''==
<references/>

CSC/ECE 517 Fall 2015/oss E1552 NFR

2015-11-07T04:47:28Z

Rahuja: /* Classes involved */

'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb'''
=='''Overview'''==
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure
<ref>Refactoring: Improving the Design of Existing Code -
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Robert
[https://books.google.com/books/about/Refactoring.html?id=HmrDHwgkbPsC&printsec=frontcover&source=kp_read_button#v=onepage&q&f=false]</ref>. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
There are many benefits of refactoring as follows:
<ref>Refactoring Software using Design Patterns - by Masatomo Noborikawa
[http://www.cs.uni.edu/~wallingf/miscellaneous/student-papers/noborikawa-paper.pdf]</ref>

* Refactoring improves the design of software. Refactoring often cleans up codes by deleting duplicates, divides a big chunk of codes into several methods, and makes the program more understandable.
* Because refactoring makes a design cleaner, it helps the programmers understand codes better and see things that may have not been seen before.
* Refactoring helps spot bugs since it makes the software more comprehensible.
* Refactoring turns an adverse design into a good design, which allows for rapid software development.

__TOC__

=='''Peer Reviewing'''==
It is the process of evaluating work done by an individual or a team by another team or an individual with expertise in the concerned area.
Types of Reviewing Strategies in Expertiza -

* Instructor Selected Reviewing - Using this strategy the instructor assigns reviews to all participants of the assignment. After selecting this strategy the instructor has the following two options -
** Set number of reviews done by each student.
** Set minimum number of reviews done for each submission.
Then the instructor can click on assign reviewers and map the students to the topics which should be reviewed by them.

[[File:editing_assignment.png‎ |frame|center|Instructor selected Reviewing]]

* Auto Selected Reviewing - If the instructor selects this strategy, students need to select reviews themselves. Either the student is given a list of topics to choose from and he selects which topic he wants to review, or he checks “I don’t care which topic I review” and he/she will be randomly assigned a topic to review. The instructor can also specify two parameters after selecting this strategy -
** Review topic threshold: - Let us assume Topic 1 has a submission than has not been reviewed. Topic 2 has submissions that has been reviewed atleast 2 times and k is set 2. Then the student will not be able to select topic 2 until all of topic 1’s submission has been reviewed atleast 2 times.
** Maximum number of reviews per submission: - This specifies the maximum number of times a particular top can be reviewed.

[[File:editing_assignment_2.png‎ |frame|center|Auto selected Reviewing]]

* Student Selected Reviewing -
In this strategy the student selects a particular submission to review instead of a particular topic. This feature had never been used and did not work correctly. Hence it has been removed from the system. However there are a lot of places where the code for student selected reviewing exists however it not being called anywhere.

=='''Project Resources'''==
* [https://github.com/rahuja910/expertiza GitHub Repository]
* [https://github.com/expertiza/expertiza/pull/602 GitHub Pull Request Link]
* [http://152.46.20.183:3000/ VCL Deployment Link] (For Instructor - username: instructor6, password: password. For student - username: student5700, password: password)

=='''Problem Statement'''==
==='''Classes involved'''===
dynamic_quiz_assignment_helper.rb
dynamic_review_assignment_helper.rb

==='''What it does''' ===
dynamic_review_assignment_helper.rb allows the system choose a team to review when a student chooses a topic to review. It helps the code choose topics that have submissions with fewer reviews than other topics. A threshold k is used to decide whether a particular topic can be chosen. If, e.g., Topic 1 has a submission that has not yet been reviewed, and Topic 2 has no submission that has been reviewed by fewer than 3 reviewers, then the incoming reviewer can only choose Topic 2 if k ≥ 3. This class does not actually decide what is reviewable, but it does make up a sorted list of the submissions by the number of the reviews they have. dynamic_quiz_assignment_helper.rb is similar, but for quizzes.

==='''What needs to be done'''===
* Remove the code for “student-selected” reviewing
* The find_submissions_in_current_cycle method returns a list of participants. It should return a list of teams.
* Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes
* The two classes have a lot of duplicated code. Remove all DRY problems.

=='''Modification of find_submissions_in_current_cycle method'''==

This function returns a list of participants for the particular assignment. This leads to redundant entries in the hash since most teams are made up of more than one member. Earlier the submissions belonged to participants rather than teams, however currently there is no need for this since if an instructor wants individual assignments he/she simply selects maximum number of size of a team as one. Correspondingly changes need to be made to the call sites.

* Before Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentParticipant.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
users = TeamsUser.where(team_id: signUp.team_id)
users.each do |user|
participant = Participant.where(user_id: user_id, parent_id: @assignment_id)
if participant
submissions_in_current_cycle << participant
end
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

* After Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentTeam.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
team=Team.where(team_id: signUp.team_id)
if team
submissions_in_current_cycle << team
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

As seen from the above code we have replaced AssignmentParticipant with AssignmentTeam. Now submissions_in_current_cycle will contain list of participants rather than a list of teams. Also note the model for AssignmentTeam contains the same methods which are present in the model for AssignmentParticipant. In the same helper class we had to modify code to handle the aspect that submissions_in_current_cycle now contains teams rather than participants. Hence we made changes in build_submissions_availability().

=='''Implementation of Criteria'''==
'''Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes.''' 
The helper classes while returning a list of teams should check the below set of conditions. Each of the below conditions need to be checked at one place to ensure better code readability and maintainability.

* The article was not written by the potential reviewer.
The potential reviewer should not be able to review its own submission and hence a check for this condition is required. However, it was already implemented in the code beforehand.

* The article was not already reviewed by the potential reviewer.
The potential reviewer should not be able to review a topic which is already reviewed by him/her. The same was also implemented along with the above condition.

* The article is not on the same topic as the potential reviewer has previously written about.
The reviewer should not be able to review on the same topic that he/she submitted as the reviewer could give biased reviews to make his/her own submission seem better. This was not implemented previously and was implemented in the code changes by checking the topic id.

'''Implementation :''' 
<pre>
def self.build_submissions_availability()
least_review_count = -1;
max_no_reviews = 5
reviewer_teams=TeamsUser.where(user_id: @reviewer_id)

@submissions_availability = Hash.new
unless @submissions_in_current_cycle.nil?
@submissions_in_current_cycle.each { |submission|
team_check=false
if( least_review_count == -1)
least_review_count = submission[1]
end
reviewer_teams.each do |reviewer_team|
if submission[0] == reviewer_team.team_id
team_check=true
end
end

if !team_check
@submissions_availability[submission[0]] = get_state(least_review_count,submission[1],max_no_reviews)
end
}
end
return @submissions_availability
end
</pre>

* The article does not already have the maximum number of potential reviews in progress.
The reviewer should only be able to review topics that have not reached the maximum number of reviews. The check for the same is done in get_state method where the current_review_count is compared with max_review_count and make it unavailable.

* The article has the minimum number of reviews for that assignment.
The article is made available if it has the minimum number of reviews for the assignment and the same is checked in get_state method where the current_review_count is compared with least_review_count and make it available.

'''Implementation:''' 
<pre>
def self.get_state(least_review_count,current_review_count,max_review_count)
if(current_review_count != -1 && current_review_count == max_review_count)
return -1
elsif(current_review_count != -1 && current_review_count > least_review_count)
return 1
elsif(current_review_count != -1 && current_review_count == least_review_count)
return 0
end
end
</pre>

=='''Deletion of "student-selected" reviewing'''==
The following files had code for “student-selected” reviewing –

* dynamic_quiz_assignment_helper.rb
* dynamic_review_assignment_helper.rb
* review_mapping_controller.rb

In student-selected reviewing, a student was allowed to review a particular submission and not just a particular topic.The functionality for “student-selected” reviewing was never implemented successfully. Hence, the methods corresponding to the aforementioned functionality were removed from respective files.

While making changes to the helper classes to remove student selected reviewing, a commit was made to the expertiza repository which deleted the page for student selected reviewing.
https://github.com/expertiza/expertiza/commit/b62182b4bb42f563ba3cee88917119be378db439

In this page the method show_available_submissions() in review_mapping_controller.rb was being called. Since this was the only place the method was being called we decided to delete the below code snippet.

def show_available_submissions
assignment = Assignment.find(params[:assignment_id])
reviewer = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
requested_topic_id = params[:topic_id]
@available_submissions = Hash.new
@available_submissions = DynamicReviewAssignmentHelper::review_assignment(assignment.id ,
reviewer.id,
requested_topic_id ,
Assignment::RS_STUDENT_SELECTED)

Also, this is the only call being made to dynamic_review_assignment_helper.rb and this helper is not used in instructor selected and auto selected reviewing strategies. For these strategies another view is being rendered specifically _set_dynamic_review.html.erb.
Similarly dynamic_quiz_assignment_helper.rb is also not being used by any controller.
Hence the two helper files have been deleted after confirmation from the developer.

=='''Design Patterns'''==

The project involved refactoring code which was used for student selected reviewing. However since this feature was removed from Expertiza during the refactoring, we had to delete the code and hence no design pattern is applicable.

=='''Testing'''==

Since we have deleted t

Creating an Assignment:
#Login using instructor.
# Go to Manage-->Assignments-->New Public Assignment
# Add couple of topics to the assignments from the topics tab.
# Check “Allow reviewer to choose which topic to review” and “Enable authors to review others working on same topic” in the same tab.
# Choose the review strategy as Auto-Selected in Review Strategy tab.
# Choose appropriate deadlines in the due dates tab.
# Go to Manage-->Assignments--><Your Assignment Name>
# Add participants to the assignment.

Signing up and submitting the Assignment:
# Login using participant1. Select the Assignment from the list of assignments.
# Sign up for a topic.
# Submit your work before the deadline.
# Repeat the same for all participants.

Reviewing work of other Participants:
# Login using participants. Select the Assignment from the list of assignments.
# Click on Other’s Work. You will see a list of topics which are eligible for reviewing.

Validation Criteria:
# You should not be able to review your own submission
# You can review other submissions of the topic if you have checked “Enable authors to review others working on the same topic” while creating the assignment.
# You should not be able to review a submission which has already been reviewed by you.
# You should not be able to review a submission which has reached maximum number of potential reviews.

=='''References'''==
<references/>

CSC/ECE 517 Fall 2015/oss E1552 NFR

2015-11-07T04:47:03Z

Rahuja:

'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb'''
=='''Overview'''==
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure
<ref>Refactoring: Improving the Design of Existing Code -
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Robert
[https://books.google.com/books/about/Refactoring.html?id=HmrDHwgkbPsC&printsec=frontcover&source=kp_read_button#v=onepage&q&f=false]</ref>. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
There are many benefits of refactoring as follows:
<ref>Refactoring Software using Design Patterns - by Masatomo Noborikawa
[http://www.cs.uni.edu/~wallingf/miscellaneous/student-papers/noborikawa-paper.pdf]</ref>

* Refactoring improves the design of software. Refactoring often cleans up codes by deleting duplicates, divides a big chunk of codes into several methods, and makes the program more understandable.
* Because refactoring makes a design cleaner, it helps the programmers understand codes better and see things that may have not been seen before.
* Refactoring helps spot bugs since it makes the software more comprehensible.
* Refactoring turns an adverse design into a good design, which allows for rapid software development.

__TOC__

=='''Peer Reviewing'''==
It is the process of evaluating work done by an individual or a team by another team or an individual with expertise in the concerned area.
Types of Reviewing Strategies in Expertiza -

* Instructor Selected Reviewing - Using this strategy the instructor assigns reviews to all participants of the assignment. After selecting this strategy the instructor has the following two options -
** Set number of reviews done by each student.
** Set minimum number of reviews done for each submission.
Then the instructor can click on assign reviewers and map the students to the topics which should be reviewed by them.

[[File:editing_assignment.png‎ |frame|center|Instructor selected Reviewing]]

* Auto Selected Reviewing - If the instructor selects this strategy, students need to select reviews themselves. Either the student is given a list of topics to choose from and he selects which topic he wants to review, or he checks “I don’t care which topic I review” and he/she will be randomly assigned a topic to review. The instructor can also specify two parameters after selecting this strategy -
** Review topic threshold: - Let us assume Topic 1 has a submission than has not been reviewed. Topic 2 has submissions that has been reviewed atleast 2 times and k is set 2. Then the student will not be able to select topic 2 until all of topic 1’s submission has been reviewed atleast 2 times.
** Maximum number of reviews per submission: - This specifies the maximum number of times a particular top can be reviewed.

[[File:editing_assignment_2.png‎ |frame|center|Auto selected Reviewing]]

* Student Selected Reviewing -
In this strategy the student selects a particular submission to review instead of a particular topic. This feature had never been used and did not work correctly. Hence it has been removed from the system. However there are a lot of places where the code for student selected reviewing exists however it not being called anywhere.

=='''Project Resources'''==
* [https://github.com/rahuja910/expertiza GitHub Repository]
* [https://github.com/expertiza/expertiza/pull/602 GitHub Pull Request Link]
* [http://152.46.20.183:3000/ VCL Deployment Link] (For Instructor - username: instructor6, password: password. For student - username: student5700, password: password)

=='''Problem Statement'''==
==='''Classes involved'''===
dynamic_quiz_assignment_helper.rb
dynamic_review_assignment_helper.rb
review_mapping_controller.rb

==='''What it does''' ===
dynamic_review_assignment_helper.rb allows the system choose a team to review when a student chooses a topic to review. It helps the code choose topics that have submissions with fewer reviews than other topics. A threshold k is used to decide whether a particular topic can be chosen. If, e.g., Topic 1 has a submission that has not yet been reviewed, and Topic 2 has no submission that has been reviewed by fewer than 3 reviewers, then the incoming reviewer can only choose Topic 2 if k ≥ 3. This class does not actually decide what is reviewable, but it does make up a sorted list of the submissions by the number of the reviews they have. dynamic_quiz_assignment_helper.rb is similar, but for quizzes.

==='''What needs to be done'''===
* Remove the code for “student-selected” reviewing
* The find_submissions_in_current_cycle method returns a list of participants. It should return a list of teams.
* Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes
* The two classes have a lot of duplicated code. Remove all DRY problems.

=='''Modification of find_submissions_in_current_cycle method'''==

This function returns a list of participants for the particular assignment. This leads to redundant entries in the hash since most teams are made up of more than one member. Earlier the submissions belonged to participants rather than teams, however currently there is no need for this since if an instructor wants individual assignments he/she simply selects maximum number of size of a team as one. Correspondingly changes need to be made to the call sites.

* Before Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentParticipant.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
users = TeamsUser.where(team_id: signUp.team_id)
users.each do |user|
participant = Participant.where(user_id: user_id, parent_id: @assignment_id)
if participant
submissions_in_current_cycle << participant
end
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

* After Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentTeam.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
team=Team.where(team_id: signUp.team_id)
if team
submissions_in_current_cycle << team
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

As seen from the above code we have replaced AssignmentParticipant with AssignmentTeam. Now submissions_in_current_cycle will contain list of participants rather than a list of teams. Also note the model for AssignmentTeam contains the same methods which are present in the model for AssignmentParticipant. In the same helper class we had to modify code to handle the aspect that submissions_in_current_cycle now contains teams rather than participants. Hence we made changes in build_submissions_availability().

=='''Implementation of Criteria'''==
'''Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes.''' 
The helper classes while returning a list of teams should check the below set of conditions. Each of the below conditions need to be checked at one place to ensure better code readability and maintainability.

* The article was not written by the potential reviewer.
The potential reviewer should not be able to review its own submission and hence a check for this condition is required. However, it was already implemented in the code beforehand.

* The article was not already reviewed by the potential reviewer.
The potential reviewer should not be able to review a topic which is already reviewed by him/her. The same was also implemented along with the above condition.

* The article is not on the same topic as the potential reviewer has previously written about.
The reviewer should not be able to review on the same topic that he/she submitted as the reviewer could give biased reviews to make his/her own submission seem better. This was not implemented previously and was implemented in the code changes by checking the topic id.

'''Implementation :''' 
<pre>
def self.build_submissions_availability()
least_review_count = -1;
max_no_reviews = 5
reviewer_teams=TeamsUser.where(user_id: @reviewer_id)

@submissions_availability = Hash.new
unless @submissions_in_current_cycle.nil?
@submissions_in_current_cycle.each { |submission|
team_check=false
if( least_review_count == -1)
least_review_count = submission[1]
end
reviewer_teams.each do |reviewer_team|
if submission[0] == reviewer_team.team_id
team_check=true
end
end

if !team_check
@submissions_availability[submission[0]] = get_state(least_review_count,submission[1],max_no_reviews)
end
}
end
return @submissions_availability
end
</pre>

* The article does not already have the maximum number of potential reviews in progress.
The reviewer should only be able to review topics that have not reached the maximum number of reviews. The check for the same is done in get_state method where the current_review_count is compared with max_review_count and make it unavailable.

* The article has the minimum number of reviews for that assignment.
The article is made available if it has the minimum number of reviews for the assignment and the same is checked in get_state method where the current_review_count is compared with least_review_count and make it available.

'''Implementation:''' 
<pre>
def self.get_state(least_review_count,current_review_count,max_review_count)
if(current_review_count != -1 && current_review_count == max_review_count)
return -1
elsif(current_review_count != -1 && current_review_count > least_review_count)
return 1
elsif(current_review_count != -1 && current_review_count == least_review_count)
return 0
end
end
</pre>

=='''Deletion of "student-selected" reviewing'''==
The following files had code for “student-selected” reviewing –

* dynamic_quiz_assignment_helper.rb
* dynamic_review_assignment_helper.rb
* review_mapping_controller.rb

In student-selected reviewing, a student was allowed to review a particular submission and not just a particular topic.The functionality for “student-selected” reviewing was never implemented successfully. Hence, the methods corresponding to the aforementioned functionality were removed from respective files.

While making changes to the helper classes to remove student selected reviewing, a commit was made to the expertiza repository which deleted the page for student selected reviewing.
https://github.com/expertiza/expertiza/commit/b62182b4bb42f563ba3cee88917119be378db439

In this page the method show_available_submissions() in review_mapping_controller.rb was being called. Since this was the only place the method was being called we decided to delete the below code snippet.

def show_available_submissions
assignment = Assignment.find(params[:assignment_id])
reviewer = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
requested_topic_id = params[:topic_id]
@available_submissions = Hash.new
@available_submissions = DynamicReviewAssignmentHelper::review_assignment(assignment.id ,
reviewer.id,
requested_topic_id ,
Assignment::RS_STUDENT_SELECTED)

Also, this is the only call being made to dynamic_review_assignment_helper.rb and this helper is not used in instructor selected and auto selected reviewing strategies. For these strategies another view is being rendered specifically _set_dynamic_review.html.erb.
Similarly dynamic_quiz_assignment_helper.rb is also not being used by any controller.
Hence the two helper files have been deleted after confirmation from the developer.

=='''Design Patterns'''==

The project involved refactoring code which was used for student selected reviewing. However since this feature was removed from Expertiza during the refactoring, we had to delete the code and hence no design pattern is applicable.

=='''Testing'''==

Since we have deleted t

Creating an Assignment:
#Login using instructor.
# Go to Manage-->Assignments-->New Public Assignment
# Add couple of topics to the assignments from the topics tab.
# Check “Allow reviewer to choose which topic to review” and “Enable authors to review others working on same topic” in the same tab.
# Choose the review strategy as Auto-Selected in Review Strategy tab.
# Choose appropriate deadlines in the due dates tab.
# Go to Manage-->Assignments--><Your Assignment Name>
# Add participants to the assignment.

Signing up and submitting the Assignment:
# Login using participant1. Select the Assignment from the list of assignments.
# Sign up for a topic.
# Submit your work before the deadline.
# Repeat the same for all participants.

Reviewing work of other Participants:
# Login using participants. Select the Assignment from the list of assignments.
# Click on Other’s Work. You will see a list of topics which are eligible for reviewing.

Validation Criteria:
# You should not be able to review your own submission
# You can review other submissions of the topic if you have checked “Enable authors to review others working on the same topic” while creating the assignment.
# You should not be able to review a submission which has already been reviewed by you.
# You should not be able to review a submission which has reached maximum number of potential reviews.

=='''References'''==
<references/>

CSC/ECE 517 Fall 2015/oss E1552 NFR

2015-11-07T04:46:08Z

Rahuja:

'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb'''
=='''Overview'''==
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure
<ref>Refactoring: Improving the Design of Existing Code -
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Robert
[https://books.google.com/books/about/Refactoring.html?id=HmrDHwgkbPsC&printsec=frontcover&source=kp_read_button#v=onepage&q&f=false]</ref>. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
There are many benefits of refactoring as follows:
<ref>Refactoring Software using Design Patterns - by Masatomo Noborikawa
[http://www.cs.uni.edu/~wallingf/miscellaneous/student-papers/noborikawa-paper.pdf]</ref>

* Refactoring improves the design of software. Refactoring often cleans up codes by deleting duplicates, divides a big chunk of codes into several methods, and makes the program more understandable.
* Because refactoring makes a design cleaner, it helps the programmers understand codes better and see things that may have not been seen before.
* Refactoring helps spot bugs since it makes the software more comprehensible.
* Refactoring turns an adverse design into a good design, which allows for rapid software development.

__TOC__

=='''Peer Reviewing'''==
It is the process of evaluating work done by an individual or a team by another team or an individual with expertise in the concerned area.
Types of Reviewing Strategies in Expertiza -

* Instructor Selected Reviewing - Using this strategy the instructor assigns reviews to all participants of the assignment. After selecting this strategy the instructor has the following two options -
** Set number of reviews done by each student.
** Set minimum number of reviews done for each submission.
Then the instructor can click on assign reviewers and map the students to the topics which should be reviewed by them.

[[File:editing_assignment.png‎ |frame|center|Instructor selected Reviewing]]

* Auto Selected Reviewing - If the instructor selects this strategy, students need to select reviews themselves. Either the student is given a list of topics to choose from and he selects which topic he wants to review, or he checks “I don’t care which topic I review” and he/she will be randomly assigned a topic to review. The instructor can also specify two parameters after selecting this strategy -
** Review topic threshold: - Let us assume Topic 1 has a submission than has not been reviewed. Topic 2 has submissions that has been reviewed atleast 2 times and k is set 2. Then the student will not be able to select topic 2 until all of topic 1’s submission has been reviewed atleast 2 times.
** Maximum number of reviews per submission: - This specifies the maximum number of times a particular top can be reviewed.

[[File:editing_assignment_2.png‎ |frame|center|Auto selected Reviewing]]

* Student Selected Reviewing -
In this strategy the student selects a particular submission to review instead of a particular topic. This feature had never been used and did not work correctly. Hence it has been removed from the system. However there are a lot of places where the code for student selected reviewing exists however it not being called anywhere.

=='''Project Resources'''==
* [https://github.com/rahuja910/expertiza GitHub Repository]
* [https://github.com/expertiza/expertiza/pull/602 GitHub Pull Request Link]
* [http://152.46.20.183:3000/ VCL Deployment Link] (For Instructor - username: instructor6, password: password. For student - username: student5700, password: password)

=='''Problem Statement'''==
==='''Classes involved'''===
dynamic_quiz_assignment_helper.rb
dynamic_review_assignment_helper.rb
review_mapping_controller.rb

==='''What it does''' ===
dynamic_review_assignment_helper.rb allows the system choose a team to review when a student chooses a topic to review. It helps the code choose topics that have submissions with fewer reviews than other topics. A threshold k is used to decide whether a particular topic can be chosen. If, e.g., Topic 1 has a submission that has not yet been reviewed, and Topic 2 has no submission that has been reviewed by fewer than 3 reviewers, then the incoming reviewer can only choose Topic 2 if k ≥ 3. This class does not actually decide what is reviewable, but it does make up a sorted list of the submissions by the number of the reviews they have. dynamic_quiz_assignment_helper.rb is similar, but for quizzes.

==='''What needs to be done'''===
* Remove the code for “student-selected” reviewing
* The find_submissions_in_current_cycle method returns a list of participants. It should return a list of teams.
* Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes
* The two classes have a lot of duplicated code. Remove all DRY problems.

=='''Modification of find_submissions_in_current_cycle method'''==

This function returns a list of participants for the particular assignment. This leads to redundant entries in the hash since most teams are made up of more than one member. Earlier the submissions belonged to participants rather than teams, however currently there is no need for this since if an instructor wants individual assignments he/she simply selects maximum number of size of a team as one. Correspondingly changes need to be made to the call sites.

* Before Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentParticipant.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
users = TeamsUser.where(team_id: signUp.team_id)
users.each do |user|
participant = Participant.where(user_id: user_id, parent_id: @assignment_id)
if participant
submissions_in_current_cycle << participant
end
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

* After Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentTeam.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
team=Team.where(team_id: signUp.team_id)
if team
submissions_in_current_cycle << team
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

As seen from the above code we have replaced AssignmentParticipant with AssignmentTeam. Now submissions_in_current_cycle will contain list of participants rather than a list of teams. Also note the model for AssignmentTeam contains the same methods which are present in the model for AssignmentParticipant. In the same helper class we had to modify code to handle the aspect that submissions_in_current_cycle now contains teams rather than participants. Hence we made changes in build_submissions_availability().

=='''Implementation of Criteria'''==
'''Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes.''' 
The helper classes while returning a list of teams should check the below set of conditions. Each of the below conditions need to be checked at one place to ensure better code readability and maintainability.

* The article was not written by the potential reviewer.
The potential reviewer should not be able to review its own submission and hence a check for this condition is required. However, it was already implemented in the code beforehand.

* The article was not already reviewed by the potential reviewer.
The potential reviewer should not be able to review a topic which is already reviewed by him/her. The same was also implemented along with the above condition.

* The article is not on the same topic as the potential reviewer has previously written about.
The reviewer should not be able to review on the same topic that he/she submitted as the reviewer could give biased reviews to make his/her own submission seem better. This was not implemented previously and was implemented in the code changes by checking the topic id.

'''Implementation :''' 
<pre>
def self.build_submissions_availability()
least_review_count = -1;
max_no_reviews = 5
reviewer_teams=TeamsUser.where(user_id: @reviewer_id)

@submissions_availability = Hash.new
unless @submissions_in_current_cycle.nil?
@submissions_in_current_cycle.each { |submission|
team_check=false
if( least_review_count == -1)
least_review_count = submission[1]
end
reviewer_teams.each do |reviewer_team|
if submission[0] == reviewer_team.team_id
team_check=true
end
end

if !team_check
@submissions_availability[submission[0]] = get_state(least_review_count,submission[1],max_no_reviews)
end
}
end
return @submissions_availability
end
</pre>

* The article does not already have the maximum number of potential reviews in progress.
The reviewer should only be able to review topics that have not reached the maximum number of reviews. The check for the same is done in get_state method where the current_review_count is compared with max_review_count and make it unavailable.

* The article has the minimum number of reviews for that assignment.
The article is made available if it has the minimum number of reviews for the assignment and the same is checked in get_state method where the current_review_count is compared with least_review_count and make it available.

'''Implementation:''' 
<pre>
def self.get_state(least_review_count,current_review_count,max_review_count)
if(current_review_count != -1 && current_review_count == max_review_count)
return -1
elsif(current_review_count != -1 && current_review_count > least_review_count)
return 1
elsif(current_review_count != -1 && current_review_count == least_review_count)
return 0
end
end
</pre>

=='''Deletion of "student-selected" reviewing'''==
The following files had code for “student-selected” reviewing –

* dynamic_quiz_assignment_helper.rb
* dynamic_review_assignment_helper.rb
* review_mapping_controller.rb

In student-selected reviewing, a student was allowed to review a particular submission and not just a particular topic.The functionality for “student-selected” reviewing was never implemented successfully. Hence, the methods corresponding to the aforementioned functionality were removed from respective files.

While making changes to the helper classes to remove student selected reviewing, a commit was made to the expertiza repository which deleted the page for student selected reviewing.
https://github.com/expertiza/expertiza/commit/b62182b4bb42f563ba3cee88917119be378db439

In this page the method show_available_submissions() in review_mapping_controller.rb was being called. Since this was the only place the method was being called we decided to delete the below code snippet.

def show_available_submissions
assignment = Assignment.find(params[:assignment_id])
reviewer = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
requested_topic_id = params[:topic_id]
@available_submissions = Hash.new
@available_submissions = DynamicReviewAssignmentHelper::review_assignment(assignment.id ,
reviewer.id,
requested_topic_id ,
Assignment::RS_STUDENT_SELECTED)

Also, this is the only call being made to dynamic_review_assignment_helper.rb and this helper is not used in instructor selected and auto selected reviewing strategies. For these strategies another view is being rendered specifically _set_dynamic_review.html.erb.
Similarly dynamic_quiz_assignment_helper.rb is also not being used by any controller.
Hence the two helper files have been deleted after confirmation from the developer.

=='''Design Patterns'''==

The project involved refactoring code which was used for student selected reviewing. However since this feature was removed from Expertiza during the refactoring we had to delete the code and hence no design patterns is applicable.

=='''Testing'''==

Since we have deleted t

Creating an Assignment:
#Login using instructor.
# Go to Manage-->Assignments-->New Public Assignment
# Add couple of topics to the assignments from the topics tab.
# Check “Allow reviewer to choose which topic to review” and “Enable authors to review others working on same topic” in the same tab.
# Choose the review strategy as Auto-Selected in Review Strategy tab.
# Choose appropriate deadlines in the due dates tab.
# Go to Manage-->Assignments--><Your Assignment Name>
# Add participants to the assignment.

Signing up and submitting the Assignment:
# Login using participant1. Select the Assignment from the list of assignments.
# Sign up for a topic.
# Submit your work before the deadline.
# Repeat the same for all participants.

Reviewing work of other Participants:
# Login using participants. Select the Assignment from the list of assignments.
# Click on Other’s Work. You will see a list of topics which are eligible for reviewing.

Validation Criteria:
# You should not be able to review your own submission
# You can review other submissions of the topic if you have checked “Enable authors to review others working on the same topic” while creating the assignment.
# You should not be able to review a submission which has already been reviewed by you.
# You should not be able to review a submission which has reached maximum number of potential reviews.

=='''References'''==
<references/>

CSC/ECE 517 Fall 2015/oss E1552 NFR

2015-11-06T08:20:23Z

Rahuja:

'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb'''
=='''Overview'''==
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure
<ref>Refactoring: Improving the Design of Existing Code -
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Robert
[https://books.google.com/books/about/Refactoring.html?id=HmrDHwgkbPsC&printsec=frontcover&source=kp_read_button#v=onepage&q&f=false]</ref>. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
There are many benefits of refactoring as follows:
<ref>Refactoring Software using Design Patterns - by Masatomo Noborikawa
[http://www.cs.uni.edu/~wallingf/miscellaneous/student-papers/noborikawa-paper.pdf]</ref>

* Refactoring improves the design of software. Refactoring often cleans up codes by deleting duplicates, divides a big chunk of codes into several methods, and makes the program more understandable.
* Because refactoring makes a design cleaner, it helps the programmers understand codes better and see things that may have not been seen before.
* Refactoring helps spot bugs since it makes the software more comprehensible.
* Refactoring turns an adverse design into a good design, which allows for rapid software development.

__TOC__

=='''Peer Reviewing'''==
It is the process of evaluating work done by an individual or a team by another team or an individual with expertise in the concerned area.
Types of Reviewing Strategies in Expertiza -

* Instructor Selected Reviewing - Using this strategy the instructor assigns reviews to all participants of the assignment. After selecting this strategy the instructor has the following two options -
** Set number of reviews done by each student.
** Set minimum number of reviews done for each submission.
Then the instructor can click on assign reviewers and map the students to the topics which should be reviewed by them.

[[File:editing_assignment.png‎ |frame|center|Instructor selected Reviewing]]

* Auto Selected Reviewing - If the instructor selects this strategy, students need to select reviews themselves. Either the student is given a list of topics to choose from and he selects which topic he wants to review, or he checks “I don’t care which topic I review” and he/she will be randomly assigned a topic to review. The instructor can also specify two parameters after selecting this strategy -
** Review topic threshold: - Let us assume Topic 1 has a submission than has not been reviewed. Topic 2 has submissions that has been reviewed atleast 2 times and k is set 2. Then the student will not be able to select topic 2 until all of topic 1’s submission has been reviewed atleast 2 times.
** Maximum number of reviews per submission: - This specifies the maximum number of times a particular top can be reviewed.

[[File:editing_assignment_2.png‎ |frame|center|Auto selected Reviewing]]

* Student Selected Reviewing -
In this strategy the student selects a particular submission to review instead of a particular topic. This feature had never been used and did not work correctly. Hence it has been removed from the system. However there are a lot of places where the code for student selected reviewing exists however it not being called anywhere.

=='''Project Resources'''==
* [https://github.com/rahuja910/expertiza GitHub Repository]
* [https://github.com/expertiza/expertiza/pull/602 GitHub Pull Request Link]
* [http://152.46.20.183:3000/ VCL Deployment Link] (For Instructor - username: instructor6, password: password. For student - username: student5700, password: password)

=='''Problem Statement'''==
==='''Classes involved'''===
dynamic_quiz_assignment_helper.rb
dynamic_review_assignment_helper.rb
review_mapping_controller.rb

==='''What it does''' ===
dynamic_review_assignment_helper.rb allows the system choose a team to review when a student chooses a topic to review. It helps the code choose topics that have submissions with fewer reviews than other topics. A threshold k is used to decide whether a particular topic can be chosen. If, e.g., Topic 1 has a submission that has not yet been reviewed, and Topic 2 has no submission that has been reviewed by fewer than 3 reviewers, then the incoming reviewer can only choose Topic 2 if k ≥ 3. This class does not actually decide what is reviewable, but it does make up a sorted list of the submissions by the number of the reviews they have. dynamic_quiz_assignment_helper.rb is similar, but for quizzes.

==='''What needs to be done'''===
* Remove the code for “student-selected” reviewing
* The find_submissions_in_current_cycle method returns a list of participants. It should return a list of teams.
* Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes
* The two classes have a lot of duplicated code. Remove all DRY problems.

=='''Modification of find_submissions_in_current_cycle method'''==

This function returns a list of participants for the particular assignment. This leads to redundant entries in the hash since most teams are made up of more than one member. Earlier the submissions belonged to participants rather than teams, however currently there is no need for this since if an instructor wants individual assignments he/she simply selects maximum number of size of a team as one. Correspondingly changes need to be made to the call sites.

* Before Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentParticipant.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
users = TeamsUser.where(team_id: signUp.team_id)
users.each do |user|
participant = Participant.where(user_id: user_id, parent_id: @assignment_id)
if participant
submissions_in_current_cycle << participant
end
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

* After Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentTeam.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
team=Team.where(team_id: signUp.team_id)
if team
submissions_in_current_cycle << team
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

As seen from the above code we have replaced AssignmentParticipant with AssignmentTeam. Now submissions_in_current_cycle will contain list of participants rather than a list of teams. Also note the model for AssignmentTeam contains the same methods which are present in the model for AssignmentParticipant. In the same helper class we had to modify code to handle the aspect that submissions_in_current_cycle now contains teams rather than participants. Hence we made changes in build_submissions_availability().

=='''Implementation of Criteria'''==
'''Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes.''' 
The helper classes while returning a list of teams should check the below set of conditions. Each of the below conditions need to be checked at one place to ensure better code readability and maintainability.

* The article was not written by the potential reviewer.
The potential reviewer should not be able to review its own submission and hence a check for this condition is required. However, it was already implemented in the code beforehand.

* The article was not already reviewed by the potential reviewer.
The potential reviewer should not be able to review a topic which is already reviewed by him/her. The same was also implemented along with the above condition.

* The article is not on the same topic as the potential reviewer has previously written about.
The reviewer should not be able to review on the same topic that he/she submitted as the reviewer could give biased reviews to make his/her own submission seem better. This was not implemented previously and was implemented in the code changes by checking the topic id.

'''Implementation :''' 
<pre>
def self.build_submissions_availability()
least_review_count = -1;
max_no_reviews = 5
reviewer_teams=TeamsUser.where(user_id: @reviewer_id)

@submissions_availability = Hash.new
unless @submissions_in_current_cycle.nil?
@submissions_in_current_cycle.each { |submission|
team_check=false
if( least_review_count == -1)
least_review_count = submission[1]
end
reviewer_teams.each do |reviewer_team|
if submission[0] == reviewer_team.team_id
team_check=true
end
end

if !team_check
@submissions_availability[submission[0]] = get_state(least_review_count,submission[1],max_no_reviews)
end
}
end
return @submissions_availability
end
</pre>

* The article does not already have the maximum number of potential reviews in progress.
The reviewer should only be able to review topics that have not reached the maximum number of reviews. The check for the same is done in get_state method where the current_review_count is compared with max_review_count and make it unavailable.

* The article has the minimum number of reviews for that assignment.
The article is made available if it has the minimum number of reviews for the assignment and the same is checked in get_state method where the current_review_count is compared with least_review_count and make it available.

'''Implementation:''' 
<pre>
def self.get_state(least_review_count,current_review_count,max_review_count)
if(current_review_count != -1 && current_review_count == max_review_count)
return -1
elsif(current_review_count != -1 && current_review_count > least_review_count)
return 1
elsif(current_review_count != -1 && current_review_count == least_review_count)
return 0
end
end
</pre>

=='''Deletion of "student-selected" reviewing'''==
The following files had code for “student-selected” reviewing –

* dynamic_quiz_assignment_helper.rb
* dynamic_review_assignment_helper.rb
* review_mapping_controller.rb

In student-selected reviewing, a student was allowed to review a particular submission and not just a particular topic.The functionality for “student-selected” reviewing was never implemented successfully. Hence, the methods corresponding to the aforementioned functionality were removed from respective files.

While making changes to the helper classes to remove student selected reviewing, a commit was made to the expertiza repository which deleted the page for student selected reviewing.
https://github.com/expertiza/expertiza/commit/b62182b4bb42f563ba3cee88917119be378db439

In this page the method show_available_submissions() in review_mapping_controller.rb was being called. Since this was the only place the method was being called we decided to delete the below code snippet.

def show_available_submissions
assignment = Assignment.find(params[:assignment_id])
reviewer = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
requested_topic_id = params[:topic_id]
@available_submissions = Hash.new
@available_submissions = DynamicReviewAssignmentHelper::review_assignment(assignment.id ,
reviewer.id,
requested_topic_id ,
Assignment::RS_STUDENT_SELECTED)

Also, this is the only call being made to dynamic_review_assignment_helper.rb and this helper is not used in instructor selected and auto selected reviewing strategies. For these strategies another view is being rendered specifically _set_dynamic_review.html.erb.
Similarly dynamic_quiz_assignment_helper.rb is also not being used by any controller.
Hence the two helper files have been deleted after confirmation from the developer.

=='''Testing from UI'''==

Creating an Assignment:
#Login using instructor.
# Go to Manage-->Assignments-->New Public Assignment
# Add couple of topics to the assignments from the topics tab.
# Check “Allow reviewer to choose which topic to review” and “Enable authors to review others working on same topic” in the same tab.
# Choose the review strategy as Auto-Selected in Review Strategy tab.
# Choose appropriate deadlines in the due dates tab.
# Go to Manage-->Assignments--><Your Assignment Name>
# Add participants to the assignment.

Signing up and submitting the Assignment:
# Login using participant1. Select the Assignment from the list of assignments.
# Sign up for a topic.
# Submit your work before the deadline.
# Repeat the same for all participants.

Reviewing work of other Participants:
# Login using participants. Select the Assignment from the list of assignments.
# Click on Other’s Work. You will see a list of topics which are eligible for reviewing.

Validation Criteria:
# You should not be able to review your own submission
# You can review other submissions of the topic if you have checked “Enable authors to review others working on the same topic” while creating the assignment.
# You should not be able to review a submission which has already been reviewed by you.
# You should not be able to review a submission which has reached maximum number of potential reviews.

=='''References'''==
<references/>

CSC/ECE 517 Fall 2015/oss E1552 NFR

2015-11-01T03:37:35Z

Rahuja: Created page with "'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb''' =='''Overview'''== Refactoring is the..."

'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb'''
=='''Overview'''==
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure
<ref>Refactoring: Improving the Design of Existing Code -
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Robert
[https://books.google.com/books/about/Refactoring.html?id=HmrDHwgkbPsC&printsec=frontcover&source=kp_read_button#v=onepage&q&f=false]</ref>. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
There are many benefits of refactoring as follows:
<ref>Refactoring Software using Design Patterns - by Masatomo Noborikawa
[http://www.cs.uni.edu/~wallingf/miscellaneous/student-papers/noborikawa-paper.pdf]</ref>

* Refactoring improves the design of software. Refactoring often cleans up codes by deleting duplicates, divides a big chunk of codes into several methods, and makes the program more understandable.
* Because refactoring makes a design cleaner, it helps the programmers understand codes better and see things that may have not been seen before.
* Refactoring helps spot bugs since it makes the software more comprehensible.
* Refactoring turns an adverse design into a good design, which allows for rapid software development.

__TOC__

=='''Peer Reviewing'''==
It is the process of evaluating work done by an individual or a team by another team or an individual with expertise in the concerned area.
Types of Reviewing Strategies in Expertiza -

* Instructor Selected Reviewing - Using this strategy the instructor assigns reviews to all participants of the assignment. After selecting this strategy the instructor has the following two options -
** Set number of reviews done by each student.
** Set minimum number of reviews done for each submission.
Then the instructor can click on assign reviewers and map the students to the topics which should be reviewed by them.

[[File:editing_assignment.png‎ |frame|center|Instructor selected Reviewing]]

* Auto Selected Reviewing - If the instructor selects this strategy, students need to select reviews themselves. Either the student is given a list of topics to choose from and he selects which topic he wants to review, or he checks “I don’t care which topic I review” and he/she will be randomly assigned a topic to review. The instructor can also specify two parameters after selecting this strategy -
** Review topic threshold: - Let us assume Topic 1 has a submission than has not been reviewed. Topic 2 has submissions that has been reviewed atleast 2 times and k is set 2. Then the student will not be able to select topic 2 until all of topic 1’s submission has been reviewed atleast 2 times.
** Maximum number of reviews per submission: - This specifies the maximum number of times a particular top can be reviewed.

[[File:editing_assignment_2.png‎ |frame|center|Auto selected Reviewing]]

* Student Selected Reviewing -
In this strategy the student selects a particular submission to review instead of a particular topic. This feature had never been used and did not work correctly. Hence it has been removed from the system. However there are a lot of places where the code for student selected reviewing exists however it not being called anywhere.

=='''Project Resources'''==
* [https://github.com/rahuja910/expertiza GitHub Repository]
* [https://github.com/expertiza/expertiza/pull/602 GitHub Pull Request Link]
* [http://152.46.20.183:3000/ VCL Deployment Link] (For Instructor - username: instructor6, password: password. For student - username: student5700, password: password)

=='''Problem Statement'''==
==='''Classes involved'''===
dynamic_quiz_assignment_helper.rb
dynamic_review_assignment_helper.rb
review_mapping_controller.rb

==='''What it does''' ===
dynamic_review_assignment_helper.rb allows the system choose a team to review when a student chooses a topic to review. It helps the code choose topics that have submissions with fewer reviews than other topics. A threshold k is used to decide whether a particular topic can be chosen. If, e.g., Topic 1 has a submission that has not yet been reviewed, and Topic 2 has no submission that has been reviewed by fewer than 3 reviewers, then the incoming reviewer can only choose Topic 2 if k ≥ 3. This class does not actually decide what is reviewable, but it does make up a sorted list of the submissions by the number of the reviews they have. dynamic_quiz_assignment_helper.rb is similar, but for quizzes.

==='''What needs to be done'''===
* Remove the code for “student-selected” reviewing
* The find_submissions_in_current_cycle method returns a list of participants. It should return a list of teams.
* Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes
* The two classes have a lot of duplicated code. Remove all DRY problems.

=='''Modification of find_submissions_in_current_cycle method'''==

This function returns a list of participants for the particular assignment. This leads to redundant entries in the hash since most teams are made up of more than one member. Earlier the submissions belonged to participants rather than teams, however currently there is no need for this since if an instructor wants individual assignments he/she simply selects maximum number of size of a team as one. Correspondingly changes need to be made to the call sites.

* Before Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentParticipant.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
users = TeamsUser.where(team_id: signUp.team_id)
users.each do |user|
participant = Participant.where(user_id: user_id, parent_id: @assignment_id)
if participant
submissions_in_current_cycle << participant
end
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

* After Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentTeam.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
team=Team.where(team_id: signUp.team_id)
if team
submissions_in_current_cycle << team
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

As seen from the above code we have replaced AssignmentParticipant with AssignmentTeam. Now submissions_in_current_cycle will contain list of participants rather than a list of teams. Also note the model for AssignmentTeam contains the same methods which are present in the model for AssignmentParticipant. In the same helper class we had to modify code to handle the aspect that submissions_in_current_cycle now contains teams rather than participants. Hence we made changes in build_submissions_availability().

=='''Implementation of Criteria'''==
'''Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes.''' 
The helper classes while returning a list of teams should check the below set of conditions. Each of the below conditions need to be checked at one place to ensure better code readability and maintainability.

* The article was not written by the potential reviewer.
The potential reviewer should not be able to review its own submission and hence a check for this condition is required. However, it was already implemented in the code beforehand.

* The article was not already reviewed by the potential reviewer.
The potential reviewer should not be able to review a topic which is already reviewed by him/her. The same was also implemented along with the above condition.

* The article is not on the same topic as the potential reviewer has previously written about.
The reviewer should not be able to review on the same topic that he/she submitted as the reviewer could give biased reviews to make his/her own submission seem better. This was not implemented previously and was implemented in the code changes by checking the topic id.

'''Implementation :''' 
<pre>
def self.build_submissions_availability()
least_review_count = -1;
max_no_reviews = 5
reviewer_teams=TeamsUser.where(user_id: @reviewer_id)

@submissions_availability = Hash.new
unless @submissions_in_current_cycle.nil?
@submissions_in_current_cycle.each { |submission|
team_check=false
if( least_review_count == -1)
least_review_count = submission[1]
end
reviewer_teams.each do |reviewer_team|
if submission[0] == reviewer_team.team_id
team_check=true
end
end

if !team_check
@submissions_availability[submission[0]] = get_state(least_review_count,submission[1],max_no_reviews)
end
}
end
return @submissions_availability
end
</pre>

* The article does not already have the maximum number of potential reviews in progress.
The reviewer should only be able to review topics that have not reached the maximum number of reviews. The check for the same is done in get_state method where the current_review_count is compared with max_review_count and make it unavailable.

* The article has the minimum number of reviews for that assignment.
The article is made available if it has the minimum number of reviews for the assignment and the same is checked in get_state method where the current_review_count is compared with least_review_count and make it available.

'''Implementation:''' 
<pre>
def self.get_state(least_review_count,current_review_count,max_review_count)
if(current_review_count != -1 && current_review_count == max_review_count)
return -1
elsif(current_review_count != -1 && current_review_count > least_review_count)
return 1
elsif(current_review_count != -1 && current_review_count == least_review_count)
return 0
end
end
</pre>

=='''Deletion of "student-selected" reviewing'''==
The following files had code for “student-selected” reviewing –

* dynamic_quiz_assignment_helper.rb
* dynamic_review_assignment_helper.rb
* review_mapping_controller.rb

In student-selected reviewing, a student was allowed to review a particular submission and not just a particular topic.The functionality for “student-selected” reviewing was never implemented successfully. Hence, the methods corresponding to the aforementioned functionality were removed from respective files.

While making changes to the helper classes to remove student selected reviewing, a commit was made to the expertiza repository which deleted the page for student selected reviewing.
https://github.com/expertiza/expertiza/commit/b62182b4bb42f563ba3cee88917119be378db439

In this page the method show_available_submissions() in review_mapping_controller.rb was being called. Since this was the only place the method was being called we decided to delete the below code snippet.

def show_available_submissions
assignment = Assignment.find(params[:assignment_id])
reviewer = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
requested_topic_id = params[:topic_id]
@available_submissions = Hash.new
@available_submissions = DynamicReviewAssignmentHelper::review_assignment(assignment.id ,
reviewer.id,
requested_topic_id ,
Assignment::RS_STUDENT_SELECTED)

Also, this is the only call being made to dynamic_review_assignment_helper.rb and this helper is not used in instructor selected and auto selected reviewing strategies. For these strategies another view is being rendered specifically _set_dynamic_review.html.erb.
Similarly dynamic_quiz_assignment_helper.rb is also not being used by any controller.
Hence the two helper files have been deleted after confirmation from the developer.

=='''References'''==
<references/>

CSC/ECE 517 Fall 2015

2015-11-01T03:36:27Z

Rahuja:

==Writing Assignment 2==
*[[CSC/ECE_517_Fall_2015/sample_page]]
*[[CSC/ECE_517_Fall_2015/ossE1558BGJ]]
*[[CSC/ECE 517 Fall 2015/oss/M1502/AAAASS]]
*[[CSC/ECE 517 Fall 2015/oss/M1503/IntegrateXMLParser]]
*[[CSC/ECE_517_Fall_2015/ossE1568BZHXJS]]
*[[CSC/ECE_517_Fall_2015/ossE1572VGA]]
*[[CSC/ECE_517_Fall_2015/oss_E1573_sap]]
*[[CSC/ECE 517 Fall 2015/oss E1559 rrz]]
*[[CSC/ECE 517 Fall 2015/oss E1570 avr]]
*[[CSC/ECE 517 Fall 2015/oss E1556 CHM]]
*[[CSC/ECE 517 Fall 2015/oss M1504 JJD]]
*[[CSC/ECE 517 Fall 2015/oss E1562 APS]]
*[[CSC/ECE 517 Fall 2015/oss M1501 GSN]]
*[[CSC/ECE 517 Fall 2015/oss M1501 GSN]]
*[[CSC/ECE 517 Fall 2015/oss E1550 KMM]]
*[[CSC/ECE 517 Fall 2015/oss E1551 RGS]]
*[[CSC/ECE 517 Fall 2015/oss E1555 GMR]]
*[[CSC/ECE 517 Fall 2015/oss E1552 NFR]]
*[[CSC/ECE 517 Fall 2015/oss E1565 AAJ]]
*[[CSC/ECE 517 Fall 2015/oss E1561 WZL]]
*[[CSC/ECE 517 Fall 2015/oss E1553 AAJ]]
*[[CSC/ECE 517 Fall 2015/oss E1554 AAR]]
*[[CSC/ECE 517 Fall 2015/oss E1569 JNR]]
*[[CSC/ECE 517 Fall 2015/oss E1560 PSV]]
*[[CSC/ECE 517 Fall 2015/oss M1505 MSV]]
*[[CSC/ECE 517 Fall 2015/oss E1557 GXM]]
*[[CSC/ECE 517 Fall 2015/oss E1566 ARB]]
*[[CSC/ECE 517 Fall 2015/oss E1567 APT]]
*[[CSC/ECE 517 Fall 2015/oss E1574 BKS]]
*[[CSC/ECE 517 Fall 2015/ossA1550RAN]]

CSC/ECE 517 Fall 2015/oss E1552 NRR

2015-11-01T01:42:24Z

Rahuja: /* Deletion of "student-selected" reviewing */

'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb'''
=='''Overview'''==
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure
<ref>Refactoring: Improving the Design of Existing Code -
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Robert
[https://books.google.com/books/about/Refactoring.html?id=HmrDHwgkbPsC&printsec=frontcover&source=kp_read_button#v=onepage&q&f=false]</ref>. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
There are many benefits of refactoring as follows:
<ref>Refactoring Software using Design Patterns - by Masatomo Noborikawa
[http://www.cs.uni.edu/~wallingf/miscellaneous/student-papers/noborikawa-paper.pdf]</ref>

* Refactoring improves the design of software. Refactoring often cleans up codes by deleting duplicates, divides a big chunk of codes into several methods, and makes the program more understandable.
* Because refactoring makes a design cleaner, it helps the programmers understand codes better and see things that may have not been seen before.
* Refactoring helps spot bugs since it makes the software more comprehensible.
* Refactoring turns an adverse design into a good design, which allows for rapid software development.

__TOC__

=='''Peer Reviewing'''==
It is the process of evaluating work done by an individual or a team by another team or an individual with expertise in the concerned area.
Types of Reviewing Strategies in Expertiza -

* Instructor Selected Reviewing - Using this strategy the instructor assigns reviews to all participants of the assignment. After selecting this strategy the instructor has the following two options -
** Set number of reviews done by each student.
** Set minimum number of reviews done for each submission.
Then the instructor can click on assign reviewers and map the students to the topics which should be reviewed by them.

[[File:editing_assignment.png‎ |frame|center|Instructor selected Reviewing]]

* Auto Selected Reviewing - If the instructor selects this strategy, students need to select reviews themselves. Either the student is given a list of topics to choose from and he selects which topic he wants to review, or he checks “I don’t care which topic I review” and he/she will be randomly assigned a topic to review. The instructor can also specify two parameters after selecting this strategy -
** Review topic threshold: - Let us assume Topic 1 has a submission than has not been reviewed. Topic 2 has submissions that has been reviewed atleast 2 times and k is set 2. Then the student will not be able to select topic 2 until all of topic 1’s submission has been reviewed atleast 2 times.
** Maximum number of reviews per submission: - This specifies the maximum number of times a particular top can be reviewed.

[[File:editing_assignment_2.png‎ |frame|center|Auto selected Reviewing]]

* Student Selected Reviewing -
In this strategy the student selects a particular submission to review instead of a particular topic. This feature had never been used and did not work correctly. Hence it has been removed from the system. However there are a lot of places where the code for student selected reviewing exists however it not being called anywhere.

=='''Project Resources'''==
* [https://github.com/rahuja910/expertiza GitHub Repository]
* [https://github.com/expertiza/expertiza/pull/602 GitHub Pull Request Link]
* [http://152.46.20.183:3000/ VCL Deployment Link] (For Instructor - username: instructor6, password: password. For student - username: student5700, password: password)

=='''Problem Statement'''==
==='''Classes involved'''===
dynamic_quiz_assignment_helper.rb
dynamic_review_assignment_helper.rb
review_mapping_controller.rb

==='''What it does''' ===
dynamic_review_assignment_helper.rb allows the system choose a team to review when a student chooses a topic to review. It helps the code choose topics that have submissions with fewer reviews than other topics. A threshold k is used to decide whether a particular topic can be chosen. If, e.g., Topic 1 has a submission that has not yet been reviewed, and Topic 2 has no submission that has been reviewed by fewer than 3 reviewers, then the incoming reviewer can only choose Topic 2 if k ≥ 3. This class does not actually decide what is reviewable, but it does make up a sorted list of the submissions by the number of the reviews they have. dynamic_quiz_assignment_helper.rb is similar, but for quizzes.

==='''What needs to be done'''===
* Remove the code for “student-selected” reviewing
* The find_submissions_in_current_cycle method returns a list of participants. It should return a list of teams.
* Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes
* The two classes have a lot of duplicated code. Remove all DRY problems.

=='''Modification of find_submissions_in_current_cycle method'''==

This function returns a list of participants for the particular assignment. This leads to redundant entries in the hash since most teams are made up of more than one member. Earlier the submissions belonged to participants rather than teams, however currently there is no need for this since if an instructor wants individual assignments he/she simply selects maximum number of size of a team as one. Correspondingly changes need to be made to the call sites.

* Before Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentParticipant.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
users = TeamsUser.where(team_id: signUp.team_id)
users.each do |user|
participant = Participant.where(user_id: user_id, parent_id: @assignment_id)
if participant
submissions_in_current_cycle << participant
end
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

* After Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentTeam.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
team=Team.where(team_id: signUp.team_id)
if team
submissions_in_current_cycle << team
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

As seen from the above code we have replaced AssignmentParticipant with AssignmentTeam. Now submissions_in_current_cycle will contain list of participants rather than a list of teams. Also note the model for AssignmentTeam contains the same methods which are present in the model for AssignmentParticipant. In the same helper class we had to modify code to handle the aspect that submissions_in_current_cycle now contains teams rather than participants. Hence we made changes in build_submissions_availability().

=='''Implementation of Criteria'''==
'''Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes.''' 
The helper classes while returning a list of teams should check the below set of conditions. Each of the below conditions need to be checked at one place to ensure better code readability and maintainability.

* The article was not written by the potential reviewer.
The potential reviewer should not be able to review its own submission and hence a check for this condition is required. However, it was already implemented in the code beforehand.

* The article was not already reviewed by the potential reviewer.
The potential reviewer should not be able to review a topic which is already reviewed by him/her. The same was also implemented along with the above condition.

* The article is not on the same topic as the potential reviewer has previously written about.
The reviewer should not be able to review on the same topic that he/she submitted as the reviewer could give biased reviews to make his/her own submission seem better. This was not implemented previously and was implemented in the code changes by checking the topic id.

'''Implementation :''' 
<pre>
def self.build_submissions_availability()
least_review_count = -1;
max_no_reviews = 5
reviewer_teams=TeamsUser.where(user_id: @reviewer_id)

@submissions_availability = Hash.new
unless @submissions_in_current_cycle.nil?
@submissions_in_current_cycle.each { |submission|
team_check=false
if( least_review_count == -1)
least_review_count = submission[1]
end
reviewer_teams.each do |reviewer_team|
if submission[0] == reviewer_team.team_id
team_check=true
end
end

if !team_check
@submissions_availability[submission[0]] = get_state(least_review_count,submission[1],max_no_reviews)
end
}
end
return @submissions_availability
end
</pre>

* The article does not already have the maximum number of potential reviews in progress.
The reviewer should only be able to review topics that have not reached the maximum number of reviews. The check for the same is done in get_state method where the current_review_count is compared with max_review_count and make it unavailable.

* The article has the minimum number of reviews for that assignment.
The article is made available if it has the minimum number of reviews for the assignment and the same is checked in get_state method where the current_review_count is compared with least_review_count and make it available.

'''Implementation:''' 
<pre>
def self.get_state(least_review_count,current_review_count,max_review_count)
if(current_review_count != -1 && current_review_count == max_review_count)
return -1
elsif(current_review_count != -1 && current_review_count > least_review_count)
return 1
elsif(current_review_count != -1 && current_review_count == least_review_count)
return 0
end
end
</pre>

=='''Deletion of "student-selected" reviewing'''==
The following files had code for “student-selected” reviewing –

* dynamic_quiz_assignment_helper.rb
* dynamic_review_assignment_helper.rb
* review_mapping_controller.rb

In student-selected reviewing, a student was allowed to review a particular submission and not just a particular topic.The functionality for “student-selected” reviewing was never implemented successfully. Hence, the methods corresponding to the aforementioned functionality were removed from respective files.

While making changes to the helper classes to remove student selected reviewing, a commit was made to the expertiza repository which deleted the page for student selected reviewing.
https://github.com/expertiza/expertiza/commit/b62182b4bb42f563ba3cee88917119be378db439

In this page the method show_available_submissions() in review_mapping_controller.rb was being called. Since this was the only place the method was being called we decided to delete the below code snippet.

def show_available_submissions
assignment = Assignment.find(params[:assignment_id])
reviewer = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
requested_topic_id = params[:topic_id]
@available_submissions = Hash.new
@available_submissions = DynamicReviewAssignmentHelper::review_assignment(assignment.id ,
reviewer.id,
requested_topic_id ,
Assignment::RS_STUDENT_SELECTED)

Also, this is the only call being made to dynamic_review_assignment_helper.rb and this helper is not used in instructor selected and auto selected reviewing strategies. For these strategies another view is being rendered specifically _set_dynamic_review.html.erb.
Similarly dynamic_quiz_assignment_helper.rb is also not being used by any controller.
Hence the two helper files have been deleted after confirmation from the developer.

=='''References'''==
<references/>

CSC/ECE 517 Fall 2015/oss E1552 NRR

2015-11-01T01:38:15Z

Rahuja: /* Deletion of "student-selected" reviewing */

'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb'''
=='''Overview'''==
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure
<ref>Refactoring: Improving the Design of Existing Code -
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Robert
[https://books.google.com/books/about/Refactoring.html?id=HmrDHwgkbPsC&printsec=frontcover&source=kp_read_button#v=onepage&q&f=false]</ref>. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
There are many benefits of refactoring as follows:
<ref>Refactoring Software using Design Patterns - by Masatomo Noborikawa
[http://www.cs.uni.edu/~wallingf/miscellaneous/student-papers/noborikawa-paper.pdf]</ref>

* Refactoring improves the design of software. Refactoring often cleans up codes by deleting duplicates, divides a big chunk of codes into several methods, and makes the program more understandable.
* Because refactoring makes a design cleaner, it helps the programmers understand codes better and see things that may have not been seen before.
* Refactoring helps spot bugs since it makes the software more comprehensible.
* Refactoring turns an adverse design into a good design, which allows for rapid software development.

__TOC__

=='''Peer Reviewing'''==
It is the process of evaluating work done by an individual or a team by another team or an individual with expertise in the concerned area.
Types of Reviewing Strategies in Expertiza -

* Instructor Selected Reviewing - Using this strategy the instructor assigns reviews to all participants of the assignment. After selecting this strategy the instructor has the following two options -
** Set number of reviews done by each student.
** Set minimum number of reviews done for each submission.
Then the instructor can click on assign reviewers and map the students to the topics which should be reviewed by them.

[[File:editing_assignment.png‎ |frame|center|Instructor selected Reviewing]]

* Auto Selected Reviewing - If the instructor selects this strategy, students need to select reviews themselves. Either the student is given a list of topics to choose from and he selects which topic he wants to review, or he checks “I don’t care which topic I review” and he/she will be randomly assigned a topic to review. The instructor can also specify two parameters after selecting this strategy -
** Review topic threshold: - Let us assume Topic 1 has a submission than has not been reviewed. Topic 2 has submissions that has been reviewed atleast 2 times and k is set 2. Then the student will not be able to select topic 2 until all of topic 1’s submission has been reviewed atleast 2 times.
** Maximum number of reviews per submission: - This specifies the maximum number of times a particular top can be reviewed.

[[File:editing_assignment_2.png‎ |frame|center|Auto selected Reviewing]]

* Student Selected Reviewing -
In this strategy the student selects a particular submission to review instead of a particular topic. This feature had never been used and did not work correctly. Hence it has been removed from the system. However there are a lot of places where the code for student selected reviewing exists however it not being called anywhere.

=='''Project Resources'''==
* [https://github.com/rahuja910/expertiza GitHub Repository]
* [https://github.com/expertiza/expertiza/pull/602 GitHub Pull Request Link]
* [http://152.46.20.183:3000/ VCL Deployment Link] (For Instructor - username: instructor6, password: password. For student - username: student5700, password: password)

=='''Problem Statement'''==
==='''Classes involved'''===
dynamic_quiz_assignment_helper.rb
dynamic_review_assignment_helper.rb
review_mapping_controller.rb

==='''What it does''' ===
dynamic_review_assignment_helper.rb allows the system choose a team to review when a student chooses a topic to review. It helps the code choose topics that have submissions with fewer reviews than other topics. A threshold k is used to decide whether a particular topic can be chosen. If, e.g., Topic 1 has a submission that has not yet been reviewed, and Topic 2 has no submission that has been reviewed by fewer than 3 reviewers, then the incoming reviewer can only choose Topic 2 if k ≥ 3. This class does not actually decide what is reviewable, but it does make up a sorted list of the submissions by the number of the reviews they have. dynamic_quiz_assignment_helper.rb is similar, but for quizzes.

==='''What needs to be done'''===
* Remove the code for “student-selected” reviewing
* The find_submissions_in_current_cycle method returns a list of participants. It should return a list of teams.
* Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes
* The two classes have a lot of duplicated code. Remove all DRY problems.

=='''Modification of find_submissions_in_current_cycle method'''==

This function returns a list of participants for the particular assignment. This leads to redundant entries in the hash since most teams are made up of more than one member. Earlier the submissions belonged to participants rather than teams, however currently there is no need for this since if an instructor wants individual assignments he/she simply selects maximum number of size of a team as one. Correspondingly changes need to be made to the call sites.

* Before Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentParticipant.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
users = TeamsUser.where(team_id: signUp.team_id)
users.each do |user|
participant = Participant.where(user_id: user_id, parent_id: @assignment_id)
if participant
submissions_in_current_cycle << participant
end
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

* After Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentTeam.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
team=Team.where(team_id: signUp.team_id)
if team
submissions_in_current_cycle << team
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

As seen from the above code we have replaced AssignmentParticipant with AssignmentTeam. Now submissions_in_current_cycle will contain list of participants rather than a list of teams. Also note the model for AssignmentTeam contains the same methods which are present in the model for AssignmentParticipant. In the same helper class we had to modify code to handle the aspect that submissions_in_current_cycle now contains teams rather than participants. Hence we made changes in build_submissions_availability().

=='''Implementation of Criteria'''==
'''Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes.''' 
The helper classes while returning a list of teams should check the below set of conditions. Each of the below conditions need to be checked at one place to ensure better code readability and maintainability.

* The article was not written by the potential reviewer.
The potential reviewer should not be able to review its own submission and hence a check for this condition is required. However, it was already implemented in the code beforehand.

* The article was not already reviewed by the potential reviewer.
The potential reviewer should not be able to review a topic which is already reviewed by him/her. The same was also implemented along with the above condition.

* The article is not on the same topic as the potential reviewer has previously written about.
The reviewer should not be able to review on the same topic that he/she submitted as the reviewer could give biased reviews to make his/her own submission seem better. This was not implemented previously and was implemented in the code changes by checking the topic id.

'''Implementation :''' 
<pre>
def self.build_submissions_availability()
least_review_count = -1;
max_no_reviews = 5
reviewer_teams=TeamsUser.where(user_id: @reviewer_id)

@submissions_availability = Hash.new
unless @submissions_in_current_cycle.nil?
@submissions_in_current_cycle.each { |submission|
team_check=false
if( least_review_count == -1)
least_review_count = submission[1]
end
reviewer_teams.each do |reviewer_team|
if submission[0] == reviewer_team.team_id
team_check=true
end
end

if !team_check
@submissions_availability[submission[0]] = get_state(least_review_count,submission[1],max_no_reviews)
end
}
end
return @submissions_availability
end
</pre>

* The article does not already have the maximum number of potential reviews in progress.
The reviewer should only be able to review topics that have not reached the maximum number of reviews. The check for the same is done in get_state method where the current_review_count is compared with max_review_count and make it unavailable.

* The article has the minimum number of reviews for that assignment.
The article is made available if it has the minimum number of reviews for the assignment and the same is checked in get_state method where the current_review_count is compared with least_review_count and make it available.

'''Implementation:''' 
<pre>
def self.get_state(least_review_count,current_review_count,max_review_count)
if(current_review_count != -1 && current_review_count == max_review_count)
return -1
elsif(current_review_count != -1 && current_review_count > least_review_count)
return 1
elsif(current_review_count != -1 && current_review_count == least_review_count)
return 0
end
end
</pre>

=='''Deletion of "student-selected" reviewing'''==
The following files had code for “student-selected” reviewing –

* dynamic_quiz_assignment_helper.rb
* dynamic_review_assignment_helper.rb
* review_mapping_controller.rb

In student-selected reviewing, a student was allowed to review a particular submission and not just a particular topic.The functionality for “student-selected” reviewing was never implemented successfully. Hence, the methods corresponding to the aforementioned functionality were removed from respective files.

While making changes to the helper classes to remove student selected reviewing, a commit was made to the expertiza repository which deleted the page for student selected reviewing.
https://github.com/expertiza/expertiza/commit/b62182b4bb42f563ba3cee88917119be378db439

In this page the method show_available_submissions() in review_mapping_controller.rb was being called. Since this was the only place the method was being called we decided to delete the below code snippet.

def show_available_submissions
assignment = Assignment.find(params[:assignment_id])
reviewer = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
requested_topic_id = params[:topic_id]
@available_submissions = Hash.new
@available_submissions = DynamicReviewAssignmentHelper::review_assignment(assignment.id ,
reviewer.id,
requested_topic_id ,
Assignment::RS_STUDENT_SELECTED)

On further understanding the code we noticed this was the only call being made to dynamic_review_assignment_helper.rb and that this helper is not used in instructor selected and auto selected reviewing strategies. For these strategies another view is being rendered specifically _set_dynamic_review.html.erb.
Similarly dynamic_quiz_assignment_helper.rb is also not being used by any controller.
Hence we decided to go ahead and delete these two files after confirmation from the developer.

=='''References'''==
<references/>

CSC/ECE 517 Fall 2015/oss E1552 NRR

2015-11-01T01:22:15Z

Rahuja: /* What needs to be done */

'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb'''
=='''Overview'''==
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure
<ref>Refactoring: Improving the Design of Existing Code -
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Robert
[https://books.google.com/books/about/Refactoring.html?id=HmrDHwgkbPsC&printsec=frontcover&source=kp_read_button#v=onepage&q&f=false]</ref>. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
There are many benefits of refactoring as follows:
<ref>Refactoring Software using Design Patterns - by Masatomo Noborikawa
[http://www.cs.uni.edu/~wallingf/miscellaneous/student-papers/noborikawa-paper.pdf]</ref>

* Refactoring improves the design of software. Refactoring often cleans up codes by deleting duplicates, divides a big chunk of codes into several methods, and makes the program more understandable.
* Because refactoring makes a design cleaner, it helps the programmers understand codes better and see things that may have not been seen before.
* Refactoring helps spot bugs since it makes the software more comprehensible.
* Refactoring turns an adverse design into a good design, which allows for rapid software development.

__TOC__

=='''Peer Reviewing'''==
It is the process of evaluating work done by an individual or a team by another team or an individual with expertise in the concerned area.
Types of Reviewing Strategies in Expertiza -

* Instructor Selected Reviewing - Using this strategy the instructor assigns reviews to all participants of the assignment. After selecting this strategy the instructor has the following two options -
** Set number of reviews done by each student.
** Set minimum number of reviews done for each submission.
Then the instructor can click on assign reviewers and map the students to the topics which should be reviewed by them.

[[File:editing_assignment.png‎ |frame|center|Instructor selected Reviewing]]

* Auto Selected Reviewing - If the instructor selects this strategy, students need to select reviews themselves. Either the student is given a list of topics to choose from and he selects which topic he wants to review, or he checks “I don’t care which topic I review” and he/she will be randomly assigned a topic to review. The instructor can also specify two parameters after selecting this strategy -
** Review topic threshold: - Let us assume Topic 1 has a submission than has not been reviewed. Topic 2 has submissions that has been reviewed atleast 2 times and k is set 2. Then the student will not be able to select topic 2 until all of topic 1’s submission has been reviewed atleast 2 times.
** Maximum number of reviews per submission: - This specifies the maximum number of times a particular top can be reviewed.

[[File:editing_assignment_2.png‎ |frame|center|Auto selected Reviewing]]

* Student Selected Reviewing -
In this strategy the student selects a particular submission to review instead of a particular topic. This feature had never been used and did not work correctly. Hence it has been removed from the system. However there are a lot of places where the code for student selected reviewing exists however it not being called anywhere.

=='''Project Resources'''==
* [https://github.com/rahuja910/expertiza GitHub Repository]
* [https://github.com/expertiza/expertiza/pull/602 GitHub Pull Request Link]
* [http://152.46.20.183:3000/ VCL Deployment Link] (For Instructor - username: instructor6, password: password. For student - username: student5700, password: password)

=='''Problem Statement'''==
==='''Classes involved'''===
dynamic_quiz_assignment_helper.rb
dynamic_review_assignment_helper.rb
review_mapping_controller.rb

==='''What it does''' ===
dynamic_review_assignment_helper.rb allows the system choose a team to review when a student chooses a topic to review. It helps the code choose topics that have submissions with fewer reviews than other topics. A threshold k is used to decide whether a particular topic can be chosen. If, e.g., Topic 1 has a submission that has not yet been reviewed, and Topic 2 has no submission that has been reviewed by fewer than 3 reviewers, then the incoming reviewer can only choose Topic 2 if k ≥ 3. This class does not actually decide what is reviewable, but it does make up a sorted list of the submissions by the number of the reviews they have. dynamic_quiz_assignment_helper.rb is similar, but for quizzes.

==='''What needs to be done'''===
* Remove the code for “student-selected” reviewing
* The find_submissions_in_current_cycle method returns a list of participants. It should return a list of teams.
* Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes
* The two classes have a lot of duplicated code. Remove all DRY problems.

=='''Modification of find_submissions_in_current_cycle method'''==

This function returns a list of participants for the particular assignment. This leads to redundant entries in the hash since most teams are made up of more than one member. Earlier the submissions belonged to participants rather than teams, however currently there is no need for this since if an instructor wants individual assignments he/she simply selects maximum number of size of a team as one. Correspondingly changes need to be made to the call sites.

* Before Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentParticipant.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
users = TeamsUser.where(team_id: signUp.team_id)
users.each do |user|
participant = Participant.where(user_id: user_id, parent_id: @assignment_id)
if participant
submissions_in_current_cycle << participant
end
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

* After Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentTeam.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
team=Team.where(team_id: signUp.team_id)
if team
submissions_in_current_cycle << team
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

As seen from the above code we have replaced AssignmentParticipant with AssignmentTeam. Now submissions_in_current_cycle will contain list of participants rather than a list of teams. Also note the model for AssignmentTeam contains the same methods which are present in the model for AssignmentParticipant. In the same helper class we had to modify code to handle the aspect that submissions_in_current_cycle now contains teams rather than participants. Hence we made changes in build_submissions_availability().

=='''Implementation of Criteria'''==
'''Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes.''' 
The helper classes while returning a list of teams should check the below set of conditions. Each of the below conditions need to be checked at one place to ensure better code readability and maintainability.

* The article was not written by the potential reviewer.
The potential reviewer should not be able to review its own submission and hence a check for this condition is required. However, it was already implemented in the code beforehand.

* The article was not already reviewed by the potential reviewer.
The potential reviewer should not be able to review a topic which is already reviewed by him/her. The same was also implemented along with the above condition.

* The article is not on the same topic as the potential reviewer has previously written about.
The reviewer should not be able to review on the same topic that he/she submitted as the reviewer could give biased reviews to make his/her own submission seem better. This was not implemented previously and was implemented in the code changes by checking the topic id.

'''Implementation :''' 
<pre>
def self.build_submissions_availability()
least_review_count = -1;
max_no_reviews = 5
reviewer_teams=TeamsUser.where(user_id: @reviewer_id)

@submissions_availability = Hash.new
unless @submissions_in_current_cycle.nil?
@submissions_in_current_cycle.each { |submission|
team_check=false
if( least_review_count == -1)
least_review_count = submission[1]
end
reviewer_teams.each do |reviewer_team|
if submission[0] == reviewer_team.team_id
team_check=true
end
end

if !team_check
@submissions_availability[submission[0]] = get_state(least_review_count,submission[1],max_no_reviews)
end
}
end
return @submissions_availability
end
</pre>

* The article does not already have the maximum number of potential reviews in progress.
The reviewer should only be able to review topics that have not reached the maximum number of reviews. The check for the same is done in get_state method where the current_review_count is compared with max_review_count and make it unavailable.

* The article has the minimum number of reviews for that assignment.
The article is made available if it has the minimum number of reviews for the assignment and the same is checked in get_state method where the current_review_count is compared with least_review_count and make it available.

'''Implementation:''' 
<pre>
def self.get_state(least_review_count,current_review_count,max_review_count)
if(current_review_count != -1 && current_review_count == max_review_count)
return -1
elsif(current_review_count != -1 && current_review_count > least_review_count)
return 1
elsif(current_review_count != -1 && current_review_count == least_review_count)
return 0
end
end
</pre>

=='''Deletion of "student-selected" reviewing'''==
The following files had code for “student-selected” reviewing –

* dynamic_quiz_assignment_helper.rb
* dynamic_review_assignment_helper.rb
* review_mapping_controller.rb

In student-selected reviewing, a student was allowed to review a particular submission and not just a particular topic.The functionality for “student-selected” reviewing was never implemented successfully. Hence, the methods corresponding to the aforementioned functionality were removed from respective files.

Changes were made at the following places - 
* dynamic_quiz_assignment_helper.rb
<pre>
# TODO: Remove this helper, this code is not well-designed.
# Look at Assignment.contributor_to_review() as an example of a better approach
module DynamicQuizAssignmentHelper

# * The article was not written by the potential reviewer.
# * The article was not already reviewed by the potential reviewer.
# * The article is not on the same topic as the potential reviewer has previously written about.
# * The article does not already have the maximum number of potential reviews in progress.
# * The article has the minimum number of reviews for that assignment.

def self.quiz_assignment(assignment_id, reviewer_id, questionnaire_id, quiz_type )
@assignment_id = assignment_id
@current_assignment = Assignment.find(assignment_id)
@reviewer_id = reviewer_id
@questionnaire_id = questionnaire_id

if (quiz_type == Assignment::RS_STUDENT_SELECTED)
@questionnaires = Array.new
@questionnaires << Questionnaire.find(@questionnaire_id)#student_selected_quiz_assignment( )
return @questionnaires
else
return nil
end
end
</pre>

* dynamic_review_assignment_helper.rb
<pre>
# TODO: Remove this helper, this code is not well-designed.
# Look at Assignment.contributor_to_review() as an example of a better approach
module DynamicReviewAssignmentHelper

# * The article was not written by the potential reviewer.
# * The article was not already reviewed by the potential reviewer.
# * The article is not on the same topic as the potential reviewer has previously written about.
# * The article does not already have the maximum number of potential reviews in progress.
# * The article has the minimum number of reviews for that assignment.

def self.review_assignment(assignment_id, reviewer_id, topic_id, review_type )
@assignment_id = assignment_id
@current_assignment = Assignment.find(assignment_id)
@reviewer_id = reviewer_id
@topic_id = topic_id

if (review_type == Assignment::RS_STUDENT_SELECTED)
return student_selected_review_assignment( )
else
return nil
end
end
</pre>

* review_mapping_controller.rb
<pre>
# Get all the available submissions
def show_available_submissions
assignment = Assignment.find(params[:assignment_id])
reviewer = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
requested_topic_id = params[:topic_id]
@available_submissions = Hash.new
@available_submissions = DynamicReviewAssignmentHelper::review_assignment(assignment.id, reviewer.id, requested_topic_id, Assignment::RS_STUDENT_SELECTED)
end
</pre>

=='''References'''==
<references/>

CSC/ECE 517 Fall 2015/oss E1552 NRR

2015-11-01T01:21:31Z

Rahuja: /* What needs to be done */

'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb'''
=='''Overview'''==
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure
<ref>Refactoring: Improving the Design of Existing Code -
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Robert
[https://books.google.com/books/about/Refactoring.html?id=HmrDHwgkbPsC&printsec=frontcover&source=kp_read_button#v=onepage&q&f=false]</ref>. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
There are many benefits of refactoring as follows:
<ref>Refactoring Software using Design Patterns - by Masatomo Noborikawa
[http://www.cs.uni.edu/~wallingf/miscellaneous/student-papers/noborikawa-paper.pdf]</ref>

* Refactoring improves the design of software. Refactoring often cleans up codes by deleting duplicates, divides a big chunk of codes into several methods, and makes the program more understandable.
* Because refactoring makes a design cleaner, it helps the programmers understand codes better and see things that may have not been seen before.
* Refactoring helps spot bugs since it makes the software more comprehensible.
* Refactoring turns an adverse design into a good design, which allows for rapid software development.

__TOC__

=='''Peer Reviewing'''==
It is the process of evaluating work done by an individual or a team by another team or an individual with expertise in the concerned area.
Types of Reviewing Strategies in Expertiza -

* Instructor Selected Reviewing - Using this strategy the instructor assigns reviews to all participants of the assignment. After selecting this strategy the instructor has the following two options -
** Set number of reviews done by each student.
** Set minimum number of reviews done for each submission.
Then the instructor can click on assign reviewers and map the students to the topics which should be reviewed by them.

[[File:editing_assignment.png‎ |frame|center|Instructor selected Reviewing]]

* Auto Selected Reviewing - If the instructor selects this strategy, students need to select reviews themselves. Either the student is given a list of topics to choose from and he selects which topic he wants to review, or he checks “I don’t care which topic I review” and he/she will be randomly assigned a topic to review. The instructor can also specify two parameters after selecting this strategy -
** Review topic threshold: - Let us assume Topic 1 has a submission than has not been reviewed. Topic 2 has submissions that has been reviewed atleast 2 times and k is set 2. Then the student will not be able to select topic 2 until all of topic 1’s submission has been reviewed atleast 2 times.
** Maximum number of reviews per submission: - This specifies the maximum number of times a particular top can be reviewed.

[[File:editing_assignment_2.png‎ |frame|center|Auto selected Reviewing]]

* Student Selected Reviewing -
In this strategy the student selects a particular submission to review instead of a particular topic. This feature had never been used and did not work correctly. Hence it has been removed from the system. However there are a lot of places where the code for student selected reviewing exists however it not being called anywhere.

=='''Project Resources'''==
* [https://github.com/rahuja910/expertiza GitHub Repository]
* [https://github.com/expertiza/expertiza/pull/602 GitHub Pull Request Link]
* [http://152.46.20.183:3000/ VCL Deployment Link] (For Instructor - username: instructor6, password: password. For student - username: student5700, password: password)

=='''Problem Statement'''==
==='''Classes involved'''===
dynamic_quiz_assignment_helper.rb
dynamic_review_assignment_helper.rb
review_mapping_controller.rb

==='''What it does''' ===
dynamic_review_assignment_helper.rb allows the system choose a team to review when a student chooses a topic to review. It helps the code choose topics that have submissions with fewer reviews than other topics. A threshold k is used to decide whether a particular topic can be chosen. If, e.g., Topic 1 has a submission that has not yet been reviewed, and Topic 2 has no submission that has been reviewed by fewer than 3 reviewers, then the incoming reviewer can only choose Topic 2 if k ≥ 3. This class does not actually decide what is reviewable, but it does make up a sorted list of the submissions by the number of the reviews they have. dynamic_quiz_assignment_helper.rb is similar, but for quizzes.

==='''What needs to be done'''===
* Remove the code for “student-selected” reviewing
* The find_submissions_in_current_cycle method returns a list of participants. It should return a list of team.
* Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes
* The two classes have a lot of duplicated code. Remove all DRY problems.

=='''Modification of find_submissions_in_current_cycle method'''==

This function returns a list of participants for the particular assignment. This leads to redundant entries in the hash since most teams are made up of more than one member. Earlier the submissions belonged to participants rather than teams, however currently there is no need for this since if an instructor wants individual assignments he/she simply selects maximum number of size of a team as one. Correspondingly changes need to be made to the call sites.

* Before Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentParticipant.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
users = TeamsUser.where(team_id: signUp.team_id)
users.each do |user|
participant = Participant.where(user_id: user_id, parent_id: @assignment_id)
if participant
submissions_in_current_cycle << participant
end
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

* After Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentTeam.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
team=Team.where(team_id: signUp.team_id)
if team
submissions_in_current_cycle << team
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

As seen from the above code we have replaced AssignmentParticipant with AssignmentTeam. Now submissions_in_current_cycle will contain list of participants rather than a list of teams. Also note the model for AssignmentTeam contains the same methods which are present in the model for AssignmentParticipant. In the same helper class we had to modify code to handle the aspect that submissions_in_current_cycle now contains teams rather than participants. Hence we made changes in build_submissions_availability().

=='''Implementation of Criteria'''==
'''Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes.''' 
The helper classes while returning a list of teams should check the below set of conditions. Each of the below conditions need to be checked at one place to ensure better code readability and maintainability.

* The article was not written by the potential reviewer.
The potential reviewer should not be able to review its own submission and hence a check for this condition is required. However, it was already implemented in the code beforehand.

* The article was not already reviewed by the potential reviewer.
The potential reviewer should not be able to review a topic which is already reviewed by him/her. The same was also implemented along with the above condition.

* The article is not on the same topic as the potential reviewer has previously written about.
The reviewer should not be able to review on the same topic that he/she submitted as the reviewer could give biased reviews to make his/her own submission seem better. This was not implemented previously and was implemented in the code changes by checking the topic id.

'''Implementation :''' 
<pre>
def self.build_submissions_availability()
least_review_count = -1;
max_no_reviews = 5
reviewer_teams=TeamsUser.where(user_id: @reviewer_id)

@submissions_availability = Hash.new
unless @submissions_in_current_cycle.nil?
@submissions_in_current_cycle.each { |submission|
team_check=false
if( least_review_count == -1)
least_review_count = submission[1]
end
reviewer_teams.each do |reviewer_team|
if submission[0] == reviewer_team.team_id
team_check=true
end
end

if !team_check
@submissions_availability[submission[0]] = get_state(least_review_count,submission[1],max_no_reviews)
end
}
end
return @submissions_availability
end
</pre>

* The article does not already have the maximum number of potential reviews in progress.
The reviewer should only be able to review topics that have not reached the maximum number of reviews. The check for the same is done in get_state method where the current_review_count is compared with max_review_count and make it unavailable.

* The article has the minimum number of reviews for that assignment.
The article is made available if it has the minimum number of reviews for the assignment and the same is checked in get_state method where the current_review_count is compared with least_review_count and make it available.

'''Implementation:''' 
<pre>
def self.get_state(least_review_count,current_review_count,max_review_count)
if(current_review_count != -1 && current_review_count == max_review_count)
return -1
elsif(current_review_count != -1 && current_review_count > least_review_count)
return 1
elsif(current_review_count != -1 && current_review_count == least_review_count)
return 0
end
end
</pre>

=='''Deletion of "student-selected" reviewing'''==
The following files had code for “student-selected” reviewing –

* dynamic_quiz_assignment_helper.rb
* dynamic_review_assignment_helper.rb
* review_mapping_controller.rb

In student-selected reviewing, a student was allowed to review a particular submission and not just a particular topic.The functionality for “student-selected” reviewing was never implemented successfully. Hence, the methods corresponding to the aforementioned functionality were removed from respective files.

Changes were made at the following places - 
* dynamic_quiz_assignment_helper.rb
<pre>
# TODO: Remove this helper, this code is not well-designed.
# Look at Assignment.contributor_to_review() as an example of a better approach
module DynamicQuizAssignmentHelper

# * The article was not written by the potential reviewer.
# * The article was not already reviewed by the potential reviewer.
# * The article is not on the same topic as the potential reviewer has previously written about.
# * The article does not already have the maximum number of potential reviews in progress.
# * The article has the minimum number of reviews for that assignment.

def self.quiz_assignment(assignment_id, reviewer_id, questionnaire_id, quiz_type )
@assignment_id = assignment_id
@current_assignment = Assignment.find(assignment_id)
@reviewer_id = reviewer_id
@questionnaire_id = questionnaire_id

if (quiz_type == Assignment::RS_STUDENT_SELECTED)
@questionnaires = Array.new
@questionnaires << Questionnaire.find(@questionnaire_id)#student_selected_quiz_assignment( )
return @questionnaires
else
return nil
end
end
</pre>

* dynamic_review_assignment_helper.rb
<pre>
# TODO: Remove this helper, this code is not well-designed.
# Look at Assignment.contributor_to_review() as an example of a better approach
module DynamicReviewAssignmentHelper

# * The article was not written by the potential reviewer.
# * The article was not already reviewed by the potential reviewer.
# * The article is not on the same topic as the potential reviewer has previously written about.
# * The article does not already have the maximum number of potential reviews in progress.
# * The article has the minimum number of reviews for that assignment.

def self.review_assignment(assignment_id, reviewer_id, topic_id, review_type )
@assignment_id = assignment_id
@current_assignment = Assignment.find(assignment_id)
@reviewer_id = reviewer_id
@topic_id = topic_id

if (review_type == Assignment::RS_STUDENT_SELECTED)
return student_selected_review_assignment( )
else
return nil
end
end
</pre>

* review_mapping_controller.rb
<pre>
# Get all the available submissions
def show_available_submissions
assignment = Assignment.find(params[:assignment_id])
reviewer = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
requested_topic_id = params[:topic_id]
@available_submissions = Hash.new
@available_submissions = DynamicReviewAssignmentHelper::review_assignment(assignment.id, reviewer.id, requested_topic_id, Assignment::RS_STUDENT_SELECTED)
end
</pre>

=='''References'''==
<references/>

CSC/ECE 517 Fall 2015/oss E1552 NRR

2015-11-01T01:12:18Z

Rahuja: /* Deletion of "student-selected" reviewing */

'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb'''
=='''Overview'''==
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure
<ref>Refactoring: Improving the Design of Existing Code -
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Robert
[https://books.google.com/books/about/Refactoring.html?id=HmrDHwgkbPsC&printsec=frontcover&source=kp_read_button#v=onepage&q&f=false]</ref>. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
There are many benefits of refactoring as follows:
<ref>Refactoring Software using Design Patterns - by Masatomo Noborikawa
[http://www.cs.uni.edu/~wallingf/miscellaneous/student-papers/noborikawa-paper.pdf]</ref>

* Refactoring improves the design of software. Refactoring often cleans up codes by deleting duplicates, divides a big chunk of codes into several methods, and makes the program more understandable.
* Because refactoring makes a design cleaner, it helps the programmers understand codes better and see things that may have not been seen before.
* Refactoring helps spot bugs since it makes the software more comprehensible.
* Refactoring turns an adverse design into a good design, which allows for rapid software development.

__TOC__

=='''Peer Reviewing'''==
It is the process of evaluating work done by an individual or a team by another team or an individual with expertise in the concerned area.
Types of Reviewing Strategies in Expertiza -

* Instructor Selected Reviewing - Using this strategy the instructor assigns reviews to all participants of the assignment. After selecting this strategy the instructor has the following two options -
** Set number of reviews done by each student.
** Set minimum number of reviews done for each submission.
Then the instructor can click on assign reviewers and map the students to the topics which should be reviewed by them.

[[File:editing_assignment.png‎ |frame|center|Instructor selected Reviewing]]

* Auto Selected Reviewing - If the instructor selects this strategy, students need to select reviews themselves. Either the student is given a list of topics to choose from and he selects which topic he wants to review, or he checks “I don’t care which topic I review” and he/she will be randomly assigned a topic to review. The instructor can also specify two parameters after selecting this strategy -
** Review topic threshold: - Let us assume Topic 1 has a submission than has not been reviewed. Topic 2 has submissions that has been reviewed atleast 2 times and k is set 2. Then the student will not be able to select topic 2 until all of topic 1’s submission has been reviewed atleast 2 times.
** Maximum number of reviews per submission: - This specifies the maximum number of times a particular top can be reviewed.

[[File:editing_assignment_2.png‎ |frame|center|Auto selected Reviewing]]

* Student Selected Reviewing -
In this strategy the student selects a particular submission to review instead of a particular topic. This feature had never been used and did not work correctly. Hence it has been removed from the system. However there are a lot of places where the code for student selected reviewing exists however it not being called anywhere.

=='''Project Resources'''==
* [https://github.com/rahuja910/expertiza GitHub Repository]
* [https://github.com/expertiza/expertiza/pull/602 GitHub Pull Request Link]
* [http://152.46.20.183:3000/ VCL Deployment Link] (For Instructor - username: instructor6, password: password. For student - username: student5700, password: password)

=='''Problem Statement'''==
==='''Classes involved'''===
dynamic_quiz_assignment_helper.rb
dynamic_review_assignment_helper.rb
review_mapping_controller.rb

==='''What it does''' ===
dynamic_review_assignment_helper.rb allows the system choose a team to review when a student chooses a topic to review. It helps the code choose topics that have submissions with fewer reviews than other topics. A threshold k is used to decide whether a particular topic can be chosen. If, e.g., Topic 1 has a submission that has not yet been reviewed, and Topic 2 has no submission that has been reviewed by fewer than 3 reviewers, then the incoming reviewer can only choose Topic 2 if k ≥ 3. This class does not actually decide what is reviewable, but it does make up a sorted list of the submissions by the number of the reviews they have. dynamic_quiz_assignment_helper.rb is similar, but for quizzes.

==='''What needs to be done'''===
* The find_submissions_in_current_cycle method returns a list of participants. It should return a list of teams. Returning a list of participants leads to redundant entries in the hash, if they are done by multi-member teams. There used to be a need for dealing with participants rather than teams, but in the current Expertiza, submissions always belong to teams rather than individuals. (This may also require changing the call site for some calls to methods of this class.)
* The comment at the beginning of the class lists a number of criteria that have to hold for a submission to be reviewable (e.g., it was not written by the potential reviewer, it has not already been reviewed by the potential reviewer). It’s not clear where these conditions are checked for. Probably the different conditions are checked for in different places. Sometimes they are checked for late (e.g., if a user has written on Topic 2, (s)he is allowed to select Topic 2 as a topic to review, but after (s)he selects it, (s)he is told that there are no more submissions to review on that topic). It would be better to check for all of these conditions in dynamic_review_assignment_helper; then the user would not even be able to select topics that have no available reviews.
* There is code for “student-selected” reviewing. This would have allowed a student to choose a particular submission, not just a particular topic. This feature had never been used, and did not work correctly, so we removed it from the system. Thus, the code for student-selected reviewing should be removed.
* The two classes have a lot of duplicated code. Remove all DRY problems.

=='''Modification of find_submissions_in_current_cycle method'''==

This function returns a list of participants for the particular assignment. This leads to redundant entries in the hash since most teams are made up of more than one member. Earlier the submissions belonged to participants rather than teams, however currently there is no need for this since if an instructor wants individual assignments he/she simply selects maximum number of size of a team as one. Correspondingly changes need to be made to the call sites.

* Before Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentParticipant.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
users = TeamsUser.where(team_id: signUp.team_id)
users.each do |user|
participant = Participant.where(user_id: user_id, parent_id: @assignment_id)
if participant
submissions_in_current_cycle << participant
end
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

* After Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentTeam.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
team=Team.where(team_id: signUp.team_id)
if team
submissions_in_current_cycle << team
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

As seen from the above code we have replaced AssignmentParticipant with AssignmentTeam. Now submissions_in_current_cycle will contain list of participants rather than a list of teams. Also note the model for AssignmentTeam contains the same methods which are present in the model for AssignmentParticipant. In the same helper class we had to modify code to handle the aspect that submissions_in_current_cycle now contains teams rather than participants. Hence we made changes in build_submissions_availability().

=='''Implementation of Criteria'''==
'''Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes.''' 
The helper classes while returning a list of teams should check the below set of conditions. Each of the below conditions need to be checked at one place to ensure better code readability and maintainability.

* The article was not written by the potential reviewer.
The potential reviewer should not be able to review its own submission and hence a check for this condition is required. However, it was already implemented in the code beforehand.

* The article was not already reviewed by the potential reviewer.
The potential reviewer should not be able to review a topic which is already reviewed by him/her. The same was also implemented along with the above condition.

* The article is not on the same topic as the potential reviewer has previously written about.
The reviewer should not be able to review on the same topic that he/she submitted as the reviewer could give biased reviews to make his/her own submission seem better. This was not implemented previously and was implemented in the code changes by checking the topic id.

'''Implementation :''' 
<pre>
def self.build_submissions_availability()
least_review_count = -1;
max_no_reviews = 5
reviewer_teams=TeamsUser.where(user_id: @reviewer_id)

@submissions_availability = Hash.new
unless @submissions_in_current_cycle.nil?
@submissions_in_current_cycle.each { |submission|
team_check=false
if( least_review_count == -1)
least_review_count = submission[1]
end
reviewer_teams.each do |reviewer_team|
if submission[0] == reviewer_team.team_id
team_check=true
end
end

if !team_check
@submissions_availability[submission[0]] = get_state(least_review_count,submission[1],max_no_reviews)
end
}
end
return @submissions_availability
end
</pre>

* The article does not already have the maximum number of potential reviews in progress.
The reviewer should only be able to review topics that have not reached the maximum number of reviews. The check for the same is done in get_state method where the current_review_count is compared with max_review_count and make it unavailable.

* The article has the minimum number of reviews for that assignment.
The article is made available if it has the minimum number of reviews for the assignment and the same is checked in get_state method where the current_review_count is compared with least_review_count and make it available.

'''Implementation:''' 
<pre>
def self.get_state(least_review_count,current_review_count,max_review_count)
if(current_review_count != -1 && current_review_count == max_review_count)
return -1
elsif(current_review_count != -1 && current_review_count > least_review_count)
return 1
elsif(current_review_count != -1 && current_review_count == least_review_count)
return 0
end
end
</pre>

=='''Deletion of "student-selected" reviewing'''==
The following files had code for “student-selected” reviewing –

* dynamic_quiz_assignment_helper.rb
* dynamic_review_assignment_helper.rb
* review_mapping_controller.rb

In student-selected reviewing, a student was allowed to review a particular submission and not just a particular topic.The functionality for “student-selected” reviewing was never implemented successfully. Hence, the methods corresponding to the aforementioned functionality were removed from respective files.

Changes were made at the following places - 
* dynamic_quiz_assignment_helper.rb
<pre>
# TODO: Remove this helper, this code is not well-designed.
# Look at Assignment.contributor_to_review() as an example of a better approach
module DynamicQuizAssignmentHelper

# * The article was not written by the potential reviewer.
# * The article was not already reviewed by the potential reviewer.
# * The article is not on the same topic as the potential reviewer has previously written about.
# * The article does not already have the maximum number of potential reviews in progress.
# * The article has the minimum number of reviews for that assignment.

def self.quiz_assignment(assignment_id, reviewer_id, questionnaire_id, quiz_type )
@assignment_id = assignment_id
@current_assignment = Assignment.find(assignment_id)
@reviewer_id = reviewer_id
@questionnaire_id = questionnaire_id

if (quiz_type == Assignment::RS_STUDENT_SELECTED)
@questionnaires = Array.new
@questionnaires << Questionnaire.find(@questionnaire_id)#student_selected_quiz_assignment( )
return @questionnaires
else
return nil
end
end
</pre>

* dynamic_review_assignment_helper.rb
<pre>
# TODO: Remove this helper, this code is not well-designed.
# Look at Assignment.contributor_to_review() as an example of a better approach
module DynamicReviewAssignmentHelper

# * The article was not written by the potential reviewer.
# * The article was not already reviewed by the potential reviewer.
# * The article is not on the same topic as the potential reviewer has previously written about.
# * The article does not already have the maximum number of potential reviews in progress.
# * The article has the minimum number of reviews for that assignment.

def self.review_assignment(assignment_id, reviewer_id, topic_id, review_type )
@assignment_id = assignment_id
@current_assignment = Assignment.find(assignment_id)
@reviewer_id = reviewer_id
@topic_id = topic_id

if (review_type == Assignment::RS_STUDENT_SELECTED)
return student_selected_review_assignment( )
else
return nil
end
end
</pre>

* review_mapping_controller.rb
<pre>
# Get all the available submissions
def show_available_submissions
assignment = Assignment.find(params[:assignment_id])
reviewer = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
requested_topic_id = params[:topic_id]
@available_submissions = Hash.new
@available_submissions = DynamicReviewAssignmentHelper::review_assignment(assignment.id, reviewer.id, requested_topic_id, Assignment::RS_STUDENT_SELECTED)
end
</pre>

=='''References'''==
<references/>

CSC/ECE 517 Fall 2015/oss E1552 NRR

2015-11-01T01:00:10Z

Rahuja: /* Modification of find_submissions_in_current_cycle method */

'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb'''
=='''Overview'''==
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure
<ref>Refactoring: Improving the Design of Existing Code -
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Robert
[https://books.google.com/books/about/Refactoring.html?id=HmrDHwgkbPsC&printsec=frontcover&source=kp_read_button#v=onepage&q&f=false]</ref>. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
There are many benefits of refactoring as follows:
<ref>Refactoring Software using Design Patterns - by Masatomo Noborikawa
[http://www.cs.uni.edu/~wallingf/miscellaneous/student-papers/noborikawa-paper.pdf]</ref>

* Refactoring improves the design of software. Refactoring often cleans up codes by deleting duplicates, divides a big chunk of codes into several methods, and makes the program more understandable.
* Because refactoring makes a design cleaner, it helps the programmers understand codes better and see things that may have not been seen before.
* Refactoring helps spot bugs since it makes the software more comprehensible.
* Refactoring turns an adverse design into a good design, which allows for rapid software development.

__TOC__

=='''Peer Reviewing'''==
It is the process of evaluating work done by an individual or a team by another team or an individual with expertise in the concerned area.
Types of Reviewing Strategies in Expertiza -

* Instructor Selected Reviewing - Using this strategy the instructor assigns reviews to all participants of the assignment. After selecting this strategy the instructor has the following two options -
** Set number of reviews done by each student.
** Set minimum number of reviews done for each submission.
Then the instructor can click on assign reviewers and map the students to the topics which should be reviewed by them.

[[File:editing_assignment.png‎ |frame|center|Instructor selected Reviewing]]

* Auto Selected Reviewing - If the instructor selects this strategy, students need to select reviews themselves. Either the student is given a list of topics to choose from and he selects which topic he wants to review, or he checks “I don’t care which topic I review” and he/she will be randomly assigned a topic to review. The instructor can also specify two parameters after selecting this strategy -
** Review topic threshold: - Let us assume Topic 1 has a submission than has not been reviewed. Topic 2 has submissions that has been reviewed atleast 2 times and k is set 2. Then the student will not be able to select topic 2 until all of topic 1’s submission has been reviewed atleast 2 times.
** Maximum number of reviews per submission: - This specifies the maximum number of times a particular top can be reviewed.

[[File:editing_assignment_2.png‎ |frame|center|Auto selected Reviewing]]

* Student Selected Reviewing -
In this strategy the student selects a particular submission to review instead of a particular topic. This feature had never been used and did not work correctly. Hence it has been removed from the system. However there are a lot of places where the code for student selected reviewing exists however it not being called anywhere.

=='''Project Resources'''==
* [https://github.com/rahuja910/expertiza GitHub Repository]
* [https://github.com/expertiza/expertiza/pull/602 GitHub Pull Request Link]
* [http://152.46.20.183:3000/ VCL Deployment Link] (For Instructor - username: instructor6, password: password. For student - username: student5700, password: password)

=='''Problem Statement'''==
==='''Classes involved'''===
dynamic_quiz_assignment_helper.rb
dynamic_review_assignment_helper.rb
review_mapping_controller.rb

==='''What it does''' ===
dynamic_review_assignment_helper.rb allows the system choose a team to review when a student chooses a topic to review. It helps the code choose topics that have submissions with fewer reviews than other topics. A threshold k is used to decide whether a particular topic can be chosen. If, e.g., Topic 1 has a submission that has not yet been reviewed, and Topic 2 has no submission that has been reviewed by fewer than 3 reviewers, then the incoming reviewer can only choose Topic 2 if k ≥ 3. This class does not actually decide what is reviewable, but it does make up a sorted list of the submissions by the number of the reviews they have. dynamic_quiz_assignment_helper.rb is similar, but for quizzes.

==='''What needs to be done'''===
* The find_submissions_in_current_cycle method returns a list of participants. It should return a list of teams. Returning a list of participants leads to redundant entries in the hash, if they are done by multi-member teams. There used to be a need for dealing with participants rather than teams, but in the current Expertiza, submissions always belong to teams rather than individuals. (This may also require changing the call site for some calls to methods of this class.)
* The comment at the beginning of the class lists a number of criteria that have to hold for a submission to be reviewable (e.g., it was not written by the potential reviewer, it has not already been reviewed by the potential reviewer). It’s not clear where these conditions are checked for. Probably the different conditions are checked for in different places. Sometimes they are checked for late (e.g., if a user has written on Topic 2, (s)he is allowed to select Topic 2 as a topic to review, but after (s)he selects it, (s)he is told that there are no more submissions to review on that topic). It would be better to check for all of these conditions in dynamic_review_assignment_helper; then the user would not even be able to select topics that have no available reviews.
* There is code for “student-selected” reviewing. This would have allowed a student to choose a particular submission, not just a particular topic. This feature had never been used, and did not work correctly, so we removed it from the system. Thus, the code for student-selected reviewing should be removed.
* The two classes have a lot of duplicated code. Remove all DRY problems.

=='''Modification of find_submissions_in_current_cycle method'''==

This function returns a list of participants for the particular assignment. This leads to redundant entries in the hash since most teams are made up of more than one member. Earlier the submissions belonged to participants rather than teams, however currently there is no need for this since if an instructor wants individual assignments he/she simply selects maximum number of size of a team as one. Correspondingly changes need to be made to the call sites.

* Before Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentParticipant.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
users = TeamsUser.where(team_id: signUp.team_id)
users.each do |user|
participant = Participant.where(user_id: user_id, parent_id: @assignment_id)
if participant
submissions_in_current_cycle << participant
end
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

* After Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentTeam.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
team=Team.where(team_id: signUp.team_id)
if team
submissions_in_current_cycle << team
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

As seen from the above code we have replaced AssignmentParticipant with AssignmentTeam. Now submissions_in_current_cycle will contain list of participants rather than a list of teams. Also note the model for AssignmentTeam contains the same methods which are present in the model for AssignmentParticipant. In the same helper class we had to modify code to handle the aspect that submissions_in_current_cycle now contains teams rather than participants. Hence we made changes in build_submissions_availability().

=='''Implementation of Criteria'''==
'''Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes.''' 
The helper classes while returning a list of teams should check the below set of conditions. Each of the below conditions need to be checked at one place to ensure better code readability and maintainability.

* The article was not written by the potential reviewer.
The potential reviewer should not be able to review its own submission and hence a check for this condition is required. However, it was already implemented in the code beforehand.

* The article was not already reviewed by the potential reviewer.
The potential reviewer should not be able to review a topic which is already reviewed by him/her. The same was also implemented along with the above condition.

* The article is not on the same topic as the potential reviewer has previously written about.
The reviewer should not be able to review on the same topic that he/she submitted as the reviewer could give biased reviews to make his/her own submission seem better. This was not implemented previously and was implemented in the code changes by checking the topic id.

'''Implementation :''' 
<pre>
def self.build_submissions_availability()
least_review_count = -1;
max_no_reviews = 5
reviewer_teams=TeamsUser.where(user_id: @reviewer_id)

@submissions_availability = Hash.new
unless @submissions_in_current_cycle.nil?
@submissions_in_current_cycle.each { |submission|
team_check=false
if( least_review_count == -1)
least_review_count = submission[1]
end
reviewer_teams.each do |reviewer_team|
if submission[0] == reviewer_team.team_id
team_check=true
end
end

if !team_check
@submissions_availability[submission[0]] = get_state(least_review_count,submission[1],max_no_reviews)
end
}
end
return @submissions_availability
end
</pre>

* The article does not already have the maximum number of potential reviews in progress.
The reviewer should only be able to review topics that have not reached the maximum number of reviews. The check for the same is done in get_state method where the current_review_count is compared with max_review_count and make it unavailable.

* The article has the minimum number of reviews for that assignment.
The article is made available if it has the minimum number of reviews for the assignment and the same is checked in get_state method where the current_review_count is compared with least_review_count and make it available.

'''Implementation:''' 
<pre>
def self.get_state(least_review_count,current_review_count,max_review_count)
if(current_review_count != -1 && current_review_count == max_review_count)
return -1
elsif(current_review_count != -1 && current_review_count > least_review_count)
return 1
elsif(current_review_count != -1 && current_review_count == least_review_count)
return 0
end
end
</pre>

=='''Deletion of "student-selected" reviewing'''==
The following files had code for “student-selected” reviewing –

* dynamic_quiz_assignment_helper.rb
* dynamic_review_assignment_helper.rb
* review_mapping_controller.rb

In student-selected reviewing, a student was allowed to review a particular submission and not just a particular topic. However, the reviewer could have got his own submission if it had been the one with least reviews. This was an undesirable aspect of student-selected reviewing.
The functionality for “student-selected” reviewing was never implemented successfully. Hence, the methods corresponding to the aforementioned functionality were removed from respective files.

Changes were made at the following places - 
* dynamic_quiz_assignment_helper.rb
<pre>
# TODO: Remove this helper, this code is not well-designed.
# Look at Assignment.contributor_to_review() as an example of a better approach
module DynamicQuizAssignmentHelper

# * The article was not written by the potential reviewer.
# * The article was not already reviewed by the potential reviewer.
# * The article is not on the same topic as the potential reviewer has previously written about.
# * The article does not already have the maximum number of potential reviews in progress.
# * The article has the minimum number of reviews for that assignment.

def self.quiz_assignment(assignment_id, reviewer_id, questionnaire_id, quiz_type )
@assignment_id = assignment_id
@current_assignment = Assignment.find(assignment_id)
@reviewer_id = reviewer_id
@questionnaire_id = questionnaire_id

if (quiz_type == Assignment::RS_STUDENT_SELECTED)
@questionnaires = Array.new
@questionnaires << Questionnaire.find(@questionnaire_id)#student_selected_quiz_assignment( )
return @questionnaires
else
return nil
end
end
</pre>

* dynamic_review_assignment_helper.rb
<pre>
# TODO: Remove this helper, this code is not well-designed.
# Look at Assignment.contributor_to_review() as an example of a better approach
module DynamicReviewAssignmentHelper

# * The article was not written by the potential reviewer.
# * The article was not already reviewed by the potential reviewer.
# * The article is not on the same topic as the potential reviewer has previously written about.
# * The article does not already have the maximum number of potential reviews in progress.
# * The article has the minimum number of reviews for that assignment.

def self.review_assignment(assignment_id, reviewer_id, topic_id, review_type )
@assignment_id = assignment_id
@current_assignment = Assignment.find(assignment_id)
@reviewer_id = reviewer_id
@topic_id = topic_id

if (review_type == Assignment::RS_STUDENT_SELECTED)
return student_selected_review_assignment( )
else
return nil
end
end
</pre>

* review_mapping_controller.rb
<pre>
# Get all the available submissions
def show_available_submissions
assignment = Assignment.find(params[:assignment_id])
reviewer = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
requested_topic_id = params[:topic_id]
@available_submissions = Hash.new
@available_submissions = DynamicReviewAssignmentHelper::review_assignment(assignment.id, reviewer.id, requested_topic_id, Assignment::RS_STUDENT_SELECTED)
end
</pre>

=='''References'''==
<references/>

CSC/ECE 517 Fall 2015/oss E1552 NRR

2015-11-01T00:55:56Z

Rahuja:

'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb'''
=='''Overview'''==
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure
<ref>Refactoring: Improving the Design of Existing Code -
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Robert
[https://books.google.com/books/about/Refactoring.html?id=HmrDHwgkbPsC&printsec=frontcover&source=kp_read_button#v=onepage&q&f=false]</ref>. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
There are many benefits of refactoring as follows:
<ref>Refactoring Software using Design Patterns - by Masatomo Noborikawa
[http://www.cs.uni.edu/~wallingf/miscellaneous/student-papers/noborikawa-paper.pdf]</ref>

* Refactoring improves the design of software. Refactoring often cleans up codes by deleting duplicates, divides a big chunk of codes into several methods, and makes the program more understandable.
* Because refactoring makes a design cleaner, it helps the programmers understand codes better and see things that may have not been seen before.
* Refactoring helps spot bugs since it makes the software more comprehensible.
* Refactoring turns an adverse design into a good design, which allows for rapid software development.

__TOC__

=='''Peer Reviewing'''==
It is the process of evaluating work done by an individual or a team by another team or an individual with expertise in the concerned area.
Types of Reviewing Strategies in Expertiza -

* Instructor Selected Reviewing - Using this strategy the instructor assigns reviews to all participants of the assignment. After selecting this strategy the instructor has the following two options -
** Set number of reviews done by each student.
** Set minimum number of reviews done for each submission.
Then the instructor can click on assign reviewers and map the students to the topics which should be reviewed by them.

[[File:editing_assignment.png‎ |frame|center|Instructor selected Reviewing]]

* Auto Selected Reviewing - If the instructor selects this strategy, students need to select reviews themselves. Either the student is given a list of topics to choose from and he selects which topic he wants to review, or he checks “I don’t care which topic I review” and he/she will be randomly assigned a topic to review. The instructor can also specify two parameters after selecting this strategy -
** Review topic threshold: - Let us assume Topic 1 has a submission than has not been reviewed. Topic 2 has submissions that has been reviewed atleast 2 times and k is set 2. Then the student will not be able to select topic 2 until all of topic 1’s submission has been reviewed atleast 2 times.
** Maximum number of reviews per submission: - This specifies the maximum number of times a particular top can be reviewed.

[[File:editing_assignment_2.png‎ |frame|center|Auto selected Reviewing]]

* Student Selected Reviewing -
In this strategy the student selects a particular submission to review instead of a particular topic. This feature had never been used and did not work correctly. Hence it has been removed from the system. However there are a lot of places where the code for student selected reviewing exists however it not being called anywhere.

=='''Project Resources'''==
* [https://github.com/rahuja910/expertiza GitHub Repository]
* [https://github.com/expertiza/expertiza/pull/602 GitHub Pull Request Link]
* [http://152.46.20.183:3000/ VCL Deployment Link] (For Instructor - username: instructor6, password: password. For student - username: student5700, password: password)

=='''Problem Statement'''==
==='''Classes involved'''===
dynamic_quiz_assignment_helper.rb
dynamic_review_assignment_helper.rb
review_mapping_controller.rb

==='''What it does''' ===
dynamic_review_assignment_helper.rb allows the system choose a team to review when a student chooses a topic to review. It helps the code choose topics that have submissions with fewer reviews than other topics. A threshold k is used to decide whether a particular topic can be chosen. If, e.g., Topic 1 has a submission that has not yet been reviewed, and Topic 2 has no submission that has been reviewed by fewer than 3 reviewers, then the incoming reviewer can only choose Topic 2 if k ≥ 3. This class does not actually decide what is reviewable, but it does make up a sorted list of the submissions by the number of the reviews they have. dynamic_quiz_assignment_helper.rb is similar, but for quizzes.

==='''What needs to be done'''===
* The find_submissions_in_current_cycle method returns a list of participants. It should return a list of teams. Returning a list of participants leads to redundant entries in the hash, if they are done by multi-member teams. There used to be a need for dealing with participants rather than teams, but in the current Expertiza, submissions always belong to teams rather than individuals. (This may also require changing the call site for some calls to methods of this class.)
* The comment at the beginning of the class lists a number of criteria that have to hold for a submission to be reviewable (e.g., it was not written by the potential reviewer, it has not already been reviewed by the potential reviewer). It’s not clear where these conditions are checked for. Probably the different conditions are checked for in different places. Sometimes they are checked for late (e.g., if a user has written on Topic 2, (s)he is allowed to select Topic 2 as a topic to review, but after (s)he selects it, (s)he is told that there are no more submissions to review on that topic). It would be better to check for all of these conditions in dynamic_review_assignment_helper; then the user would not even be able to select topics that have no available reviews.
* There is code for “student-selected” reviewing. This would have allowed a student to choose a particular submission, not just a particular topic. This feature had never been used, and did not work correctly, so we removed it from the system. Thus, the code for student-selected reviewing should be removed.
* The two classes have a lot of duplicated code. Remove all DRY problems.

=='''Modification of find_submissions_in_current_cycle method'''==

This function returns a list of participants for the particular assignment. This leads to redundant entries in the hash since most teams are made up of more than one member. Earlier the submissions belonged to participants rather than teams, however currently there is no need for this since if an instructor wants individual assignments he/she simply select maximum number of size of a team as one. Correspondingly changes need to be made to the call sites.

* Before Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentParticipant.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
users = TeamsUser.where(team_id: signUp.team_id)
users.each do |user|
participant = Participant.where(user_id: user_id, parent_id: @assignment_id)
if participant
submissions_in_current_cycle << participant
end
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

* After Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentTeam.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
team=Team.where(team_id: signUp.team_id)
if team
submissions_in_current_cycle << team
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

As seen from the above code we have replaced AssignmentParticipant with AssignmentTeam. Now submissions_in_current_cycle will contain list of participants rather than a list of teams. Also note the model for AssignmentTeam contains the same methods which are present in the model for AssignmentParticipant. In the same helper class we had to modify code to handle the aspect that submissions_in_current_cycle now contains teams rather than participants. Hence we made changes in build_submissions_availability().

=='''Implementation of Criteria'''==
'''Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes.''' 
The helper classes while returning a list of teams should check the below set of conditions. Each of the below conditions need to be checked at one place to ensure better code readability and maintainability.

* The article was not written by the potential reviewer.
The potential reviewer should not be able to review its own submission and hence a check for this condition is required. However, it was already implemented in the code beforehand.

* The article was not already reviewed by the potential reviewer.
The potential reviewer should not be able to review a topic which is already reviewed by him/her. The same was also implemented along with the above condition.

* The article is not on the same topic as the potential reviewer has previously written about.
The reviewer should not be able to review on the same topic that he/she submitted as the reviewer could give biased reviews to make his/her own submission seem better. This was not implemented previously and was implemented in the code changes by checking the topic id.

'''Implementation :''' 
<pre>
def self.build_submissions_availability()
least_review_count = -1;
max_no_reviews = 5
reviewer_teams=TeamsUser.where(user_id: @reviewer_id)

@submissions_availability = Hash.new
unless @submissions_in_current_cycle.nil?
@submissions_in_current_cycle.each { |submission|
team_check=false
if( least_review_count == -1)
least_review_count = submission[1]
end
reviewer_teams.each do |reviewer_team|
if submission[0] == reviewer_team.team_id
team_check=true
end
end

if !team_check
@submissions_availability[submission[0]] = get_state(least_review_count,submission[1],max_no_reviews)
end
}
end
return @submissions_availability
end
</pre>

* The article does not already have the maximum number of potential reviews in progress.
The reviewer should only be able to review topics that have not reached the maximum number of reviews. The check for the same is done in get_state method where the current_review_count is compared with max_review_count and make it unavailable.

* The article has the minimum number of reviews for that assignment.
The article is made available if it has the minimum number of reviews for the assignment and the same is checked in get_state method where the current_review_count is compared with least_review_count and make it available.

'''Implementation:''' 
<pre>
def self.get_state(least_review_count,current_review_count,max_review_count)
if(current_review_count != -1 && current_review_count == max_review_count)
return -1
elsif(current_review_count != -1 && current_review_count > least_review_count)
return 1
elsif(current_review_count != -1 && current_review_count == least_review_count)
return 0
end
end
</pre>

=='''Deletion of "student-selected" reviewing'''==
The following files had code for “student-selected” reviewing –

* dynamic_quiz_assignment_helper.rb
* dynamic_review_assignment_helper.rb
* review_mapping_controller.rb

In student-selected reviewing, a student was allowed to review a particular submission and not just a particular topic. However, the reviewer could have got his own submission if it had been the one with least reviews. This was an undesirable aspect of student-selected reviewing.
The functionality for “student-selected” reviewing was never implemented successfully. Hence, the methods corresponding to the aforementioned functionality were removed from respective files.

Changes were made at the following places - 
* dynamic_quiz_assignment_helper.rb
<pre>
# TODO: Remove this helper, this code is not well-designed.
# Look at Assignment.contributor_to_review() as an example of a better approach
module DynamicQuizAssignmentHelper

# * The article was not written by the potential reviewer.
# * The article was not already reviewed by the potential reviewer.
# * The article is not on the same topic as the potential reviewer has previously written about.
# * The article does not already have the maximum number of potential reviews in progress.
# * The article has the minimum number of reviews for that assignment.

def self.quiz_assignment(assignment_id, reviewer_id, questionnaire_id, quiz_type )
@assignment_id = assignment_id
@current_assignment = Assignment.find(assignment_id)
@reviewer_id = reviewer_id
@questionnaire_id = questionnaire_id

if (quiz_type == Assignment::RS_STUDENT_SELECTED)
@questionnaires = Array.new
@questionnaires << Questionnaire.find(@questionnaire_id)#student_selected_quiz_assignment( )
return @questionnaires
else
return nil
end
end
</pre>

* dynamic_review_assignment_helper.rb
<pre>
# TODO: Remove this helper, this code is not well-designed.
# Look at Assignment.contributor_to_review() as an example of a better approach
module DynamicReviewAssignmentHelper

# * The article was not written by the potential reviewer.
# * The article was not already reviewed by the potential reviewer.
# * The article is not on the same topic as the potential reviewer has previously written about.
# * The article does not already have the maximum number of potential reviews in progress.
# * The article has the minimum number of reviews for that assignment.

def self.review_assignment(assignment_id, reviewer_id, topic_id, review_type )
@assignment_id = assignment_id
@current_assignment = Assignment.find(assignment_id)
@reviewer_id = reviewer_id
@topic_id = topic_id

if (review_type == Assignment::RS_STUDENT_SELECTED)
return student_selected_review_assignment( )
else
return nil
end
end
</pre>

* review_mapping_controller.rb
<pre>
# Get all the available submissions
def show_available_submissions
assignment = Assignment.find(params[:assignment_id])
reviewer = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
requested_topic_id = params[:topic_id]
@available_submissions = Hash.new
@available_submissions = DynamicReviewAssignmentHelper::review_assignment(assignment.id, reviewer.id, requested_topic_id, Assignment::RS_STUDENT_SELECTED)
end
</pre>

=='''References'''==
<references/>

CSC/ECE 517 Fall 2015/oss E1552 NRR

2015-11-01T00:22:05Z

Rahuja:

'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb'''
=='''Overview'''==
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure
<ref>Refactoring: Improving the Design of Existing Code -
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Robert
[https://books.google.com/books/about/Refactoring.html?id=HmrDHwgkbPsC&printsec=frontcover&source=kp_read_button#v=onepage&q&f=false]</ref>. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
There are many benefits of refactoring as follows:
<ref>Refactoring Software using Design Patterns - by Masatomo Noborikawa
[http://www.cs.uni.edu/~wallingf/miscellaneous/student-papers/noborikawa-paper.pdf]</ref>

* Refactoring improves the design of software. Refactoring often cleans up codes by deleting duplicates, divides a big chunk of codes into several methods, and makes the program more understandable.
* Because refactoring makes a design cleaner, it helps the programmers understand codes better and see things that may have not been seen before.
* Refactoring helps spot bugs since it makes the software more comprehensible.
* Refactoring turns an adverse design into a good design, which allows for rapid software development.

__TOC__

=='''Peer Reviewing'''==
It is the process of evaluating work done by an individual or a team by another team or an individual with expertise in the concerned area.
Types of Reviewing Strategies in Expertiza -

* Instructor Selected Reviewing - Using this strategy the instructor assigns reviews to all participants of the assignment. After selecting this strategy the instructor has the following two options -
** Set number of reviews done by each student.
** Set minimum number of reviews done for each submission.
Then the instructor can click on assign reviewers and map the students to the topics which should be reviewed by them.

[[File:editing_assignment.png‎ |frame|center|Instructor selected Reviewing]]

* Auto Selected Reviewing - If the instructor selects this strategy, students need to select reviews themselves. Either the student is given a list of topics to choose from and he selects which topic he wants to review, or he checks “I don’t care which topic I review” and he/she will be randomly assigned a topic to review. The instructor can also specify two parameters after selecting this strategy -
** Review topic threshold: - Let us assume Topic 1 has a submission than has not been reviewed. Topic 2 has submissions that has been reviewed atleast 2 times and k is set 2. Then the student will not be able to select topic 2 until all of topic 1’s submission has been reviewed atleast 2 times.
** Maximum number of reviews per submission: - This specifies the maximum number of times a particular top can be reviewed.

[[File:editing_assignment_2.png‎ |frame|center|Auto selected Reviewing]]

* Student Selected Reviewing -
In this strategy the student selects a particular submission to review instead of a particular topic. This feature had never been used and did not work correctly. Hence it has been removed from the system. However there are a lot of places where the code for student selected reviewing exists however it not being called anywhere.

=='''Project Resources'''==
* [https://github.com/rahuja910/expertiza GitHub Repository]
* [https://github.com/expertiza/expertiza/pull/602 GitHub Pull Request Link]
* [http://152.46.20.183:3000/ VCL Deployment Link] (For Instructor - username: instructor6, password: password. For student - username: student5700, password: password)

=='''Problem Statement'''==
==='''Classes involved'''===
dynamic_quiz_assignment_helper.rb
dynamic_review_assignment_helper.rb
review_mapping_controller.rb

==='''What it does''' ===
dynamic_review_assignment_helper.rb allows the system choose a team to review when a student chooses a topic to review. It helps the code choose topics that have submissions with fewer reviews than other topics. A threshold k is used to decide whether a particular topic can be chosen. If, e.g., Topic 1 has a submission that has not yet been reviewed, and Topic 2 has no submission that has been reviewed by fewer than 3 reviewers, then the incoming reviewer can only choose Topic 2 if k ≥ 3. This class does not actually decide what is reviewable, but it does make up a sorted list of the submissions by the number of the reviews they have. dynamic_quiz_assignment_helper.rb is similar, but for quizzes.

==='''What needs to be done'''===
* The find_submissions_in_current_cycle method returns a list of participants. It should return a list of teams. Returning a list of participants leads to redundant entries in the hash, if they are done by multi-member teams. There used to be a need for dealing with participants rather than teams, but in the current Expertiza, submissions always belong to teams rather than individuals. (This may also require changing the call site for some calls to methods of this class.)
* The comment at the beginning of the class lists a number of criteria that have to hold for a submission to be reviewable (e.g., it was not written by the potential reviewer, it has not already been reviewed by the potential reviewer). It’s not clear where these conditions are checked for. Probably the different conditions are checked for in different places. Sometimes they are checked for late (e.g., if a user has written on Topic 2, (s)he is allowed to select Topic 2 as a topic to review, but after (s)he selects it, (s)he is told that there are no more submissions to review on that topic). It would be better to check for all of these conditions in dynamic_review_assignment_helper; then the user would not even be able to select topics that have no available reviews.
* There is code for “student-selected” reviewing. This would have allowed a student to choose a particular submission, not just a particular topic. This feature had never been used, and did not work correctly, so we removed it from the system. Thus, the code for student-selected reviewing should be removed.
* The two classes have a lot of duplicated code. Remove all DRY problems.

=='''Modification of find_submissions_in_current_cycle method'''==

This function returns a list of participants for the particular assignment. This leads to redundant entries in the hash since most teams are made up of more than one member. Earlier the submissions belonged to Participants rather than teams, however currently there is no need for this since if want an individual project we simply select maximum number of size of a team as one. Correspondingly changes need to be made to the call sites.

* Before Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentParticipant.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
users = TeamsUser.where(team_id: signUp.team_id)
users.each do |user|
participant = Participant.where(user_id: user_id, parent_id: @assignment_id)
if participant
submissions_in_current_cycle << participant
end
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

* After Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentTeam.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
team=Team.where(team_id: signUp.team_id)
if team
submissions_in_current_cycle << team
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

As seen from the above code we have replaced AssignmentParticipant with AssignmentTeam. Now submissions_in_current_cycle will contain list of participants rather than a list of teams. Also note the model for AssignmentTeam contains the same methods which present in the model for AssignmentTeam. In the same helper class we had to modify code to handle the aspect that submissions_in_current_cycle now contains teams rather than participants. Hence we made changes in build_submissions_availability().

=='''Implementation of Criteria'''==
'''Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes.''' 
The helper classes while returning a list of teams should check the below set of conditions. Each of the below conditions need to be checked at one place to ensure better code readability and maintainability.

* The article was not written by the potential reviewer.
The potential reviewer should not be able to review its own submission and hence a check for this condition is required. However, it was already implemented in the code beforehand.

* The article was not already reviewed by the potential reviewer.
The potential reviewer should not be able to review a topic which is already reviewed by him/her. The same was also implemented along with the above condition.

* The article is not on the same topic as the potential reviewer has previously written about.
The reviewer should not be able to review on the same topic that he/she submitted as the reviewer could give biased reviews to make his/her own submission seem better. This was not implemented previously and was implemented in the code changes by checking the topic id.

'''Implementation :''' 
<pre>
def self.build_submissions_availability()
least_review_count = -1;
max_no_reviews = 5
reviewer_teams=TeamsUser.where(user_id: @reviewer_id)

@submissions_availability = Hash.new
unless @submissions_in_current_cycle.nil?
@submissions_in_current_cycle.each { |submission|
team_check=false
if( least_review_count == -1)
least_review_count = submission[1]
end
reviewer_teams.each do |reviewer_team|
if submission[0] == reviewer_team.team_id
team_check=true
end
end

if !team_check
@submissions_availability[submission[0]] = get_state(least_review_count,submission[1],max_no_reviews)
end
}
end
return @submissions_availability
end
</pre>

* The article does not already have the maximum number of potential reviews in progress.
The reviewer should only be able to review topics that have not reached the maximum number of reviews. The check for the same is done in get_state method where the current_review_count is compared with max_review_count and make it unavailable.

* The article has the minimum number of reviews for that assignment.
The article is made available if it has the minimum number of reviews for the assignment and the same is checked in get_state method where the current_review_count is compared with least_review_count and make it available.

'''Implementation:''' 
<pre>
def self.get_state(least_review_count,current_review_count,max_review_count)
if(current_review_count != -1 && current_review_count == max_review_count)
return -1
elsif(current_review_count != -1 && current_review_count > least_review_count)
return 1
elsif(current_review_count != -1 && current_review_count == least_review_count)
return 0
end
end
</pre>

=='''Deletion of "student-selected" reviewing'''==
The following files had code for “student-selected” reviewing –

* dynamic_quiz_assignment_helper.rb
* dynamic_review_assignment_helper.rb
* review_mapping_controller.rb

In student-selected reviewing, a student was allowed to review a particular submission and not just a particular topic. However, the reviewer could have got his own submission if it had been the one with least reviews. This was an undesirable aspect of student-selected reviewing.
The functionality for “student-selected” reviewing was never implemented successfully. Hence, the methods corresponding to the aforementioned functionality were removed from respective files.

Changes were made at the following places - 
* dynamic_quiz_assignment_helper.rb
<pre>
# TODO: Remove this helper, this code is not well-designed.
# Look at Assignment.contributor_to_review() as an example of a better approach
module DynamicQuizAssignmentHelper

# * The article was not written by the potential reviewer.
# * The article was not already reviewed by the potential reviewer.
# * The article is not on the same topic as the potential reviewer has previously written about.
# * The article does not already have the maximum number of potential reviews in progress.
# * The article has the minimum number of reviews for that assignment.

def self.quiz_assignment(assignment_id, reviewer_id, questionnaire_id, quiz_type )
@assignment_id = assignment_id
@current_assignment = Assignment.find(assignment_id)
@reviewer_id = reviewer_id
@questionnaire_id = questionnaire_id

if (quiz_type == Assignment::RS_STUDENT_SELECTED)
@questionnaires = Array.new
@questionnaires << Questionnaire.find(@questionnaire_id)#student_selected_quiz_assignment( )
return @questionnaires
else
return nil
end
end
</pre>

* dynamic_review_assignment_helper.rb
<pre>
# TODO: Remove this helper, this code is not well-designed.
# Look at Assignment.contributor_to_review() as an example of a better approach
module DynamicReviewAssignmentHelper

# * The article was not written by the potential reviewer.
# * The article was not already reviewed by the potential reviewer.
# * The article is not on the same topic as the potential reviewer has previously written about.
# * The article does not already have the maximum number of potential reviews in progress.
# * The article has the minimum number of reviews for that assignment.

def self.review_assignment(assignment_id, reviewer_id, topic_id, review_type )
@assignment_id = assignment_id
@current_assignment = Assignment.find(assignment_id)
@reviewer_id = reviewer_id
@topic_id = topic_id

if (review_type == Assignment::RS_STUDENT_SELECTED)
return student_selected_review_assignment( )
else
return nil
end
end
</pre>

* review_mapping_controller.rb
<pre>
# Get all the available submissions
def show_available_submissions
assignment = Assignment.find(params[:assignment_id])
reviewer = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
requested_topic_id = params[:topic_id]
@available_submissions = Hash.new
@available_submissions = DynamicReviewAssignmentHelper::review_assignment(assignment.id, reviewer.id, requested_topic_id, Assignment::RS_STUDENT_SELECTED)
end
</pre>

=='''References'''==
<references/>

CSC/ECE 517 Fall 2015/oss E1552 NRR

2015-11-01T00:18:01Z

Rahuja:

'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb'''
=='''Overview'''==
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure
<ref>Refactoring: Improving the Design of Existing Code -
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Robert
[https://books.google.com/books/about/Refactoring.html?id=HmrDHwgkbPsC&printsec=frontcover&source=kp_read_button#v=onepage&q&f=false]</ref>. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
There are many benefits of refactoring as follows:
<ref>Refactoring Software using Design Patterns - by Masatomo Noborikawa
[http://www.cs.uni.edu/~wallingf/miscellaneous/student-papers/noborikawa-paper.pdf]</ref>

* Refactoring improves the design of software. Refactoring often cleans up codes by deleting duplicates, divides a big chunk of codes into several methods, and makes the program more understandable.
* Because refactoring makes a design cleaner, it helps the programmers understand codes better and see things that may have not been seen before.
* Refactoring helps spot bugs since it makes the software more comprehensible.
* Refactoring turns an adverse design into a good design, which allows for rapid software development.

__TOC__

=='''Peer Reviewing'''==
It is the process of evaluating work done by an individual or a team by another team or an individual with expertise in the concerned area.
Types of Reviewing Strategies in Expertiza -

* Instructor Selected Reviewing - Using this strategy the instructor assigns reviews to all participants of the assignment. After selecting this strategy the instructor has the following two options -
** Set number of reviews done by each student.
** Set minimum number of reviews done for each submission.
Then the instructor can click on assign reviewers and map the students to the topics which should be reviewed by them.

[[File:editing_assignment.png‎ |frame|center|Instructor selected Reviewing]]

* Auto Selected Reviewing - If the instructor selects this strategy, students need to select reviews themselves. Either the student is given a list of topics to choose from and he selects which topic he wants to review, or he checks “I don’t care which topic I review” and he/she will be randomly assigned a topic to review. The instructor can also specify two parameters after selecting this strategy -
** Review topic threshold: - Let us assume Topic 1 has a submission than has not been reviewed. Topic 2 has submissions that has been reviewed atleast 2 times and k is set 2. Then the student will not be able to select topic 2 until all of topic 1’s submission has been reviewed atleast 2 times.
** Maximum number of reviews per submission: - This specifies the maximum number of times a particular top can be reviewed.

[[File:editing_assignment_2.png‎ |frame|center|Auto selected Reviewing]]

* Student Selected Reviewing -
In this strategy the student selects a particular submission to review instead of a particular topic. This feature had never been used and did not work correctly. Hence it has been removed from the system. However there are a lot of places where the code for student selected reviewing exists however it not being called anywhere.

=='''Project Resources'''==
* [https://github.com/rahuja910/expertiza GitHub Repository]
* [https://github.com/expertiza/expertiza/pull/602 GitHub Pull Request Link]
* [http://152.46.20.183:3000/ VCL Deployment Link] (For Instructor - username: instructor6, password: password. For student - username: student5700, password: password)

=='''Problem Statement'''==
==='''Classes involved'''===
dynamic_quiz_assignment_helper.rb
dynamic_review_assignment_helper.rb
review_mapping_controller.rb

==='''What it does''' ===
dynamic_review_assignment_helper.rb allows the system choose a team to review when a student chooses a topic to review. It helps the code choose topics that have submissions with fewer reviews than other topics. A threshold k is used to decide whether a particular topic can be chosen. If, e.g., Topic 1 has a submission that has not yet been reviewed, and Topic 2 has no submission that has been reviewed by fewer than 3 reviewers, then the incoming reviewer can only choose Topic 2 if k ≥ 3. This class does not actually decide what is reviewable, but it does make up a sorted list of the submissions by the number of the reviews they have. dynamic_quiz_assignment_helper.rb is similar, but for quizzes.

==='''What needs to be done'''===
* The find_submissions_in_current_cycle method returns a list of participants. It should return a list of teams. Returning a list of participants leads to redundant entries in the hash, if any are done by multi-member teams. There used to be a need for dealing with participants rather than teams, but in the current Expertiza, submissions always belong to teams rather than individuals. (This may also require changing the call site for some calls to methods of this class.)
* The comment at the beginning of the class lists a number of criteria that have to hold for a submission to be reviewable (e.g., it was not written by the potential reviewer, it has not already been reviewed by the potential reviewer). It’s not clear where these conditions are checked for. Probably the different conditions are checked for in different places. Sometimes they are checked for late (e.g., if a user has written on Topic 2, (s)he is allowed to select Topic 2 as a topic to review, but after (s)he selects it, (s)he is told that there are no more submissions to review on that topic). It would be better to check for all of these conditions in dynamic_review_assignment_helper; then the user would not even be able to select topics that have no available reviews.
* There is code for “student-selected” reviewing. This would have allowed a student to choose a particular submission, not just a particular topic. This feature had never been used, and did not work correctly, so we removed it from the system. Thus, the code for student-selected reviewing should be removed.
* The two classes have a lot of duplicated code. Remove all DRY problems.

=='''Modification of find_submissions_in_current_cycle method'''==

This function returns a list of participants for the particular assignment. This leads to redundant entries in the hash since most teams are made up of more than one member. Earlier the submissions belonged to Participants rather than teams, however currently there is no need for this since if want an individual project we simply select maximum number of size of a team as one. Correspondingly changes need to be made to the call sites.

* Before Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentParticipant.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
users = TeamsUser.where(team_id: signUp.team_id)
users.each do |user|
participant = Participant.where(user_id: user_id, parent_id: @assignment_id)
if participant
submissions_in_current_cycle << participant
end
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

* After Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentTeam.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
team=Team.where(team_id: signUp.team_id)
if team
submissions_in_current_cycle << team
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

As seen from the above code we have replaced AssignmentParticipant with AssignmentTeam. Now submissions_in_current_cycle will contain list of participants rather than a list of teams. Also note the model for AssignmentTeam contains the same methods which present in the model for AssignmentTeam. In the same helper class we had to modify code to handle the aspect that submissions_in_current_cycle now contains teams rather than participants. Hence we made changes in build_submissions_availability().

=='''Implementation of Criteria'''==
'''Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes.''' 
The helper classes while returning a list of teams should check the below set of conditions. Each of the below conditions need to be checked at one place to ensure better code readability and maintainability.

* The article was not written by the potential reviewer.
The potential reviewer should not be able to review its own submission and hence a check for this condition is required. However, it was already implemented in the code beforehand.

* The article was not already reviewed by the potential reviewer.
The potential reviewer should not be able to review a topic which is already reviewed by him/her. The same was also implemented along with the above condition.

* The article is not on the same topic as the potential reviewer has previously written about.
The reviewer should not be able to review on the same topic that he/she submitted as the reviewer could give biased reviews to make his/her own submission seem better. This was not implemented previously and was implemented in the code changes by checking the topic id.

'''Implementation :''' 
<pre>
def self.build_submissions_availability()
least_review_count = -1;
max_no_reviews = 5
reviewer_teams=TeamsUser.where(user_id: @reviewer_id)

@submissions_availability = Hash.new
unless @submissions_in_current_cycle.nil?
@submissions_in_current_cycle.each { |submission|
team_check=false
if( least_review_count == -1)
least_review_count = submission[1]
end
reviewer_teams.each do |reviewer_team|
if submission[0] == reviewer_team.team_id
team_check=true
end
end

if !team_check
@submissions_availability[submission[0]] = get_state(least_review_count,submission[1],max_no_reviews)
end
}
end
return @submissions_availability
end
</pre>

* The article does not already have the maximum number of potential reviews in progress.
The reviewer should only be able to review topics that have not reached the maximum number of reviews. The check for the same is done in get_state method where the current_review_count is compared with max_review_count and make it unavailable.

* The article has the minimum number of reviews for that assignment.
The article is made available if it has the minimum number of reviews for the assignment and the same is checked in get_state method where the current_review_count is compared with least_review_count and make it available.

'''Implementation:''' 
<pre>
def self.get_state(least_review_count,current_review_count,max_review_count)
if(current_review_count != -1 && current_review_count == max_review_count)
return -1
elsif(current_review_count != -1 && current_review_count > least_review_count)
return 1
elsif(current_review_count != -1 && current_review_count == least_review_count)
return 0
end
end
</pre>

=='''Deletion of "student-selected" reviewing'''==
The following files had code for “student-selected” reviewing –

* dynamic_quiz_assignment_helper.rb
* dynamic_review_assignment_helper.rb
* review_mapping_controller.rb

In student-selected reviewing, a student was allowed to review a particular submission and not just a particular topic. However, the reviewer could have got his own submission if it had been the one with least reviews. This was an undesirable aspect of student-selected reviewing.
The functionality for “student-selected” reviewing was never implemented successfully. Hence, the methods corresponding to the aforementioned functionality were removed from respective files.

Changes were made at the following places - 
* dynamic_quiz_assignment_helper.rb
<pre>
# TODO: Remove this helper, this code is not well-designed.
# Look at Assignment.contributor_to_review() as an example of a better approach
module DynamicQuizAssignmentHelper

# * The article was not written by the potential reviewer.
# * The article was not already reviewed by the potential reviewer.
# * The article is not on the same topic as the potential reviewer has previously written about.
# * The article does not already have the maximum number of potential reviews in progress.
# * The article has the minimum number of reviews for that assignment.

def self.quiz_assignment(assignment_id, reviewer_id, questionnaire_id, quiz_type )
@assignment_id = assignment_id
@current_assignment = Assignment.find(assignment_id)
@reviewer_id = reviewer_id
@questionnaire_id = questionnaire_id

if (quiz_type == Assignment::RS_STUDENT_SELECTED)
@questionnaires = Array.new
@questionnaires << Questionnaire.find(@questionnaire_id)#student_selected_quiz_assignment( )
return @questionnaires
else
return nil
end
end
</pre>

* dynamic_review_assignment_helper.rb
<pre>
# TODO: Remove this helper, this code is not well-designed.
# Look at Assignment.contributor_to_review() as an example of a better approach
module DynamicReviewAssignmentHelper

# * The article was not written by the potential reviewer.
# * The article was not already reviewed by the potential reviewer.
# * The article is not on the same topic as the potential reviewer has previously written about.
# * The article does not already have the maximum number of potential reviews in progress.
# * The article has the minimum number of reviews for that assignment.

def self.review_assignment(assignment_id, reviewer_id, topic_id, review_type )
@assignment_id = assignment_id
@current_assignment = Assignment.find(assignment_id)
@reviewer_id = reviewer_id
@topic_id = topic_id

if (review_type == Assignment::RS_STUDENT_SELECTED)
return student_selected_review_assignment( )
else
return nil
end
end
</pre>

* review_mapping_controller.rb
<pre>
# Get all the available submissions
def show_available_submissions
assignment = Assignment.find(params[:assignment_id])
reviewer = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
requested_topic_id = params[:topic_id]
@available_submissions = Hash.new
@available_submissions = DynamicReviewAssignmentHelper::review_assignment(assignment.id, reviewer.id, requested_topic_id, Assignment::RS_STUDENT_SELECTED)
end
</pre>

=='''References'''==
<references/>

CSC/ECE 517 Fall 2015/oss E1552 NRR

2015-11-01T00:15:09Z

Rahuja:

'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb'''
=='''Overview'''==
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure
<ref>Refactoring: Improving the Design of Existing Code -
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Robert
[https://books.google.com/books/about/Refactoring.html?id=HmrDHwgkbPsC&printsec=frontcover&source=kp_read_button#v=onepage&q&f=false]</ref>. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
There are many benefits of refactoring as follows:
<ref>Refactoring Software using Design Patterns - by Masatomo Noborikawa
[http://www.cs.uni.edu/~wallingf/miscellaneous/student-papers/noborikawa-paper.pdf]</ref>

* Refactoring improves the design of software. Refactoring often cleans up codes by deleting duplicates, divides a big chunk of codes into several methods, and makes the program more understandable.
* Because refactoring makes a design cleaner, it helps the programmers understand codes better and see things that may have not been seen before.
* Refactoring helps spot bugs since it makes the software more comprehensible.
* Refactoring turns an adverse design into a good design, which allows for rapid software development.

__TOC__

=='''Peer Reviewing'''==
It is the process of evaluating work done by an individual or a team by another team or an individual with expertise in the concerned area.
Types of Reviewing Strategies in Expertiza -

* Instructor Selected Reviewing - Using this strategy the instructor assigns reviews to all participants of the assignment. After selecting this strategy the instructor has the following two options -
** Set number of reviews done by each student.
** Set minimum number of reviews done for each submission.
Then the instructor can click on assign reviewers and map the students to the topics which should be reviewed by them.

[[File:editing_assignment.png‎ |frame|center|Instructor selected Reviewing]]

* Auto Selected Reviewing - If the instructor selects this strategy, students need to select reviews themselves. Either the student is given a list of topics to choose from and he selects which topic he wants to review, or he checks “I don’t care which topic I review” and he/she will be randomly assigned a topic to review. The instructor can also specify two parameters after selecting this strategy -
** Review topic threshold: - Let us assume Topic 1 has a submission than has not been reviewed. Topic 2 has submissions that has been reviewed atleast 2 times and k is set 2. Then the student will not be able to select topic 2 until all of topic 1’s submission has been reviewed atleast 2 times.
** Maximum number of reviews per submission: - This specifies the maximum number of times a particular top can be reviewed.

[[File:editing_assignment_2.png‎ |frame|center|Auto selected Reviewing]]

* Student Selected Reviewing -
In this strategy the student selects a particular submission to review instead of a particular topic. This feature had never been used and did not work correctly. Hence it has been removed from the system. However there are a lot of places where the code for student selected reviewing exists however it not being called anywhere.

=='''Project Resources'''==
* [https://github.com/rahuja910/expertiza GitHub Repository]
* [https://github.com/expertiza/expertiza/pull/602 GitHub Pull Request Link]
* [http://152.46.20.183:3000/ VCL Deployment Link] (For Instructor - username: instructor6, password: password. For student - username: student5700, password: password)

=='''Problem Statement'''==
==='''Classes involved'''===
dynamic_quiz_assignment_helper.rb
dynamic_review_assignment_helper.rb
review_mapping_controller.rb

==='''What it does''' ===
dynamic_review_assignment_helper.rb allows the system choose a team to review when a student chooses a topic to review. It helps the code choose topics that have submissions with fewer reviews than other topics. A threshold k is used to decide whether a particular topic can be chosen. If, e.g., Topic 1 has a submission that has not yet been reviewed, and Topic 2 has no submission that has been reviewed by fewer than 3 reviewers, then the incoming reviewer can only choose Topic 2 if the k ≥ 3. This class does not actually decide what is reviewable, but it does make up a sorted list of the submissions by the number of the reviews they have. dynamic_quiz_assignment_helper.rb is similar, but for quizzes.

==='''What needs to be done'''===
* The find_submissions_in_current_cycle method returns a list of participants. It should return a list of teams. Returning a list of participants leads to redundant entries in the hash, if any are done by multi-member teams. There used to be a need for dealing with participants rather than teams, but in the current Expertiza, submissions always belong to teams rather than individuals. (This may also require changing the call site for some calls to methods of this class.)
* The comment at the beginning of the class lists a number of criteria that have to hold for a submission to be reviewable (e.g., it was not written by the potential reviewer, it has not already been reviewed by the potential reviewer). It’s not clear where these conditions are checked for. Probably the different conditions are checked for in different places. Sometimes they are checked for late (e.g., if a user has written on Topic 2, (s)he is allowed to select Topic 2 as a topic to review, but after (s)he selects it, (s)he is told that there are no more submissions to review on that topic). It would be better to check for all of these conditions in dynamic_review_assignment_helper; then the user would not even be able to select topics that have no available reviews.
* There is code for “student-selected” reviewing. This would have allowed a student to choose a particular submission, not just a particular topic. This feature had never been used, and did not work correctly, so we removed it from the system. Thus, the code for student-selected reviewing should be removed.
* The two classes have a lot of duplicated code. Remove all DRY problems.

=='''Modification of find_submissions_in_current_cycle method'''==

This function returns a list of participants for the particular assignment. This leads to redundant entries in the hash since most teams are made up of more than one member. Earlier the submissions belonged to Participants rather than teams, however currently there is no need for this since if want an individual project we simply select maximum number of size of a team as one. Correspondingly changes need to be made to the call sites.

* Before Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentParticipant.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
users = TeamsUser.where(team_id: signUp.team_id)
users.each do |user|
participant = Participant.where(user_id: user_id, parent_id: @assignment_id)
if participant
submissions_in_current_cycle << participant
end
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

* After Code Snippet -
<pre>
def self.find_submissions_in_current_cycle()

if @topic_id.blank?
submissions_in_current_cycle = AssignmentTeam.where(parent_id: @assignment_id)
else
#using topic_id to find participant.id(s).
signUps = SignedUpTeam.where(topic_id: @topic_id)
signUps.each do |signUp|
team=Team.where(team_id: signUp.team_id)
if team
submissions_in_current_cycle << team
end
end
end
submissions_in_current_cycle = submissions_in_current_cycle.reject { |submission| !submission.has_submissions? }

# Create a new Hash to store the number of reviews that have already been done (or are in progress) for
# each submission.
@submission_review_count = Hash.new
submissions_in_current_cycle.each do |submission|
# Each 'ResponseMap' entry indicates a review has been performed or is in progress.
existing_maps = ResponseMap.where(reviewee_id: submission.id, reviewed_object_id: @assignment_id )
if existing_maps.nil?
@submission_review_count[submission.id] = 0 # There are no reviews in progress (potential or completed).
else
@submission_review_count[submission.id] = existing_maps.size
end
end

# Sort and return the list of submissions by the number of reviews that they have.
sorted_review_count = @submission_review_count.sort {|a, b| a[1]<=>b[1]}
return sorted_review_count
end
</pre>

As seen from the above code we have replaced AssignmentParticipant with AssignmentTeam. Now submissions_in_current_cycle will contain list of participants rather than a list of teams. Also note the model for AssignmentTeam contains the same methods which present in the model for AssignmentTeam. In the same helper class we had to modify code to handle the aspect that submissions_in_current_cycle now contains teams rather than participants. Hence we made changes in build_submissions_availability().

=='''Implementation of Criteria'''==
'''Making sure all the conditions mentioned at the beginning of the class are implemented in both the helper classes.''' 
The helper classes while returning a list of teams should check the below set of conditions. Each of the below conditions need to be checked at one place to ensure better code readability and maintainability.

* The article was not written by the potential reviewer.
The potential reviewer should not be able to review its own submission and hence a check for this condition is required. However, it was already implemented in the code beforehand.

* The article was not already reviewed by the potential reviewer.
The potential reviewer should not be able to review a topic which is already reviewed by him/her. The same was also implemented along with the above condition.

* The article is not on the same topic as the potential reviewer has previously written about.
The reviewer should not be able to review on the same topic that he/she submitted as the reviewer could give biased reviews to make his/her own submission seem better. This was not implemented previously and was implemented in the code changes by checking the topic id.

'''Implementation :''' 
<pre>
def self.build_submissions_availability()
least_review_count = -1;
max_no_reviews = 5
reviewer_teams=TeamsUser.where(user_id: @reviewer_id)

@submissions_availability = Hash.new
unless @submissions_in_current_cycle.nil?
@submissions_in_current_cycle.each { |submission|
team_check=false
if( least_review_count == -1)
least_review_count = submission[1]
end
reviewer_teams.each do |reviewer_team|
if submission[0] == reviewer_team.team_id
team_check=true
end
end

if !team_check
@submissions_availability[submission[0]] = get_state(least_review_count,submission[1],max_no_reviews)
end
}
end
return @submissions_availability
end
</pre>

* The article does not already have the maximum number of potential reviews in progress.
The reviewer should only be able to review topics that have not reached the maximum number of reviews. The check for the same is done in get_state method where the current_review_count is compared with max_review_count and make it unavailable.

* The article has the minimum number of reviews for that assignment.
The article is made available if it has the minimum number of reviews for the assignment and the same is checked in get_state method where the current_review_count is compared with least_review_count and make it available.

'''Implementation:''' 
<pre>
def self.get_state(least_review_count,current_review_count,max_review_count)
if(current_review_count != -1 && current_review_count == max_review_count)
return -1
elsif(current_review_count != -1 && current_review_count > least_review_count)
return 1
elsif(current_review_count != -1 && current_review_count == least_review_count)
return 0
end
end
</pre>

=='''Deletion of "student-selected" reviewing'''==
The following files had code for “student-selected” reviewing –

* dynamic_quiz_assignment_helper.rb
* dynamic_review_assignment_helper.rb
* review_mapping_controller.rb

In student-selected reviewing, a student was allowed to review a particular submission and not just a particular topic. However, the reviewer could have got his own submission if it had been the one with least reviews. This was an undesirable aspect of student-selected reviewing.
The functionality for “student-selected” reviewing was never implemented successfully. Hence, the methods corresponding to the aforementioned functionality were removed from respective files.

Changes were made at the following places - 
* dynamic_quiz_assignment_helper.rb
<pre>
# TODO: Remove this helper, this code is not well-designed.
# Look at Assignment.contributor_to_review() as an example of a better approach
module DynamicQuizAssignmentHelper

# * The article was not written by the potential reviewer.
# * The article was not already reviewed by the potential reviewer.
# * The article is not on the same topic as the potential reviewer has previously written about.
# * The article does not already have the maximum number of potential reviews in progress.
# * The article has the minimum number of reviews for that assignment.

def self.quiz_assignment(assignment_id, reviewer_id, questionnaire_id, quiz_type )
@assignment_id = assignment_id
@current_assignment = Assignment.find(assignment_id)
@reviewer_id = reviewer_id
@questionnaire_id = questionnaire_id

if (quiz_type == Assignment::RS_STUDENT_SELECTED)
@questionnaires = Array.new
@questionnaires << Questionnaire.find(@questionnaire_id)#student_selected_quiz_assignment( )
return @questionnaires
else
return nil
end
end
</pre>

* dynamic_review_assignment_helper.rb
<pre>
# TODO: Remove this helper, this code is not well-designed.
# Look at Assignment.contributor_to_review() as an example of a better approach
module DynamicReviewAssignmentHelper

# * The article was not written by the potential reviewer.
# * The article was not already reviewed by the potential reviewer.
# * The article is not on the same topic as the potential reviewer has previously written about.
# * The article does not already have the maximum number of potential reviews in progress.
# * The article has the minimum number of reviews for that assignment.

def self.review_assignment(assignment_id, reviewer_id, topic_id, review_type )
@assignment_id = assignment_id
@current_assignment = Assignment.find(assignment_id)
@reviewer_id = reviewer_id
@topic_id = topic_id

if (review_type == Assignment::RS_STUDENT_SELECTED)
return student_selected_review_assignment( )
else
return nil
end
end
</pre>

* review_mapping_controller.rb
<pre>
# Get all the available submissions
def show_available_submissions
assignment = Assignment.find(params[:assignment_id])
reviewer = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
requested_topic_id = params[:topic_id]
@available_submissions = Hash.new
@available_submissions = DynamicReviewAssignmentHelper::review_assignment(assignment.id, reviewer.id, requested_topic_id, Assignment::RS_STUDENT_SELECTED)
end
</pre>

=='''References'''==
<references/>

CSC/ECE 517 Fall 2015/oss E1552 NRR

2015-10-31T15:56:57Z

Rahuja: Created page with "'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb'''"

'''E1552 Refactoring dynamic_review_assignment_helper.rb and dynamic_quiz_assignment_helper.rb'''

CSC/ECE 517 Fall 2015

2015-10-30T03:22:18Z

Rahuja: