CSC/ECE 517 Fall 2023 - E2375. Reimplement Waitlists: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 12: Line 12:
'''Issues we found in Current Functionality'''
'''Issues we found in Current Functionality'''


* When a team is deleted, and if that team currently holds a particular topic, that team is also being deleted. However, the topic is not being assigned to the next team that is at the top of the waitlist queue.  
* When a team is deleted, and if that team currently holds a particular topic, that team is also being deleted. However, the topic is not being assigned to the next team that is at the top of the waitlist queue.  


=== Comments on why E2240, was not merged ===
=== Comments on why E2240, was not merged ===

Revision as of 18:27, 30 October 2023

Topic Overview & Prior Work

Feature Overview

E2281 contains detailed information on the previous team's work with this feature.

A summary of the desired functionality is presented below:

Any instructor or TA can sign students up for a topic. Students are able to sign themselves up for a topic. If the topic is full then the team will be put on a queue or "waitlist" for the topic. If the current team holding that topic drops the topic, then the team at the top of the waitlist will be assigned the topic.

Issues we found in Current Functionality

  • When a team is deleted, and if that team currently holds a particular topic, that team is also being deleted. However, the topic is not being assigned to the next team that is at the top of the waitlist queue.

Comments on why E2240, was not merged

  1. The code for the waitlist is distributed all over the application, which is something could have been placed into a single model and called through other files
  2. Although manual testing looked solid, there were not enough automated test cases to back their functionality.
  3. Too many class methods. A design with multiple class methods is not taking advantage of object orientation, which says that all actions should be structured as operations on a specific receiver.
  4. The code does not follow Ruby style design.
  5. Lack of descriptive code comments