soc-se-bot
commented
1 week ago Team's Response
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 response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: After reading the response, I can understand why the team has chosen not to agree with my request but I don't agree with it. This is because since the "Team" and "Cycle" field is not included in the application yet, it is fair that I felt that there is no need for any duplicated entries. This is because from the user point of view, the entries in the app will look the same if it is the same role, same company but different team as the there is no "Team" and "Cycle" field to indicate the differences. Also, the UG did not mention anything about this additional enhancement, hence from a perspective of a tester, I think it is valid for me to think that this a consideration they missed when implementing rather than a deliberate action to leave it out.
Furthermore, this is a part of their response,
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.
This shows that they agree that my concern is valid, but just not in scope for this iteration. So why is it that it is a `response.rejected' which indicates that I am clearly wrong when they agree that something more can be done to improve this feature?
Hence I believe that the very least I should get would be response.NotInScope and not response.Rejected as I had made a valid response especially considering the fact that it was not stated in the UG that the enhancements will be done in future iterations.
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