search

nus-cs2103-AY2223S2 / forum

12 stars 0 forks source link

Feature freeze clarifications #310

Open damithc opened 1 year ago

damithc commented 1 year ago

[Posting on behalf of a team]

Regarding modification of error messages, the site stated that "Yes, but only if the current text is incorrect (i.e., a bug). Adding more information or otherwise 'enhancing' the text is not allowed." Currently, some of our error messages have been noted to be misleading or incorrect. How can we rectify this? Are we allowed to give more specific error messages so as to not mislead users? Or is it sufficient to just say that the input is invalid and justify in the UG?

Case 1: The current error message is correct but too general: Making the error message more specific is an enhancement, not a bug fix. Case 2: The current error message makes the user think the problem is X when in reality it is Y. This is a 'misleading' error message. OK to fix, but limit to fix to correcting the misleading nature of the message only.

We have a component called "Departments". A tester noted that a department's name should be case insensitive, which seems to be true. Is this a bug and are we allowed to change it?

If the case sensitivity of a feature does not follow the real world, it is considered a feature flaw. The best you can do in v1.4 is to document this behavior clearly in the UG. An exception is when the UG clearly states the case sensitivity but the actual feature doesn't follow it, in which case it is a bug and can be fixed.

We also store email as a data field. A tester also noted that an email's name should be case insensitive, which is true by definition of an email. Is this a bug and are we allowed to change it.

Same as above.

Some testers listed alignment issues as a bug. It was stated on the site that we cannot fix alignment, but if it is listed as a bug are we allowed to rectify it?

Only if the misalignment results in user being unable to view data or seeing incorrect data e.g., if two data items overlaps with each other.

4ndrelim commented 1 year ago

Hi prof,

If the case sensitivity of a feature does not follow the real world, it is considered a feature flaw. The best you can do in v1.4 is to document this behaviour clearly in the UG.

so as long as we clearly acknowledge our current limitations in the UG, we won't be penalized for it? Because i'm sure issues like this will arise again in the actual PE.

damithc commented 1 year ago

@4ndrelim

so as long as we clearly acknowledge our current limitations in the UG, we won't be penalized for it?

There is no such guarantee. But given feature tweaks are not allowed during the feature freeze, what you can do is to mitigate the impact by documenting the current behavior clearly, and possibly indicating how the feature will be further enhanced in a future version.