soc-se-bot
commented
2 months ago Team's Response
Reason for response
The user guide states very clearly that the student ID field is used as the unique identifier for students. This is intended behavior. The 2 users created are not duplicate students from the perspective of a user who has read the user guide.
Addendum
For actual users, as you've already mentioned, its unlikely that 2 students with the same values for every field (aside from ID) will exist. Hence, teachers will very rarely have to deal with this issue and therefore we consider this a low severity issue even if it is one. It is much more probable that this becomes an issue when teachers forget if they've already entered a student into the contact list and try again, in which case the check on duplicate student ID will prevent them from doing so.
In this case, its not entirely clear which fields we have to check in order to make it "convenient" for the teacher to differentiate between students. Where to draw the line is very unclear. For instance, do we reject students who have the same name, same address but different emails? Do we reject students who have the same name, same email but different addresses? In order to not make inputs too restrictive, we use only the unique identifier to check for students.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: # Reason for rejection
I agree that it is unlikely that the teacher will have to deal with the issue as the error is uncommon. However, in the larger context, as this app is designed for the teachers of young children, it is reasonable to expect that some measures have been taken to ensure the child's information is accurate in the system just in case the teacher has to contact a parent, especially for emergencies. I do not believe the area in which teachers are most likely to make mistakes would be the student id. The parents also reasonably trust the teachers and the schools to do their part of being responsible for young children.
Furthermore, it is unlikely that a teacher will remember students by their ID unless it is easy to remember, such as a student with ID 00001. If they need to contact a parent urgently, they might need to search for it using the find feature and are unlikely to search by ID but instead will use the name. If the name of the child is not in the system because the name was wrongly written to be the same as another child, the teacher will not be able to find the student and will have to manually search through the list, which not only hinders the teacher but is not a good idea in times of emergency. In this case, traditional methods like an Excel sheet might be more suitable for referencing as all the contacts will be visible simultaneously.
Potential Solution
As for your dilemma on what information to make unique, I believe that students with the same name should not have the same phone number, at least.
This is also beneficial if a class has two students with the same name. If necessary, the teacher can try both numbers and avoid accidentally saving both children with the same parent's phone number. They will also not end up in a situation where one child is accidentally saved with the wrong parent's number.
Conclusion
Given that there is a lot of responsibility attached to being a teacher of young children, using an app that can hinder their ability to contact parents promptly will be discouraging for teachers to want to use.
Even if developers are unwilling to follow my suggestions, this issue should at least be dealt with in a future iteration and such should be either accepted or response.Notinscope.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** # Reason for rejection I agree that it is unlikely that the teacher will have to deal with the issue as the error is uncommon. However, in the larger context, as this app is designed for the teachers of young children, it is reasonable to expect that some measures have been taken to ensure the child's information is accurate in the system just in case the teacher has to contact a parent, especially for emergencies. I do not believe the area in which teachers are most likely to make mistakes would be the student id. The parents also reasonably trust the teachers and the schools to do their part of being responsible for young children. Furthermore, it is unlikely that a teacher will remember students by their ID unless it is easy to remember, such as a student with ID 00001. If they need to contact a parent urgently, they might need to search for it using the find feature and are unlikely to search by ID but instead will use the name. If the name of the child is not in the system because the name was wrongly written to be the same as another child, the teacher will not be able to find the student and will have to manually search through the list, which not only hinders the teacher but is not a good idea in times of emergency. In this case, traditional methods like an Excel sheet might be more suitable for referencing as all the contacts will be visible simultaneously. # Potential Solution As for your dilemma on what information to make unique, I believe that students with the same name should not have the same phone number, at least. This is also beneficial if a class has two students with the same name. If necessary, the teacher can try both numbers and avoid accidentally saving both children with the same parent's phone number. They will also not end up in a situation where one child is accidentally saved with the wrong parent's number. # Conclusion Given that there is a lot of responsibility attached to being a teacher of young children, using an app that can hinder their ability to contact parents promptly will be discouraging for teachers to want to use. Even if developers are unwilling to follow my suggestions, this issue is still a hindering factor for users and should be severity.Medium.  I also chose severity.Medium as although emergencies are hopefully rare situations, it is not a minor inconvenience for teachers to not to be able to promptly contact parents in emergencies.
This bug is important as you are noting down student details. It is unlikely that 2 students with the same details and same name could exist in the the same class. Although possible for to have the same phone number and address, it is unlikely that parents will name all their children with the exact same name with no variation.
This could make it difficult for the teacher to figure out which John Doe they are looking for and will have to check with the student directly for their unique id everytime they use your app.