Open narwhalsilent opened 6 months ago
We believe that this is a cosmetic issue as there is no obvious problems when reading through.
e.g There should be no problem reading id then ID. We also mention this in this section of the UG. handphone and phone number are used interchangeably in real life, so there is no problem there as well. We are not using like office number and phone number separately.
Team chose [response.NotInScope
]
Reason for disagreement: I believe that it is essential to have a consistent format when referring to command syntax and parameters, because command syntax cannot be read like natural speech.
Instead, command parameters are in effect treated like special symbols which are unique and have no equivalents.
The group's UG also shows the team intended to refer to parameters with the exact same format as shown in command format, i.e. lowercase with brackets. In the following screenshot, it is exemplified by the phrase "(id)
is the parameter to be supplied by you".
Hence, in the screenshot in the original bug report when the team refers to "ID
", it could have been confusing as it is a different convention for the syntax of parameters.
I believe it would have been much more easily readable if the team stuck to this convention.
In command syntax, the parameter values are represented as
(something)
.However, when giving tips, the brackets are not kept, and the name of the parameters are changed. e.g.
(id)
toID
and(handphone)
tophone number
.This can confuse the reader.
Improvement: Standardise how parameters are referred to in UG.