search

Nanosync / pe

0 stars 0 forks source link

Stats bug: End date #7

Open Nanosync opened 4 years ago

Nanosync commented 4 years ago

Reason: Users might incorrectly key in the date and the app should prompt the user of invalid input.

Steps to reproduce:

  1. Entering 33 nov as end date is parsed as a valid input

image.png

nus-pe-bot commented 4 years ago

Team's Response

This issue is due to an attempt to allow more natural forms of date and time input by integrating Natty and paticularly the limitations of the natural language processing used by Natty. Natty attempts to parse anything a user enters that resembles a valid date as a date. This results in unexpected date time when the representation of the date a user enters does not align with Natty's expectations.

Natty attempts to recognize a wide range of date formats, but since there is an inherent ambiguity in the grammar describing these formats, some decisions need to be made arbitrarily.

Excerpt from Natty's documentation available here

As language is naturally ambiguous in the absence of context, and stronger natural language processing to determine said context, it is not feasible to correctly parse every single date that a user enters.

For example:

Attempting to parse 33 alone is ambiguous. 33/2 is less ambiguous, however, this format does no align with most common time inputs, and the date is also not a valid date. However, Natty is not aware of the context of this input and tries its best to determine what it could mean. This results in it parsing a time rather than a date as 33 is not a valid date in any context. This results in the outcome seen where Natty parses the 2 in the input an an hour rather than a month due to the absence of a valid date, since in most contexts 2 is taken to be a time.

For this particular case:

As stated in our user guide, users ‘can refer to http://natty.joestelmach.com/ for documentation and more information’. As seen from the ‘try it out’ section of the aforementioned website, Natty successfully parses a datetime input of ‘nov 32 2019’ as 1st Nov. This matches the success message in the screenshot of the bug report (1 Nov). The time field of the added budget in the report (12:00:00 AM) is an intended budget feature.

image.png

Hence, we are changing the bug type to a FeatureFlaw:

type.FunctionalityBug: A functionality does not work as specified/expected.

Downgrading severity to Low:

We are defining this issue as not in scope for the following reasons:

Team chose [response.NotInScope]

Reason for disagreement: Thank you for the response.

According to the User Guide, the team has modified the natural language parser to read dates as dd/MM.

image.png

This has led me to believe that the team is talented - they are highly capable in modifying the third-party library's behaviour and validating additional inputs passed to Natty since the input format was changed.

Even if there are no rigid date formats, it should still be mentioned in the user guide as a tip that invalid dates that are entered may not show an error message. In the best case scenario, an error message can be shown.

Thus, I believe that this issue is still in scope.

:question: Issue severity

Team chose [severity.Low]. Originally [severity.Medium].

Reason for disagreement:

:question: Issue type

Team chose [type.FeatureFlaw]. Originally [type.FunctionalityBug].

Reason for disagreement: