Open joshuan98 opened 1 year ago
As mentioned in the user guide,
The specification for timetable /fancy is that it will show unreadable output if the terminal does not support it and a fancy output if the terminal does. Hence, the program is performing exactly to specification.
[The team marked this bug as a duplicate of the following bug]
"timetable /fancy" command does not work at all
"timetable /fancy" command does not work at all
[original: nus-cs2113-AY2223S1/pe-interim#21] [original labels: type.FeatureFlaw severity.High]
[This is the team's response to the above 'original' bug]
As mentioned in the user guide,
The specification for timetable /fancy is that it will show unreadable output if the terminal does not support it and a fancy output if the terminal does. Hence, the program is performing exactly to specification.
Items for the Tester to Verify
:question: Issue duplicate status
Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)
Reason for disagreement: [replace this with your explanation]
Team chose [response.Rejected
]
Reason for disagreement: I provided explanation in issue #34 in CATcher. I have copied the explanation below:
I strongly disagree with the line of reasoning provided by the team. Clearly, the timetable /fancy does not work on Windows as per my screenshot in another issue (#25 in CATcher). Hence, the functionality provided is obviously OS-dependent.
Asking the user to "install a terminal which supports it or configure their terminal to support it" is a slippery slope argument. Firstly, the group provides no support on which Windows terminal supports it or provide an explanation on how to configure command prompt to support it. Secondly, by the team's logic, it means that the onus is on the user to make sure that the program works which simply should not be the case.
Moreover, while it is true that the differences between timetable /fancy and timetable /simple are purely cosmetic, it remains a fact that a Windows user who types /fancy will not be able to glean any discernable information from the output. With no error message provided, it is clear that the program does not fail gracefully.
In fact, the group could have simply disabled this feature on Windows platform entirely. As such, this error could be labelled as a feature flaw instead.
Considering the fact that all Windows users would not be able to use this function but there are other alternatives, I think that the issue severity could be reduced to medium but certainly not lower than that.
Team chose [type.FeatureFlaw
]
Originally [type.FunctionalityBug
]
Reason for disagreement: [replace this with your explanation]
Team chose [severity.Medium
]
Originally [severity.High
]
Reason for disagreement: [replace this with your explanation]