search

nus-cs2103-AY2122S2 / forum

13 stars 1 forks source link

Questions regarding what is allowed in v1.4 #238

Open benmurphyy opened 2 years ago

benmurphyy commented 2 years ago

I have a couple of questions regarding what is allowed in v1.4 that is not mentioned in the module website: 1) can we adjust and improve error messages shown to user on invalid inputs in v1.4 ? 2) can we make bigger changes to the ui (show more things, but no adding of new commands involved) other than the mentioned styling like text size etc

damithc commented 2 years ago

@benmurphyy These are both behavior changes that are not bug fixes. Hence, not allowed. The v1.3.* should already have the exact behavior you intend to have in v1.4, barring bugs that escaped your testing.

Note that this kind of minor changes might normally be allowed in an actual feature freeze, but in our case, in the interest of uniformity between teams, we have to choose 'no behavior changes' rather than 'minor tweaks allowed' as it is hard to define the line between 'minor' and 'major' changes.

reignnz commented 2 years ago

Can I ask if it's possible to perform abstraction and refactoring of code during v1.4? For eg. changing the name of some files and encapsulating them into packages, but not affecting the behaviour of the code. Thank you!

damithc commented 2 years ago

Can I ask if it's possible to perform abstraction and refactoring of code during v1.4? For eg. changing the name of some files and encapsulating them into packages, but not affecting the behaviour of the code. Thank you!

@reignnz Yes. more details at https://nus-cs2103-ay2122s2.github.io/website/schedule/week12/project.html#2-start-fixing-ped-bugs-before-the-tutorial image

charmainehly commented 2 years ago

May I make a quick clarification with regards to the 'cosmetic enhancements' --> would we be allowed to edit the css files to include new styleclass and id in order to customise the colours of the various elements? Thank you!!

damithc commented 2 years ago

May I make a quick clarification with regards to the 'cosmetic enhancements' --> would we be allowed to edit the css files to include new styleclass and id in order to customise the colours of the various elements? Thank you!!

@charmainehly Should be fine, but if it results in a behavioral change, it will not be allowed. The spirit of the 'feature freeze' need to be maintained irrespective of which file is modified. For example, adding different colors to make the UI more informative will not be allowed as that's basically a new feature.

charmainehly commented 2 years ago

May I make a quick clarification with regards to the 'cosmetic enhancements' --> would we be allowed to edit the css files to include new styleclass and id in order to customise the colours of the various elements? Thank you!!

@charmainehly Should be fine, but if it results in a behavioral change, it will not be allowed. The spirit of the 'feature freeze' need to be maintained irrespective of which file is modified. For example, adding different colors to make the UI more informative will not be allowed as that's basically a new feature.

Yep, that makes sense, thanks prof! :)

benmurphyy commented 2 years ago

@damithc Hi Prof, just to clarify on the improving error messages point - what if the error message is considered a feature flaw? For example, I type in an incomplete field, but the error message presented does not specify the field i have inputted wrongly, hence being considered a feature flaw. Are we allowed to then change the error message to fix this feature flaw?

damithc commented 2 years ago

@damithc Hi Prof, just to clarify on the improving error messages point - what if the error message is considered a feature flaw? For example, I type in an incomplete field, but the error message presented does not specify the field i have inputted wrongly, hence being considered a feature flaw. Are we allowed to then change the error message to fix this feature flaw?

@benmurphyy fixing feature flaws is not allowed during the feature freeze. Fixing is allowed only if the error message has a bug (i.e., gives incorrect info).

benmurphyy commented 2 years ago

@damithc I see, did not know that! Thanks Prof!

damithc commented 2 years ago

more details: image

sharpstorm commented 2 years ago

@damithc Hi prof, then in that case, would changing the help messages to be consistent with minor fixes in the UG (E.g. Changing "Clear" to "Clear Data") be considered a cosmetic change or a functionality change?

damithc commented 2 years ago

@damithc Hi prof, then in that case, would changing the help messages to be consistent with modifications to minor fixes the UG (E.g. Changing "Clear" to "Clear Data") be considered a cosmetic change or a functionality change?

@sharpstorm There is no restriction on what you can change in the UG. But for the application itself, let's not do any rephrasing of UI text either. In fact I regret allowing cosmetic changes precisely because it is hard to draw the line of what is cosmetic and what is not. We'll be disallowing even cosmetic changes from next semester. This semester, we'll still allow it but the tolerance will be very low e.g., changes to line thickness, spacing, alignment etc. will be allowed.

AAlghrairy commented 2 years ago

Would an incorrect error message being displayed due to an error caused by something similar to Integer overflow be considered a feature flaw? If not, would we be allowed to modify the error message and/or display a new error message for this particular problem?

Also, for cases like bugs caused by Integer Overflow, are we allowed to ignore them completely as long as they are due to extreme user behavior (as is stated in admin website)?

damithc commented 2 years ago

Would an incorrect error message being displayed due to an error caused by something similar to Integer overflow be considered a feature flaw? If not, would we be allowed to modify the error message and/or display a new error message for this particular problem?

If the error message is incorrect (as opposed to not detailed/friendly enough), it is a bug and is allowed to be fixed.

Also, for cases like bugs caused by Integer Overflow, are we allowed to ignore them completely as long as they are due to extreme user behavior (as is stated in admin website)?

Depends. Handling such problems can be considered low priority (and hence, not in scope for the current version) if such input can only be the result of intentional extreme user behavior (i.e., not a potential user mistake). Another factor to consider is the potential damage such an input can cause. For example, if such an input causes the existing data file to get corrupted and past 'good' data to become unusable, the priority of preventing such inputs increases.