Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

the developer guide could benefit from the same formatting for implementation and rationale for differing sections #13

Open
nikhil-2101 opened this issue Apr 19, 2024 · 1 comment

Comments

@nikhil-2101
Copy link
Owner

nikhil-2101 commented Apr 19, 2024

Screenshot (448).png

Screenshot (447).png

@nus-se-bot
Copy link

nus-se-bot commented Apr 23, 2024

Team's Response

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

❓ Issue response

Team chose [response.IssueUnclear]

  • I disagree

Reason for disagreement: The downgrade is fine but it should still be considered as an issue instead of being rejected.


❓ Issue severity

Team chose [severity.VeryLow]
Originally [severity.Low]

  • I disagree

Reason for disagreement: [replace this with your explanation]


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants