nus-pe-bot
commented
1 year ago Team's Response
This does not affect the normal functioning of the app. The user need not look at the console output.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: I'm still not very convinced why this bug should be counted as NotInScope as the team did not really provide a strong justification for this.
According to the module website, the one of the following conditions must be proven to be fulfilled by the team to qualify a bug report as NotInScope:
- "The UG specifies it as not supported or coming in a future version."
This is not true, the team did not include that looking at the console output is not supported, or that it is coming in a future version.
- "The user cannot attempt to use the missing feature or when the user does so, the software fails gracefully, possibly with a suitable error message i.e., the software should not crash."
I can view console outputs (this is not a missing feature), the software does not stop me or fail gracefully when I try to do so.
More importantly, I think fixing this bug is pretty simple since it is just an issue with the xmlns tag in the team's FXML files are wrongly configured (only needed to change 5 version numbers):
and the errors in the console goes away:
and the app works fine (including the auto-fill feature):
Since no strong justification was provided as to why the team feels that this bug should be counted as NotInScope (according to the conditions that they have to prove, outlined in the module website), and the reasons above why I think this bug doesn't qualify for NotInScope, I'll unfortunately have to disagree with the team's decision.
Criteria extracted from module website
:question: Issue severity
Team chose [severity.VeryLow]
Originally [severity.Low]
- [x] I disagree
Reason for disagreement: The team mentioned,
"This does not affect the normal functioning of the app."
which I totally agree with.
However, I don't agree that this issue should be marked severity.VeryLow because this is not a purely cosmetic issue.
Rather, this bug is caused by an incompatible JavaFX version number- which is not a typo/spacing/layout/color/font issue.
However, as the team mentioned, and I agree with, this is flaw that is unlikely to affect normal operations of the product. The user still can continue using the product, even though some minor inconvenience is caused when reading the console log (have to sift through all the warnings to see actually useful information).
As such, (not a cosmetic issue + unlikely to affect normal operations of the product + minor inconvenience is caused), I stand by my initial decision that this bug should be classified as severity.Low, and not severity.VeryLow.
Extracted from the module website:
Description
JavaFX warnings shown in terminal. (wrong version- testing on macOS)
Steps to reproduce
Clicking on UI elements in the GUI (such as the list items) causes a JavaFX warning to be shown in the terminal, while this does not affect the main usage of the application, it causes the console to be crowded with warnings and this drowns out important logging information, making it difficult for users to read these logged information. (as shown below)
Screenshots