search

nus-cs2103-AY2324S2 / forum

16 stars 0 forks source link

Duplicate of a issue with multiple bugs #957

Closed drustanyjt closed 6 months ago

drustanyjt commented 6 months ago

A different tester put two bugs into the same report, on each for commands A and B (call this issue 1). I'm guessing he did this because he felt that there should be the ability to undo A and undo B by allowing negative inputs, and they both had a similar idea.

I instead have reported them as two separate bugs (of two different severities even), but the developer has marked both of my bugs as duplicates of issue 1.

Would it make sense to mark 1 of the 2 bugs I reported as not a duplicate? The instructions on the website seem to apply more to the developer response phase:

image

damithc commented 6 months ago

@drustanyjt If you believe the two bugs are not duplicates, you can object to the duplicate flagging of one of the bugs.

Although another tester combined them into one bug report, if they are actually two bugs, the dev team should have treated issue 1 as containing one of the two bugs, not both. But if they are duplicates, the dev team did the right thing.

So, you'll need to decide based on how strong you believe these two are distinct bugs and not duplicates.

drustanyjt commented 6 months ago

@damithc thanks prof. I took a closer look at the response given by the team. I realised the team's response to Issue 1 only addresses command A and makes no mention of command B.

I intend to mark my bug that mentions command B as a duplicate (both of my issues are FeatureFlaws, and both commands are different objects with their own parser, so I believe it is impossible that rectifying the flaw in one command will fix the flaw in the other).

Given that the dev team's response does not mention command B at all how should I interpret their response? I was thinking I could try replacing every mention of A with B and respond to that instead, but I'm not sure if I am then misunderstanding their intended design of command B.

The command input formats of A and B are almost identical. Given this, another way could be to try and infer how the team would have argued if they were directly addressing the flaw in command B (based on their argument for A), in the context of what B is suppose to do, and try responding to that instead?

damithc commented 6 months ago

@drustanyjt You can also cover both cases. i.e.,

There are two ways to interpret the dev team's response: 1....

  1. ... For position 1, my response is ... For position 2, my response is ...
drustanyjt commented 6 months ago

Okay thanks prof @damithc, I will do that!