soc-se-bot
commented
10 months ago Team's Response
Overzealous rejection of inputs can annoy the user:
A user might want to enter a lesson in the past, just for record keeping purposes. Such overzealous input blocking can be considered a type.FeatureFlaw.
As for the suggestion on the edit, the possibility of user 1 making a careless typo and modify the day of lesson wrongly and 2 the input remain a valid date input after the typo and 3 happened to be a day in the past year can is flagged is very rare. On the other hand, modifying the lesson date in the past is a significantly more common use case, and blocking this could be taken as overzealous rejection of inputs can annoy the user.
Moreover, in our carefully designed feedback panel, the user could see and compare lesson before and after edition and realize the typo made. This further reduce the already low risk of "This could be an issue for users because they can make a typo and be confused when they come back to the app at another time."
Therefore, we conclude that this issue is not a bug.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: Although the team argues that this would be overzealous, I feel that this is a necessary feature in the context of this particular application, since this is a productivity/planner app.
The team replies " On the other hand, modifying the lesson date in the past is a significantly more common use case, and blocking this could be taken as overzealous rejection of inputs can annoy the user."
This is different from my suggestion: which is to only allow the adding of new lessons past the current date. Expired lessons can remain in the app if the user chooses not to touch it. But if they want to edit the date, it should only be allowed to make adjustments to a new date that is after the current time.
Why would the user want to edit an expired date into another expired date? It does not make sense, unless the user edits the date to a new valid date in the future(for example, to update a lesson that is recurring every week).
In some applications, adding events in the past might be acceptable, for example, you might want to add a birthday of a user which is clearly in the past. But the context of the application simply does not make sense to allow for NEW lessons to be added in the past.
This could be considered as an acceptance bug.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
You can edit/add lessons on dates that have already been past. This could be an issue for users because they can make a typo and be confused when they come back to the app at another time.