search

Devanshshah1309 / pe

0 stars 0 forks source link

Unreasonable non-alphanumeric constraint on Task Names #2

Open Devanshshah1309 opened 1 year ago

Devanshshah1309 commented 1 year ago

Steps to Reproduce

Run task add tn/Review PR #2 i/Due ASAP d/12/12/2022

Expected

Task should be added. It is very common to want to have characters such as #, (, !, ), etc. in tasks and it is unreasonable for users to not be allowed to enter them in task names. For example, a TA for a software engineering module might want to look through a random PR of a group to make sure they're following the right instructions given by the instructors. Hence, the task name can be "Review PR#2", which is how GitHub and other applications refer to issues and PRs.

The problem is made worse by the fact that you cannot even enter parentheses (which is a very commonly used). Hence, it significantly hinders users from performing common actions.

Actual

Screenshot 2022-11-11 at 4.21.36 PM.png

nus-se-bot commented 1 year ago

Team's Response

As a group, we do think this is a minor flaw. However, we as a team agree that:

  1. A severity of high suggests this completely breaks something or has disastrous outcomes. We disagree on that since it's not really that common to use special characters in what you expect to be task descriptions or names aside from very specific workflows you mentioned like reviewing PRs

  2. Given the current example, you could very easily just name it task add tn/Review PR 2 i/Due ASAP d/12/12/2022. It feels like a mild inconvenience to the user, not something that significantly hinders any action

    Items for the Tester to Verify

    :question: Issue severity

Team chose [severity.VeryLow] Originally [severity.High]

Reason for disagreement: This is not a cosmetic issue and should not be labelled with severity.VeryLow.

However, after some thought, I do agree that this issue doesn't make the app unusable and so it shouldn't be high severity.

I would argue that it is a medium severity feature flaw for the following reasons:

  1. There is no real reason why this constraint on alphanumeric characters even exists in the first place. Why was it not possible to allow users to enter special characters (except quotes as that might mess with the parsing)?
  2. I agree that the user "can just remove the #" but that's not the point. It does cause inconvenience to the user (as you accepted it being a minor flaw). As a developer, you want to be able to ensure the smoothest and most intuitive experience for users. If it is common for users to use special characters for tasks in other task management applications (notion, asana, etc.) why does your app not provide support for it? They would be used to inserting these special characters everywhere else and would have to consciously avoid them for your application.

As per the module's website,

severity.Medium : A flaw that causes occasional inconvenience to some users but they can continue to use the product.

Based on the above points, I think this is a medium severity feature flaw bug.

Side note: as mentioned in other issues too, I feel this is a deliberate attempt to lower the severity of an issue with the hopes that the tester doesn't (or forgets to) disagree since it is obviously not a cosmetic bug and does affect usage.