Open JasonYapzx opened 1 year ago
Statuses were added relatively later in the project, and we focused more on other important parts like adding statuses to the application model, updating commands to take in statuses, and also designing the GUI to display statuses. Sorting by statuses was not intended in this version, but can certainly be a good feature to add in a future version.
Team chose [response.NotInScope
]
Reason for disagreement: [I do believe this is in line with the team's user story that was generated, being able to sort the applications via their statuses should also be included. Granted, we did not have to implement everything in our user stories (namely those with lower priority), but again, the usefulness of sorting via status would be much higher compared to that of sorting via whatever positions I may or may not have applied. As such for those users that may want to sort via application status, it would be a feature that is lacking within the current iteration of the application. I do feel it is apt to still include this as a feature flaw.
Taking a look at the team's code base, the implementation of each sort is largely the same (with the exception of interviews) as shown below:
Since application statuses are stored as strings, the implementation of the sorting would be similar if not identical to that of sorting via Company. This would not require a huge amount of effort to implement thus I do believe this can still be considered a flaw in the sorting feature. ]
Issue
The current application does not support the ability to sort via application statuses, which could be more convenient for users who prefer to see an overview of all their current applications, this could potentially be more useful than organising all the SWE applications/ Data Engineer applications together because it allows the users to more easily keep track of how many potential emails/technical interview rounds they might have to prepare for. It would be more fitting to have this ability rather than sorting by positions.