CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.

Team

Mentor

• Divyang Doshi (ddoshi2)

Team Members

• Vijaya Durga Kona (vkona)
• Anand Morlaw (asmorlaw)
• Varun Garg (vgarg4)
• Jagdish Kini (jkini)

Introduction

Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

Problem Statement

Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

What needs to be done

• Review_bids_others_work is a DRY violation
• Run_bidding algorithm should be assign_reviewers
• Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
• Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
• Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
• Ability to allow the algorithm to run again after running once.
• Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
• In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
• Test whether the topic changes color depending on the number of outstanding bids

Design

Problems and planned changes (need to change the content)

Problem 1: Review_bids_others_work is a DRY violation

get_data_for_review_report passes back a data structure with multiple response objects to the _review_report.html.erb view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

• Proposed Solution : get_data_for_review_report will be refactored to use partials

Problem 2: Run_bidding algorithm should be assign_reviewers

In this issue, Run_bidding_algorithm algorithm should be assigned a new name which is assign_reviewers.

• Proposed Solution : Run_bidding_algorithm will be refactored to a new name which is assign_reviewers. Accordingly, we will have to refractor this on the calling side too.

Problem 3: Currently it doesn't work if some student does not bid. In this case, the algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid

get_data_for_review_report passes back a data structure with multiple response objects to the _review_report.html.erb view. This violates the Expert pattern because the given view does not know how to break apart the structure passed to it.

• Proposed Solution : get_data_for_review_report will be refactored to use partials

Problem 4: Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?

get_data_for_review_report passes back a data structure with multiple response objects to the _review_report.html.erb view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

• Proposed Solution : get_data_for_review_report will be refactored to use partials

Problem 5: Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive

get_data_for_review_report passes back a data structure with multiple response objects to the _review_report.html.erb view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

• Proposed Solution : get_data_for_review_report will be refactored to use partials

Problem 6: Ability to allow the algorithm to run again after running once.

Bidding algorithm is allowed to run only once in the TOPICS webpage in the process of managing Assignments. The button Run Review Algorithm is enabled only when the parameter of the assignment can_choose_topic_to_review is true.

• Proposed Solution : Dependency on can_choose_topic_to_review attribute will be removed for the visibility of the button Run Review Algorithm

Problem 7: Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?

get_data_for_review_report passes back a data structure with multiple response objects to the _review_report.html.erb view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

• Proposed Solution : get_data_for_review_report will be refactored to use partials

Problem 8: In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing

get_data_for_review_report passes back a data structure with multiple response objects to the _review_report.html.erb view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

• Proposed Solution : get_data_for_review_report will be refactored to use partials

Problem 9: Test whether the topic changes color depending on the number of outstanding bids

get_topic_bg_color_review_bids in review_bids_helper.rb and review_bids_show.html.erb are responsible for the color changes based on the number of participants and bid size.

• Proposed Solution : A new test case will be added in review_bids_helper_spec.rb for this case that test the changes in background color based on the number of participants and outstanding size.

Diagram

Author's View : The flow for authors to email reviewers regarding the work they have been reviewed for:

Testing (need to change the content)

RSpec

As such no functionality changed in any function, only refactoring done. All the refactoring was carefully verified by running rspec tests. To run the spec file, run:

rspec spec/controllers/signup_sheet_controller_spec.rb

Physical Testing

We found that add_signup_topics_staggered was simply calling add_signup_topics function. So we eliminated the add_signup_topics_staggered function and manually checked and found that it is working perfectly fine.

Delete signup and delete signup as instructor method successfully broken down to remove the dry code by creating a new helper function. This functionality has not been broken due to any changes and has been checked by running rspec and testing manually.

Edge Cases and Pre-Conditions

1. When dropping topic if submission already done.
2. When deadline from dropping topic has passed.
3. Deleting topic when topic cannot be found.
4. Signup in case when user cannot be found.

Reference

1. Expertiza on GitHub
2. Expertiza on GitHub