soc-se-bot
commented
4 months ago Team's Response
"i.e. --tags=" was referring to what a tag option is.
The line right below the line quoted states clearly that including "--tags=" will remove ALL existing tags of this client.
Furthermore, the "--tags=" field is in square brackets throughout the user guide, indicating clearly that it is not a compulsory field.
The second example of the screenshot above also demonstrates that adding "--tags=" without any parameters after will remove all existing tags.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: Thanks for the response.
I note the difference between what was written in the UG:
If the tag option is not specified, i.e. --tags=, the existing tags will be left as is.
And a possible improvement I thought of:
If the tag option, i.e. --tags=, is not specified, the existing tags will be left as is.
From my understanding, the team is trying to refer to --tags= as the tag option. Notably 'i.e' refers to 'that is', which as I've pointed out in my report, can be misinterpreted as --tags= is a means of leaving the tags out.
The new and improved documentation which places the i.e right after mentioning the tag option will completely eliminate this ambiguity!
## :question: Issue severity Team chose [`severity.VeryLow`] Originally [`severity.Medium`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
The description explaining the behaviour of the
editcommand can be misleading since it talks about not specifying the tag option and includes the tag option--tags=which can be misconstrued by a new user into thinking that--tags=is the intended input for not specifying the tag option. By following this, the user could unintentionally remove relevant tags from a client of theirs and be unable to recover them!