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

In review_bids_others_work.html.erb in sign_up_sheet folder in views it can be seen that some code is DRY.

• Proposed Solution : review_bids_others_work.html.erb will be refactored. We will try to find the the repetitive code in it and remove it as required without effective the current implementation.

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

This issue is quite an important one. The algorithm currently needs valid bids from all the people and would not work if there is a user who does not bid for any of the projects.

• Proposed Solution : For the above case, the best solution that should work out is assigning the bids to random projects where a user does not bid for any of the projects to review. The code needs to be refactored and enhanced accordingly to take care of the modification.

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

So this is an open-ended issue. Currently, the bidding algorithm only works on assignments with the team. Currently, if the assignment does not have a team then no project gets assigned to the user until a team is formed. Yes, we can tweak the code so that an individual user gets assigned a project, but it won't make much sense as this is supposed to be a group project and there will be limited topics for the same. If the algorithm will go on assigning projects to individual users also then the pool will get exhausted.

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

For this issue we need to include a count which contains the count of the number of students/teams who have made their bids.

• Proposed Solution : For this we would include a count in the method assign_bidding of controller review_bids_controller.rb. This attribute will help us to keep track of the number of students bidding for reviews. We will increment this count whenever a team or a student bids for a particular review and decrement it if all the bids are removed by any team. This count will be stored in DB and shown to the users in the view page.

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?

The methods in rebiew_bid.rb are to get bidding data, to assign review topics, assign topic to reviewer and for getting individual reviewer_ids bidding data. These all are class methods. If we convert these to the instance methods, then we will have to create an object and then call these methods. So we will have to go through the flow to check whether it fits perfectly. If we are not able to convert these to instance methods, then a better approach would be to move these functions to a helper function.

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

This issue is quite critical and pivotal to ensuring the sound functioning of the complete code base. The testing should encapsulate all the edge cases where the code behaves differently than the expectation.

• Proposed Solution : We need to work on capturing all the scenarios and increasing the number of test cases to encapsulate all the edge cases which will help in the smooth functioning of the application. The code needs to be modified and refactored according to the testing results obtained to handle the additional conditions that are supposedly tricky.

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

RSpec

The main task here of testing is to make sure no functionality is breaking because of the refactoring.

• If we decide to move the code of review_bid.rb to a helper as discussed as a possible approach for problem 7, then we will have to add some additional test cases to make sure the functionality is still working as necessary.
• For Problem 5 if we add a new attribute to count the number of students that have made bids we need to add a test case to check if the count is incremented or decremented correctly
• For Problem 6, we need to add a test case to check if the Run Review Algorithm button is enabled to run the algorithm again
• For Problem 9, A new test case will be added in review_bids_helper_spec.rb that tests the changes in background color based on the number of participants and outstanding size.
• Unit test cases will be added to verify the logic behind the methods to calculate the values for their metrics

Physical Testing

• We will have to run the project and check for all possible functionality that might get affected because of the refactoring done.
• Also for problem 5 we need to check if the count of bidding is displayed.

Reference

1. Expertiza on GitHub
2. Previous Documentation
3. Previous Video
4. Previous Pull Request