soc-se-bot
commented
3 days ago Team's Response
Yes, what you said is a fact that we have missed out in our DG. On hindsight, it would have been better to explain how we arrived at our university list in our DG. But, we felt that overall it did not affect any functionality and this change would just make the explanation more whole.
Items for the Tester to Verify
:question: Issue severity
Team chose [severity.VeryLow]
Originally [severity.Medium]
- [x] I disagree
Reason for disagreement: The severity should not be VeryLow I feel as it has been clearly stated in the course website that this severity can be assigned to issues that have a cosmetic impact only. The severity should be medium I feel
No mention of where the universities list is being fetched from and no acknowledgements means that this hurts the very credibility of the app which the team has built and could raise some questions about the legitimacy of the sources from which they fetched their data. I've attached a screenshot with the missing acknowledgement (failing to acknowledge the NUS website/authorities providing the SEP Partner universities data for CEG)
Furthermore, the way in which the teams have input the quota for the universities in their list raises some questions.
As you can see from the screenshots attached above, (note that the actual table of data about the partner unis was obtained from the following link : https://ceg.nus.edu.sg/wp-content/uploads/sites/4/2024/08/CEG-AY2526-SEP-Round-1-Places.pdf) the University of Michigan has 1 seat only for sem 1 and no seats for sem 2. In contrast, the Boston college has 1 seat only for sem 2 and no seats for sem 1. However, there is no distinction between these 2 semesters in the quota values which have been input by the team in their code. They seem to have just taken the max value from the 2 semesters, but this raises questions about how they expect the admins to use this app then.
Since there is no parameter marking the semester for which the student has input his/her SEP applications, I assumed that the team has structured the codebase to work such that the allocations are all for a single particular semester. However, clearly due to the screenshots I've pasted, this does not seem to be the expected functionality of the app. This is because if it was, that would mean that students can be allocated to both the University of Michigan and the Boston college in the same semester (which shouldn't be possible as they have a non zero quota only in different sems) as they both seem to have a quota of 1 in the codebase. This causes much confusion about how the team expects the admins (who are the target users of the app) to use their app. It looks like the admins have to do a lot of pre processing work on the SEP data obtained from the student applications, before they could use this app. And even then, it looks like it may cause logical errors, none of which has been addressed by the team. So how useful even is the app in reality ?
This makes it difficult for developers going through the DG who wish to contribute to the code as well, since they do not understand the timeframe in which the app is supposed to function. Is it for a single particular semester ? If it is, won't it cause the logical error mentioned above where students are allocated to both the University of Michigan and the Boston college in a single semester ? Or Is it over both the semesters ? If it is for both the semesters combined, how does the app know for which semester the student has submitted their application ?
Not enough details were given in the DG about where the university indices and the universities themselves are being fetched from to create the hash map in the UniversityRepository object