|
| 1 | +# PR Review Guidelines |
| 2 | + |
| 3 | +Use these guidelines when reviewing pull requests for this documentation repository. |
| 4 | + |
| 5 | +## Priorities |
| 6 | + |
| 7 | +- First look for changes that can break rendered documentation: malformed Markdown, Hugo |
| 8 | + shortcodes, `tabpane` / `tab` pairs, code fences, front matter, anchors, or translated page |
| 9 | + structure. Small whitespace and delimiter changes can break code blocks or entire sections. |
| 10 | +- Treat `gh-codeblock` paths and line ranges as correctness-sensitive. If `examples/` changed, |
| 11 | + search `website_and_docs/content` for references to the changed files. If docs changed a |
| 12 | + `gh-codeblock`, verify the path still exists and the line range shows exactly the intended |
| 13 | + snippet. |
| 14 | +- Check translation maintenance against `website_and_docs/content/documentation/about/style.en.md`. |
| 15 | + English text changes do not require translated files in the same PR, but changed translation |
| 16 | + files must preserve working front matter, shortcodes, tabs, code blocks, and example references. |
| 17 | + When the style guide requires translated code examples, verify the matching translated files were |
| 18 | + updated. |
| 19 | +- For examples, review code correctness only as it affects the published docs: runnable snippets, |
| 20 | + assertions where practical, stable demo pages, and matching documentation references. |
| 21 | + |
| 22 | +## Documentation checks |
| 23 | + |
| 24 | +- Front matter should match the surrounding page style. |
| 25 | +- `linkTitle` should be short and title-cased; `title` should use sentence case. |
| 26 | +- General prose should be language-independent. Put binding-specific code or behavior in language |
| 27 | + tabs. |
| 28 | +- When all tabs use `gh-codeblock`, the `tabpane` should use `text=true`. When only some tabs use |
| 29 | + shortcodes or markdown, those tabs need `text=true`. |
| 30 | +- `gh-codeblock` lines must not be indented. Plain text in markdown tabs also must not be |
| 31 | + accidentally indented into a code block. |
| 32 | + |
| 33 | +## Do not comment on |
| 34 | + |
| 35 | +- Missing translated files for ordinary English text changes. |
| 36 | +- Subjective wording preferences unless the text is inaccurate, confusing, or inconsistent with |
| 37 | + the Selenium docs style guide. |
| 38 | +- Formatting nits that do not affect rendering, code block structure, shortcode parsing, or |
| 39 | + maintainability. |
| 40 | +- CI status without a clear connection to the diff. |
| 41 | + |
| 42 | +## Review style |
| 43 | + |
| 44 | +- Label severity as blocking, important, or minor. |
| 45 | +- Make each comment actionable: state the risk, why it matters, and the smallest fix. |
| 46 | +- Include file and line context when possible. |
| 47 | +- Do not leave duplicate comments for the same root cause. |
| 48 | +- It is acceptable to report no findings. |
0 commit comments