Open jayasting98 opened 2 years ago
We already mentioned that the behaviour is similar to our filter
command in order to reduce the amount of duplicate content in our User Guide. This includes the requirement of name matching the entire word. If we mentioned it everywhere in the UG, it wouldn't be user-friendly and hard to read.
Team chose [response.Rejected
]
Reason for disagreement: I disagree because it is pretty difficult to navigate the UG (no links back to the table of content, etc). Most of my time was spent scrolling the document, not actually finding bugs.
Also, I think that unlike code with the DRY principle, it is actually better if things were repeated everywhere in a user guide because readers would usually prefer to go to only one single specific section and expect everything to be there especially with how difficult the UG was to navigate. It also would not be very user-friendly to need to go to a different section when they would have expected it within the same section still. It would be like when we are younger and we ask our father for permission to do something, but then he tells us to go ask our mother. Perhaps one exception is if the linked thing is describing something else, but in this case, the linked thing, filter
is also describing the behaviour of get
itself. Another exception is probably if it requires a long explanation, but in this case, that behaviour does not need a lot, just a few lines.
The UG says that the personal details whose name contains the given NAME will be shown. However, it does not mention the fact that it must be a match for an entire word.
For example, searching with parameter n/lex does not result in showing Alex Yeoh's details even though "Alex Yeoh" contains "lex". Actually, if you intended to do this, then actually this would be a functionality bug.
I put this as low because people may initially use this wrongly due to the inaccurate or lack of documentation of this behaviour.