From 81c8481fe6b0394cc9d2cef9d9d4af573ef0b0d1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Aneta=20=C5=A0teflov=C3=A1=20Petrov=C3=A1?= Date: Mon, 22 Sep 2025 17:13:30 +0200 Subject: [PATCH 1/4] Review PR checklist --- CONTRIBUTING.md | 33 +++++++++++++++++++-------------- 1 file changed, 19 insertions(+), 14 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8970460dbef..863bd3802fa 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -20,28 +20,33 @@ As a maintainer, I will: Examples of trivial PRs: Fixing a typo, fixing markup, or fixing links. Non-trivial PRs might not only benefit from additional review but they also represent an opportunity for community members to ask questions and learn. -## Pull request checklist +## Pull request checklists + +* [ ] My contribution is my own work and I agree to the license of the project. +See [LICENSE](LICENSE). +* [ ] My commits include meaningful commit messages. +See [seven rules for git commit messages](https://cbea.ms/git-commit/#seven-rules). +* [ ] I write one sentence per line. +See [One sentence per line](https://jeffkreeftmeijer.com/one-sentence-per-line/). +* [ ] My change does not add trailing whitespaces. +Some editors can help with this. +For example, VS Code has multiple settings related to handling whitespaces. +* [ ] My change does not worsen the state of any build target. +* [ ] I re-read my work carefully before raising a PR or before marking a draft PR as ready for review. +This can include using `git show`, viewing the diff against master or the target branch, running a local Vale check, and other methods. +* [ ] My PR description includes a meaningful description of the changes for the community. +* [ ] I fill out the cherry-picking list in the PR description to the best of my abilities to signify which versions my update applies to. +If unsure, I let reviewers know so that they can assist. +* [ ] Before pinging others about my PR, I await the GitHub Actions checks to see if my branch builds. +If a GitHub check fails and I'm unsure how to proceed, I let reviewers know so that they can assist. -* [ ] Before pushing, I view my diff against master or the target branch and check for spelling mistakes, failed conflict resolutions, etc. -* [ ] Before pinging others about my PR, I await the Github Actions to see if my branch builds. * [ ] If I add text that applies only to a specific downstream product, I notify others and give them a chance to request extending the `ifdef::[]` or `ifndef::[]` directive. * [ ] My change does not contain `Foreman`, `Satellite`, or `orcharhino`. Instead, I use attributes. -* [ ] I don't add useless or trailing white space. -* [ ] I put each sentence to its own line. -* [ ] I write a meaningful commit message. -See [seven rules for git commit messages](https://cbea.ms/git-commit/#seven-rules). -* [ ] My change does not worsen the state of any build target. -* [ ] My contribution is my own work and I agree to the license of the project. -See [LICENSE](LICENSE). * [ ] If I make more than one change on my branch, I create more than one commit and rebase my branch to master. -* [ ] My PR does not solely rely on internal resources to answer the _why_, but instead contains at least a basic description for the community. -* [ ] When creating my PR, I select all branches I want my change to get cherry-picked to. * [ ] I am familiar to proper capitalization for project-specific terminology. See [Capitalization](#Capitalization). * [ ] The first line of the file contains the modular docs content type attribute, for example, `:_mod-docs-content-type: ASSEMBLY` for assemblies. -* [ ] I fill out the cherry-picking list in the PR template to the best of my abilities to signify which versions my update applies to. -If unsure, I let reviewers know so that they can assist. Each PR should undergo tech review. (Tech review is performed by an Engineer who did not author the PR. It can be skipped if the PR does not significantly change description of product behavior.) From 32dca69d5beaa227488bb60892923e4bd4ce1c4a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Aneta=20=C5=A0teflov=C3=A1=20Petrov=C3=A1?= Date: Tue, 23 Sep 2025 11:21:03 +0200 Subject: [PATCH 2/4] Remove PR checklist items that are obsolete or duplicate other parts of the guidelines --- CONTRIBUTING.md | 8 -------- 1 file changed, 8 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 863bd3802fa..88eb065e0e7 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -40,14 +40,6 @@ If unsure, I let reviewers know so that they can assist. * [ ] Before pinging others about my PR, I await the GitHub Actions checks to see if my branch builds. If a GitHub check fails and I'm unsure how to proceed, I let reviewers know so that they can assist. -* [ ] If I add text that applies only to a specific downstream product, I notify others and give them a chance to request extending the `ifdef::[]` or `ifndef::[]` directive. -* [ ] My change does not contain `Foreman`, `Satellite`, or `orcharhino`. -Instead, I use attributes. -* [ ] If I make more than one change on my branch, I create more than one commit and rebase my branch to master. -* [ ] I am familiar to proper capitalization for project-specific terminology. -See [Capitalization](#Capitalization). -* [ ] The first line of the file contains the modular docs content type attribute, for example, `:_mod-docs-content-type: ASSEMBLY` for assemblies. - Each PR should undergo tech review. (Tech review is performed by an Engineer who did not author the PR. It can be skipped if the PR does not significantly change description of product behavior.) From 14a94bfe9e146a180175e2c2178436f566f64c2a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Aneta=20=C5=A0teflov=C3=A1=20Petrov=C3=A1?= Date: Tue, 23 Sep 2025 11:21:34 +0200 Subject: [PATCH 3/4] Add headings to PR checklist --- CONTRIBUTING.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 88eb065e0e7..988d431bf16 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -22,6 +22,8 @@ Non-trivial PRs might not only benefit from additional review but they also repr ## Pull request checklists +Checklist for documentation contributions: + * [ ] My contribution is my own work and I agree to the license of the project. See [LICENSE](LICENSE). * [ ] My commits include meaningful commit messages. @@ -32,6 +34,9 @@ See [One sentence per line](https://jeffkreeftmeijer.com/one-sentence-per-line/) Some editors can help with this. For example, VS Code has multiple settings related to handling whitespaces. * [ ] My change does not worsen the state of any build target. + +Checklist for raising PRs: + * [ ] I re-read my work carefully before raising a PR or before marking a draft PR as ready for review. This can include using `git show`, viewing the diff against master or the target branch, running a local Vale check, and other methods. * [ ] My PR description includes a meaningful description of the changes for the community. From be05015e72bc59d41f7ab6ed1fcbeef3b761bfd5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Aneta=20=C5=A0teflov=C3=A1=20Petrov=C3=A1?= Date: Tue, 23 Sep 2025 12:29:19 +0200 Subject: [PATCH 4/4] Move a PR checklist item to 'contributor's pledge' This is because this item should be on a contributor's mind permanently rather than something they have to remember before raising each PR. --- CONTRIBUTING.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 988d431bf16..114f1290bad 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -8,6 +8,8 @@ As a contributor, I will: * Familiarize myself with the [Pull Request Checklist](#Pull-Request-Checklist) and [Foreman documentation minimalist style guide](#Foreman-documentation-minimalist-style-guide). * Open additional issues if my contribution is incomplete. +* Put in my best effort to ensure that my contribution does not worsen the state of any build target. +For example, this might include reviewing how my changes affect upstream build targets even when working on behalf of a downstream product. ## Maintainer's pledge @@ -33,7 +35,6 @@ See [One sentence per line](https://jeffkreeftmeijer.com/one-sentence-per-line/) * [ ] My change does not add trailing whitespaces. Some editors can help with this. For example, VS Code has multiple settings related to handling whitespaces. -* [ ] My change does not worsen the state of any build target. Checklist for raising PRs: