nus-se-bot
commented
4 months ago Team's Response
Duplicate as the bug refers to formatting of bullet points at the section level of the DG, which is the same as 983.
We are unsure what the problem is with our style of formatting the bullet points. We are also not sure of what consistent formatting the points mean, let alone what benefit it would bring. Do you mean the hierarchy of the bullet points within each sections, or syncing hierarchies between all chapters?
Regardless, as per current formatting of instructions for manual testing, the type of bullet point used does not seem to hinder the user's ability to understand the section at all. Bullet point formatting is only cosmetic, and whether it is a cosmetic problem is questionable.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
the developer guide could benefit from the same formatting for implementation and rationale for differing sections
Note from the teaching team: This bug was reported during the Part II (Evaluating Documents) stage of the PE. You may reject this bug if it is not related to the quality of documentation.
[original: nus-cs2113-AY2324S2/pe-interim#897] [original labels: severity.Low type.DocumentationBug]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
We believe this bug refers to formatting of bullet points at the section level of the DG.
We are unsure what the problem is with our style of formatting the bullet points. We are also not sure of what "same formatting" of the points mean, let alone what benefit it would bring. Do you mean the hierarchy of the bullet points within each section, or making the hierarchies consistent for implementation and rationale between all chapters?
Regardless, as per current formatting of instructions for manual testing, the type of bullet point used does not seem to hinder the user's ability to understand the section at all. Bullet point formatting is only cosmetic, and whether it is a cosmetic problem is questionable.
The aforementioned documentation style seems to be a non-issue, due to the fact that the DG for the different components have vastly different usages, plus each bullet point in the first screenshot has in fact multiple methods associated with the same system checks.
Lastly, reading the rationale behind these checks does not hinder the user from understanding what these checks are doing. While they may look slightly different with slightly different formatting, reading the rationale for that associated implementation does not in fact cause the user to not understand what it means.
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)
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
## :question: Issue response Team chose [`response.IssueUnclear`] - [x] I disagree **Reason for disagreement:** It improves the overall readability and professionalism of the developer guide.
The numbering for Non-Functional Requirements goes from 1. to a circled bullet point. while the numbering for the next section goes from 1. to i.