search

Devanshshah1309 / pe

0 stars 0 forks source link

Unreasonable constraint on Tutorial Group Naming #6

Open Devanshshah1309 opened 1 year ago

Devanshshah1309 commented 1 year ago

Steps to Reproduce

Screenshot 2022-11-11 at 4.39.10 PM.png

Expected

We expect our tutorial groups to be anything (or at least, any combination of letters and numbers). They can begin with L (e.g. CS2100 lab groups) or any other letter too. There's no reason why tutorial groups must begin T and can only have xx where xx are numeric values.

This feature completely neglects the group of users who don't have such nicely formatted tutorial group numbers. For instance, ES2660 has tutorial groups named SGX (for numeric values of X). Other modules have their own conventions, which should have been considered.

It is a High priority bug because if as a user, I cannot even add my own tutorial group name, how do I use the application?

Actual

Tutorial groups other than Txx are rejected by the application.

nus-se-script commented 1 year ago

Team's Response

This is similar to one of the other bugs, where we do agree that more flexibility for naming would be a good thing. However, we don't really think this is a problem of High severity. It feels like a mild inconvenience to just replace SG with T, not a bug with disastrous outcomes that severely hinders any workflow when working with this application.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: Thanks for your response!

Firstly, since you acknowledge that this bug causes inconvenience to a user, you cannot reject the bug report anyway.

Moreover, you did not mention which "other bug" this is similar to (so I have no idea what the context of that bug is). You could have provided a link (or an issue number?) for me to take a look at.

If your problem was regarding the severity, you should have lowered the severity to what you felt was appropriate; rejecting the bug was a poor decision.

:question: Issue severity

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

Reason for disagreement: Firstly, let me explain why severity.VeryLow is definitely a wrong severity label.

From the module's website,

severity.veryLow: A flaw that is purely cosmetic and does not affect usage e.g., a typo/spacing/layout/color/font issues in the docs or the UI that doesn't affect usage. Only cosmetic problems should have this label.

Since this is (obviously) not a cosmetic issue, it should not be severity.veryLow. It seems as though your team is intentionally trying to argue for an unreasonable stance in the hopes that the teaching team will find a "middle ground". You might want to take note (from the module website):

Excessive incorrect downgrading/rejecting/ duplicate-flagging, if deemed an attempt to game the system, will be penalized.

and also,

When the tester and the dev team cannot reach a consensus, the teaching team will be select either the dev team position or the tester position as the final state of the bug, whichever appear to be closer to being reasonable. The teaching team will not come up with our own position, or choose a middle ground. Hence, do not be tempted to argue for an unreasonable position in the hope that you'll receive something less than asked but still in your favor e.g., if the tester chose severity.High but you think it should be severity.Medium, don't argue for severity.VeryLow in the hope that the teaching team will decide a middle ground of severity.Low or severity.Medium. It's more likely that the teaching team will choose the tester's position as yours seems unreasonable.

Also, your team claims that "it is easy to just replace SG with T" and continue using the application. Yes, in this case it causes a mild inconvenience - but that was just an example.

Consider the case of our own module - CS2103T!

Imagine that there's a tutor (say, Ben) who is tutoring 2 sessions for CS2103T: T13-3,4 and W10-1,2. In other words, Ben is tutoring teams 1 and 2 on Tuesday 1pm and teams 3 and 4 on Wednesday 10am. Ben is very eager to try your application and attempts to add T13-3,4 as his tutorial name. Unfortunately, it doesn't work because you only allow tutorial names to be of the form Txx :( Okay, not a big issue for Ben! He just names it as T13 and moves on to add the next group.

He tries adding W10, which is again rejected by your app! How can he add W10 in your application? Is poor Ben expected to enter T10 and then remember that T10 in fact maps to W10 in his head?

This problem is made worse if he is tutoring two classes on different days with the same time: W13 and T13. What does he enter it as now?

This is why I claim that this constraint is unreasonable and makes the entire app almost unusable by a large number of tutors. Hence, the severity of this issue should remain High in my opinion.

I feel this is a good example of "building the system right" but "not building the right system" (doing the thing right vs doing the right thing). In other words, if users cannot use the app, it doesn't matter how cool the features are as it doesn't solve their problem.

Just curious, what made you decide to enforce such a strict naming convention? Was it to make implementing your feature easier? Anyway, if tutors of this module (for which you developed this entire application!) itself cannot use your application, it is worth questioning whether it was the right decision (it should have been obvious as soon as you started writing user stories - thinking about different kinds of teaching assistants would have helped you avoid this severe lack of user consideration).