search

peasantbird / pe

0 stars 0 forks source link

Create can have more optional fields #3

Open peasantbird opened 11 months ago

peasantbird commented 11 months ago

The current create command requires many fields to be inputted for it to work.

Example: create c/Citadel ro/Backend Developer a/Yet to apply de/01/02/2022 s/24/04/2022 du/2 re/C++

However, certain details like deadline for the application, starting date and duration of the internship may not be known until you receive the internship offer, which would mean that dummy values have to be placed inside these required fields.

Perhaps the application in the future could allow for more optional fields, apart from those that are required like the company name, role and application status.

soc-se-bot commented 11 months ago

Team's Response

Thank you for the bug report, but we are going to classify this as NotInScope.

Here is the reason why:

  1. Many job roles do mention when the internships normally start, even if the specific date is not given. You almost always know which month/whether it is a summer internship, for example. As a user, you can always default to the start of the month, the end of the previous month, etc. in cases when it is unclear. We leave this element of flexibility to you.

  2. It is an explicit design choice to make this parameter compulsory because we want it to make the filter command as impactful as possible. Our product is designed for students who are managing multiple internship applications - and certain internships are more desirable than others because of their start date. Making this parameter compulsory is our way of nudging students to key in the most amount of details to the best of their knowledge, so that they can filter for the internships that are most important to apply for first.

Similar lines of reasoning can be applied, for deadline, duration, etc. and we are more than happy to share our thoughts on the other parameters if you so request.

We appreciate the feedback though - in fact this was a major point of discussion during the inception of our product. For v1.4, we settled on making this parameter compulsory. But if enough users such as yourself think that we should make this parameter optional, we will make the change. Hence, we classify this as NotInScope.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Start date as compulsory parameter in create command

Many job roles do not mention the specific start date of an internship. I believe that having start date as compulsory parameter is not convenient for users.

image.png

[original: nus-cs2103-AY2324S1/pe-interim#5932] [original labels: severity.Low type.FeatureFlaw]

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

Thank you for the bug report, but we are going to classify this as NotInScope.

Here is the reason why:

  1. Many job roles do mention when the internships normally start, even if the specific date is not given. You almost always know which month/whether it is a summer internship, for example. As a user, you can always default to the start of the month, the end of the previous month, etc. in cases when it is unclear. We leave this element of flexibility to you.
  2. It is an explicit design choice to make this parameter compulsory because we want it to make the filter command as impactful as possible. Our product is designed for students who are managing multiple internship applications - and certain internships are more desirable than others because of their start date. Making this parameter compulsory is our way of nudging students to key in the most amount of details to the best of their knowledge, so that they can filter for the internships that are most important to apply for first.

We appreciate the feedback though - in fact this was a major point of discussion during the inception of our product. For v1.4, we settled on making this parameter compulsory. But if enough users such as yourself think that we should make this parameter optional, we will make the change. Hence, we classify this as NotInScope.

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)

Reason for disagreement: [replace this with your explanation]

## :question: Issue response Team chose [`response.NotInScope`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]