search

ruiyangzh / pe

0 stars 0 forks source link

Keying in date/time for meetings is difficult and unwieldy #8

Open ruiyangzh opened 10 months ago

ruiyangzh commented 10 months ago

The command format requires user to key in details of a meeting's timing down to the minute. This is not only unneccessary (as many schedules may not be a strict timing), but also frustrates the user when entering a schedule since the reason for failure is not informed to the user. For example the command schedule 1 i/2021-02-29-23-23 are rejected because they do not fit the leap year timings.
However, the message is a generic 

Schedule time should be in YYYY-MM-DD-HH-mm, and be valid. E.g. 2020-09-30-23-59. 
Please check to make sure the date & time exist.

This can affect users quite severely, since meetings are a core feature of the application. However the app is still useable, hence it is of severity medium.

soc-pe-bot commented 10 months ago

Team's Response

Since this issue mentions two bugs:

  1. It's unnecessary to key in schedule time down to the minute
  2. The error message is not specific enough

We choose the first bug to discuss.

We downgrade the severity of this bug to severity.Low since it only inconveniences the user occasionally, as only a subset of schedules a user wishes to key in will lack fields. Moreover, we mark this bug as response.NotInScope since:

  1. This inconvenience is minor because if the user wants to enter a meeting's timing down to the hour, they could just type "-00" for "-mm". Similarly for schedule timing on a general date, the user could type "-00-00" for "-HH-mm". This is a fairly easier workaround, with only 6 characters being added as an input. Furthermore, it appears reasonably uncommon for users to not have at least an idea of when they ought to be ready for an event (e.g. if a user schedules a meeting, they likely have some idea of a hard deadline they ought to be present for it!)
  2. The UG states that only YYYY-MM-DD-HH-mm is accepted.
  3. Any attempts of doing otherwise will fail and return an error message.
  4. The tradeoff for any such implementation is that parsing has to be reworked to be strict enough to account for invalid fields (taking into account leap years, etc.), but lenient enough to allow for missing fields & inference. While certainly not as much work as a full feature, we posit that the work put towards development of new features delivered by the dev team like note was better spent towards those features, rather than tweaking a facet of a feature that causes minor inconvenience.

image.png

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: Hi, I can see the reasoning for this being not a medium-severity bug. However I still think this should be considered a bug to be fixed. The problem is not that the user is unsure when the meeting is; it's that the user must provide additional details even when such details are not necessary to their workflow, and burdens them to type extra strokes, especially the '-' character which is a special character. Although this is stated in the UG, I do not believe that much extra effort would be needed.

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]