nus-pe-script
commented
1 week ago Team's Response
No details provided by team.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
Duplicates are allowed in the add command
Duplicates can be added to the list, I don't think it make sense to have duplicated entries as they are referring to the same internship, hence I believe this is a bug
[original: nus-cs2113-AY2425S1/pe-interim#341] [original labels: severity.Low type.FunctionalityBug]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
Thank you for raising this concern. We appreciate your feedback and understand the potential need to track seemingly duplicate internships under specific scenarios. Below, we address some of the examples provided and explain our decision.
- Different Contexts to the Same Role and Company
Same Role, Same Company, Different Teams: In large companies, the same role (e.g., "Software Engineer") may be available across different teams or departments (e.g., "AI Team" vs. "Web Development Team"). While the role and company are identical, the actual context of the internship is different.
Different Hiring Processes: Applications for these roles might go through different interviewers, timelines, or skill requirements, warranting separate entries.
Updating the skills and deadline sections of the internship would allow for valid differentiation of the internship, and if these attributes are essential for the user to track their applications, treating these as duplicates would lose meaningful data.
- Multiple Applications to the Same Role
Reapplication: An applicant might apply to the same role multiple times, perhaps in different semesters or application cycles. Tracking these separately provides a better history of their applications and outcomes.
Overlapping Applications: Some internships might have overlapping timelines but differ in details like starting dates or preferred qualifications.
While we agree that further differentiation—such as introducing fields like "Team" or "Cycle"—could enhance the functionality for tracking such cases, we believe these enhancements are beyond the scope of the current iteration. For now, we recommend leveraging existing fields (e.g., skills and deadlines) to differentiate internships where appropriate.
Allowing duplicates ensures flexibility for users to track applications as they see fit, even in cases where roles may seem similar but differ in meaningful ways. Additionally, users can manually avoid duplicates if they find them unnecessary for their use case.
As such, we have decided not to treat this as a bug.
Items for the Tester to Verify
:question: Issue duplicate status
Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
## :question: Issue response Team chose [`response.Rejected`] - [x] I disagree **Reason for disagreement:** Thank you for your detailed explanation. While I understand the scenarios where seemingly duplicate internships may have valid differentiation, I would like to highlight the core issue: 1. Given the same inputs, the system currently allows two identical internship entries (same role, company) to coexist. This behavior is not a matter of flexibility or user customization but rather a fundamental issue of data integrity. 2. Impact on data quality: Allowing exact duplicates leads to redundancy and potential confusion for users, especially in scenarios where identical entries could be mistaken for separate applications or records. Additionally, this could lead to a problem where skills and deadlines are added to incorrect entries with the same initial information, this nullifies your suggestion to use skills and deadlines as a form of differentiator between the internships. 3. Tracking history: While tracking reapplications or internships in different teams or cycles is valuable, this requires explicit fields to differentiate those cases. The current implementation does not enforce or support this level of differentiation, meaning the system does not guarantee that users track these scenarios accurately or meaningfully. 4. Balance between flexibility and reliability: While flexibility is important, it should not come at the expense of the reliability of the data. A system that permits exact duplicates without requiring any distinguishing fields introduces ambiguity and undermines its purpose of organized tracking. If you want to accept duplicate internships, a solution would be to allow users to either highlight that this is going to be a duplicate or to allow more input arguments to prevent exact duplicates while still accommodating the users needs for differentiation. In its current state, the system fails to ensure data integrity by allowing exact duplicates to be created, which is why I maintain this issue qualifies as a bug rather than a feature decision.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.High`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
The ability to add duplicate internships is a feature flaw as it could be a mistake by the user who re-input it again by accident. This can be seen from the 2 different ids given for the same input information. Consider checking for duplicates and giving a warning message.