soc-se-bot
commented
1 week ago Team's Response
Thank you for your insightful feedback and for raising this concern regarding the user experience. We understand how an update_student or update_grade feature could enhance usability by reducing repetitive actions.
After reviewing this, we agree that it is a valid suggestion and have accepted it as a bug. However, we consider this to be of low severity for the following reasons:
-
Priority Differences:
Components, as changable entities, have grades and other data depending on them. Therefore, ensuring the ability to update components is crucial to maintaining the integrity of related data. -
Standalone Nature of Grades:
Grades, unlike components, are standalone data that can be easily deleted and re-added if needed. Similarly, student records are typically static, as they represent fundamental entities rather than frequently edited information.
While we acknowledge the inconvenience of repeated actions in some scenarios, this does not significantly hinder the program's core functionality. The current design ensures all necessary operations can still be carried out, albeit with some additional steps.
That said, we’ll consider prioritizing this feature enhancement in future iterations to improve the user experience further. Thank you again for your valuable feedback, and please feel free to share any additional thoughts!
Items for the Tester to Verify
:question: Issue severity
Team chose [severity.Low]
Originally [severity.Medium]
- [x] I disagree
Reason for disagreement: I disagree. The team's argument is not convincing enough that it should be severity.Low instead of severity.Medium. Based on the definition of severity.Low and severity.Medium, both severity still allow the user to continue use the product. Therefore, claiming that "this does not significantly hinder the program's core functionality. The current design ensures all necessary operations can still be carried out, albeit with some additional steps." and thus a severity.Low is not sufficient to qualify the issue as severity.Low. The question then becomes "How much of an inconvenience does this issue cause?" and "How often will it occur?".
To begin, the team pointed out priority differences, which instantly served as a red flag to me. Their argument implies that maintaining the accuracy of student data and grades is of lower priority compared to maintaining the accuracy of components. This perspective is fundamentally flawed because student data, grades, and components are all essential to the functionality and integrity of the application. Inaccuracies in any of these areas can lead to significant consequences, affecting student records, performance assessments, and overall academic tracking and integrity. All data entities—students, grades, and components—should be maintained with equal priority to ensure the system functions correctly and reliably.
Secondly, the team also mentioned about standalone data, static variables, etc. This gives me the impression that the team is not grasping hold of what the actual issue is. Their argument overlooks the fact that operations involving adding students and grades are far more frequent than those involving components. Consider the following typical academic scenario where professors need to manually add and manage data and grades for the WHOLE cohort of students (100+) compared to adding 4 components (Quiz 1, Quiz 2, Midterms & Finals). Judging the number of parameters for input as well, I think its clear that the add operation for grades and students data is more likely to result in frequent errors. The course only mentioned fast typists but nothing about being accurate. I would argue that it would cause a significant amount of inconvenience for the user as they conduct repeated actions of adding students and grades and are unable to update their misinputs quickly.
It's also common to see changes to student's grades after grades are released due to occasional error in the marking scheme. Realistically, it is more rare to see changes to components in the midst of the semester. Ultimately, there seem to be a mishandling of priority for the features as updating of components was chosen over updating student data and grades even though they are approximately of the same complexity. As occasional significant inconvenience is caused to the user, I labelled it as severityMedium.
Based on the above, I would also like to argue that the issue is within scope because fixing the issue is not less important but equally important as the work done in v2.1.
In the case where the user accidentally misinput the student's data or grades, it might be inconvenient for the user to repeatedly delete the student/grades first then add back the correct one. The interactions could be more user friendly such as incorporating a update_student/update_grade feature. I don't see why this is not considered for students & grades but components is.
Even though these features are put as 'in the future', I think its important as this will degrade the user interactions with the program and should be place high priority same as updating components.