CSC/ECE 517 Fall 2023 - E2350. Allow reviewers to bid on what to review: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 76: Line 76:
=== Ability to allow the algorithm to run again after running once. ===
=== Ability to allow the algorithm to run again after running once. ===


Dependency on <code>can_choose_topic_to_review</code> attribute was removed for the visibility of the button <code>Run Review Algorithm</code> allowing the user to click and run the algorithm multiple times
<code>can_choose_topic_to_review</code> attribute is handled so as to allow the user to refrain from clicking the button to run the algorithm again if done once already. So the attribute was removed for the visibility of the button <code>Run Review Algorithm</code> allowing the user to click and run the algorithm multiple times




Line 93: Line 93:
=== 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 ===
=== 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 ===


More test cases for edge scenarios are to be implemented.
Test cases were added and existing cases were modified for several scenarios.





Revision as of 04:59, 7 November 2023

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

Team

Mentor

  • Srilekha Gudipati (sngudipa)

Team Members

  • Amulya Usem (ausem)
  • Gowtham Pollam (gpollam)
  • Basaveswara Mukesh Suryadevara (bsuryad)


Links

  • Pull request [1]
  • Github repo [2]
  • Deployed server [3]
Credentials : username - instructor6 password - password

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


Soultions

Review_bids_others_work is a DRY violation

The file review_bids_others_work.html.erb has been refactored in order to resolve DRY violation by removing redundant code without impacting the current functionality.



Run_bidding algorithm should be assign_reviewers

run_bidding_algorithm was refactored to assign_reviewers. Accordingly, all the other instances of this were modified too.



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

The code was modified to assign random reviews to students in case they didn't bid for any.



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?

Currently, it is mandatory to have a team but we can still make the team be assigned a project even if the team has only one member since there is no settings to place a minimum member cap. Although the member will have to create a team and assign a name so that the member can place a bid.

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

We have included a count variable in assign_bidding of controller review_bids_controller.rb. It helps us to keep track of the number of students bidding for reviews and is shown to the users in the view page.


Ability to allow the algorithm to run again after running once.

can_choose_topic_to_review attribute is handled so as to allow the user to refrain from clicking the button to run the algorithm again if done once already. So the attribute was removed for the visibility of the button Run Review Algorithm allowing the user to click and run the algorithm multiple times



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 review_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. All the methods in review_bid.rb are converted into instance methods and other occurances were refactored to create an object and then call these methods.


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

Test cases were added and existing cases were modified for several scenarios.


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

A test case was added in review_bids_helper_spec.rb that test the changes in background color based on the number of participants and outstanding size.



Test Plan

RSpec

  • The main task is to ensure existing functionality remains intact post-integration of new code and refactoring of review_bid.rb.
  • Refactor tests in response to methods in review_bid.rb transitioning to instance methods.
  • For requirement 5, implement tests to validate the correct increment and decrement of the newly introduced attribute.
  • For requirement 6, introduce a test case to verify the "Run Review Algorithm" button's enablement for algorithm re-execution.
  • For requirement 9, a test in review_bids_helper_spec.rb assesses the background color alteration contingent on participant numbers and outstanding bid size.
  • Develop additional test cases to ascertain the random allocation of reviews when a student has not placed a bid.

Physical Testing

  • With the UI under development in a separate project, verification via direct links is essential.
  • Execute a full functionality sweep to detect any disruptions caused by the recent code refactoring.
  • For requirement 5, a manual check to confirm the visibility and accuracy of the bidding count is necessary at http://152.7.177.6:8080/review_bids/200.


References