soc-pe-bot
commented
1 year ago Team's Response
Hello! Thank you for your input on your bug. However, we have decided to reject this and that the severity should be reduced from Medium to Low.
Why should it be rejected?
NUSCoursemates utilises NUSMods API to check on the validity of the courses for AY 2023/2024 Sem 1 or Sem 2 and it was stated in our User Guide that we are only following the valid courses updated as of 11 Nov 2023.
However, it will be updated in v2.0 as well as our implementation of the live tracking of courses. We have included this in our planned enhancements in Appendix C.5.
In addition, we have also consulted Prof Damith on this situation in forum issue #404 and his guidance is that if a course is added after our stipulated date of update, it will be fine due to the constraints of the project.
Moreover, our team would like to address the given example, CP3200. This course is invalid as it is not offered in AY2023/24 for both sem 1 and sem 2.
In addition, it is untrue that NUSCoursemates does not accept industry attachment programmes and DYOMs. As shown below, NUSCoursemates accept such courses but there might be courses that have been added after 11 November and hence are not recognised by NUSCoursemates.
Lastly, there is a link to NUSMods on the UG, which directs the user to what are considered valid courses. The ban has to be enforced, or else there will be no way to perform course validation, which is vital to maintaining the integrity of the data in our app.
Why should it be severity low?
If the teaching team decides to accept this as a valid bug (for reasons unbeknownst to us), we would categorise it under severity.Low as it would only cause a minor inconvenience to our users in rare occasions. We believe that it should not be deemed as severity medium as this is a rare occurrence for users, majority of NUS SoC students would not take courses such as "CP3200, industry attachments programmes/internships, DYOMs" and utilise NUSCoursemates at the same time as NUSCoursemates intent is always for easy management and tracking of your peers during the semester. However, we have a stronger justification for this bug to be rejected.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: My points are misrepresented. The issue is not whether the app's data is always up to date with the latest semester or NUSMods, the issue is with the idea of mandating the course codes to be in line with NUSMods' latest semester in the first place. Meaning, it does not matter whether:
However, it will be updated in v2.0 as well as our implementation of the live tracking of courses. We have included this in our planned enhancements in Appendix C.5.
In addition, we have also consulted Prof Damith on this situation in forum issue #404 and his guidance is that if a course is added after our stipulated date of update, it will be fine due to the constraints of the project.
The course codes in the app only function as a name. Meaning, there is no additional function that can be done depending on what course you add. Its just a display similar to a name, email or address.
In line with these guidelines above, I believe this is considered an overzealous form of input blocking. Users can't enter their own personalized input for record keeping purposes (eg CS2103T (Y2S1)), which might be relevant as they stated that their app is a peer-keeping app for SoC students.
The ban has to be enforced, or else there will be no way to perform course validation, which is vital to maintaining the integrity of the data in our app.
It doesn't matter, there is no integrity that needs to be maintained as the course is just a display name. This is goes against their value proposition which they have mentioned several times in response to other issues and unnecessarily removes freedom to customize input choices.
Put simply, saying that course codes must be verified strictly for integrity is like saying that we should verify the person's name according to NUS' database, check if the telegram handle is valid, check if the email address is valid, check if phone number is actually in used, etc.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** I would actually like to revise the severity to **high**. It is a severe feature flaw that course codes are mandated to be in line with NUSMods' latest semester. They have mentioned multiple times that courses not offered in the current semester are classified as **invalid**: > Moreover, our team would like to address the given example, CP3200. This course is invalid as it is not offered in AY2023/24 for both sem 1 and sem 2. > NUSCoursemates accept such courses but there might be courses that have been added after 11 November and hence are not recognised by NUSCoursemates. There are many implications, for example not being able to add courses from past years if they are not offered now. But there is one that has **disastrous consequences**. Consider the following scenarios: **1. Course name changed in future semester.** - I added CS2103T in AY23/24. - `CS2103T` changes name to `CS2103N` in AY24/25. NUSMods updates to reflect this change. Their app also updates to reflect this change (like I said the issue is not whether their app is in sync with NUSMod's latest semester). - In AY24/25, when I open their app, `CS2103T` is deemed invalid. **Their app wipes the local database and clears the entire list as an invalid data is present in the JSON.** **2. Course not offered in future semesters.** - I added CS2103T in AY23/24. - `CS2103T` is not offered in AY24/25. NUSMods updates to reflect this change. Their app also updates to reflect this change (like I said the issue is not whether their app is in sync with NUSMod's latest semester). - In AY24/25, when I open their app, `CS2103T` is deemed invalid. **Their app wipes the local database and clears the entire list as an invalid data is present in the JSON.** Based on these grave consequences that risk the data in the app being wiped out, in addition to the great possibility of this happening (courses changing names and varying in when they are offered are very common), **I would in fact dispute even my own original rating and revise the severity to `severity.High` instead.** 
As there are credit-bearing courses that are not listed on NUSMods (eg CP3200, industry attachments programmes/internships, DYOMs), would it be better if we don't strictly block course codes that are not listed?
As there course codes are only relevant in name (there's no additional feature to link to NUSMods or anything), perhaps a warning would better suffice instead of a blanket ban?