damithc
commented
10 months ago
The team has rejected my feature flaw issue, with the justification that it is the user's fault on the typo and they should fix it themselves based on the error message, in which the error message is correct. However, I believe that the app could do a simple fix to improve the user's experience. How should I go about justifying my disagreement to their rejection? If I would like to argue for NotInScope, do I have to suggest an implementation because the textbook states this:
if the feature is implemented to work in a certain way but it could have been implemented to work in a better way (from the end-user's point of view) without much additional effort
Does a feature flaw issue means that I have to make sure that this NotInScope change will not lead to more ambiguous issues, even though it fixes one of the many ambiguous issues, like white spaces trimming? I can anticipate some further debates on how trying to fix this feature flaw could give rise to even more ambiguous issues, but it is not stated in the justification of the dev team, so will the final evaluation of the prof and ta consider these aspects?
@GlendaChong If you are looking to get the FeatureFlaw accepted, the suggested fix should not take more effort (or cause more complications) than the current implementation. But if you are arguing for NotInScope, the effort doesn't matter as long as it is feasible to do and the value it adds is worth the effort it would take. But if it is likely to take more effort than the value it produces, it is unlikely to be done even in the future, and hence, not suitable for NotInScope either.
2. The team has also rejected another issue and marked as duplicate, but I realised it could have been a functionality bug instead of a feature flaw, which the dev team did not change the type. In this case, if I were to disagree with the rejection, should I justify based on which type? Will I be penalised if I talk about functionality bug instead?
In your response, you can admit you chose the wrong type in the original bug, propose a different type, and justify why the bug should be accepted under the new type.
3. According to this forum on duplicates, as long as the fixes are independent like of different paragraphs, they are not considered duplicates, because changing the format at one place doesn't fix the other one. Could I just further clarify if the example below could be considered as non-duplicates even though the team has marked it as NotInScope, if I report both use case 2 and use case 3 as separate format issues?
Use Case 1 1. .... 2. ... Use case ends. Use Case 2 1. .... 2. ... Use case ends. Use Case 3 1. .... 2. ... Use case ends.
Yes, they should be separate issue if fixing one doesn't automatically fix the other.
4. Can I clarify what it means by describing UI in use case? For example, if we state
App shows the error message, is that considered giving Ui details, and hence incorrect? Is the more appropriate and correct wayApp detects an error in the input?
App indicates to the user there is an error -> Good.
App shows the error message -> Borderline, but still acceptable
App turns the input box red to indicate an error -> Bad. Contains too much UI-specific details.
GlendaChong
Hi Prof @damithc, I have a few questions to clarify.
The team has rejected my feature flaw issue, with the justification that it is the user's fault on the typo and they should fix it themselves based on the error message, in which the error message is correct. However, I believe that the app could do a simple fix to improve the user's experience. How should I go about justifying my disagreement to their rejection? If I would like to argue for NotInScope, do I have to suggest an implementation because the textbook states this:
Does a feature flaw issue means that I have to make sure that this NotInScope change will not lead to more ambiguous issues, even though it fixes one of the many ambiguous issues, like white spaces trimming? I can anticipate some further debates on how trying to fix this feature flaw could give rise to even more ambiguous issues, but it is not stated in the justification of the dev team, so will the final evaluation of the prof and ta consider these aspects?
The team has also rejected another issue and marked as duplicate, but I realised it could have been a functionality bug instead of a feature flaw, which the dev team did not change the type. In this case, if I were to disagree with the rejection, should I justify based on which type? Will I be penalised if I talk about functionality bug instead?
According to this forum on duplicates, as long as the fixes are independent like of different paragraphs, they are not considered duplicates, because changing the format at one place doesn't fix the other one.
Could I just further clarify if the example below could be considered as non-duplicates even though the team has marked it as NotInScope, if I report both use case 2 and use case 3 as separate format issues?
App shows the error message, is that considered giving Ui details, and hence incorrect? Is the more appropriate and correct wayApp detects an error in the input?