-
Notifications
You must be signed in to change notification settings - Fork 14
feat(styleguide): improvements #1417
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
base: main
Are you sure you want to change the base?
Conversation
|
To fix the formatting issues:
npx remark -o --silent --silently-ignore contribute/style-guide-extended.mdx contribute/style-guide.mdx |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No documentation issues detected.
contribute/style-guide-extended.mdx
Outdated
| ##### Italics | ||
|
|
||
| - Link text **MUST NOT** be styled with bold or italics. Do not wrap links in emphasis (for example, `**[Foo](/foo)**`, `_ [Foo](/foo)_`) and do not put bold or italic markup inside the link label. When the link label is a code identifier, use inline code as the label (for example, ``[`foo_bar`](/ref/foo_bar)``). (Why: links are already visually distinct; extra emphasis adds noise and makes scanning harder.) \[HIGH] | ||
| - Italics **MAY** be used for first‑mention term emphasis or titles of publications, books, papers, or standards. Avoid using italics for recurring emphasis in procedures. (Why: minimal, conventional italics aid comprehension without competing with steps.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
conventional italics aid comprehension without competing with steps
which steps?
contribute/style-guide-extended.mdx
Outdated
|
|
||
| - performs chain‑affecting operations (e.g., resharding, pruning, halting, replay). (Why: these actions can corrupt the state, reduce availability, or cause data loss.) \[HIGH] | ||
|
|
||
| - On pages with many such steps, you **MAY** combine these into a page‑level safety summary plus short local callouts for individual commands instead of repeating full details every time. (Why: a shared summary avoids repetition while still making risks visible near each step.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Steps?
contribute/style-guide-extended.mdx
Outdated
| ### 11.2 How to write the callout | ||
|
|
||
| A safety callout **MUST** include: (Why: readers need to know the risk, scope, recovery, and safe environment before proceeding.) \[HIGH] | ||
| A guide that contains safety‑critical steps **MUST** clearly communicate all of the following, either in a page‑level safety summary, in local callouts near each step, or in combination: (Why: readers need to know the risk, scope, recovery, and safe environment before proceeding.) \[HIGH] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Steps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the updates to contribute/style-guide-extended.mdx: there’s one inline suggestion to better align the new guidance with the existing style conventions. Please apply the inline suggestion.
closes #943