# Being a good steward as an MR/PR author > ⚠️ If you are a CyberArk employee, refer to [Reviews in the cert-manager team](https://venafi.atlassian.net/wiki/spaces/TPFK/pages/3445129226) instead. These guidelines are intended to make your Merge Requests (MRs) and Pull Requests (PRs) easier to review as well and making the reviewer want to review your work. A good MR/PR author does not just “drop code”; they communicate the problem, the reasoning, and the confidence they have in their changes. We have five guidelines: - Explain Why - Be Mindful With The How - Self-Review Before Asking Others - Show Proof for Acceptance Criteria - Reproducible Tests ## 1. Always explain the "Why" Clearly state why this MR/PR is needed. - Why do customers need this change? - Why do we as a team need this? Do not force the reviewer to go read the Jira ticket or external documentation. The MR/PR should stand on its own. ✅ Example: > “This fixes an issue where cert-manager fails to renew certificates when DNS-01 providers return a temporary failure. This is important because customers experience outages when….” ❌ Avoid: > “Fixes VC-12345.” (with no further context) ## 2. Be Mindful With The How You don’t need to explain how** you fixed the bug or implemented the feature if the design is obvious from the code. Only include details of "how" if: - The implementation is not straightforward, or - You took a non-obvious design decision that may not be clear during code review. ## 3. Self-Review Before Asking Others Perform a self-review of your MR/PR. To do that, open your MR on GitLab or PR on GitHub and walk through your own changes as if you were the reviewer to catch obvious mistakes before others do. To do that, you can use tools like GitHub Copilot, but also leave comments in your own MR where things are tricky, so reviewers know you already considered them. ## 4. Provide Proof for Acceptance Criteria Reviewers should not have to guess whether acceptance criteria are met. Always provide proof: - Screenshots for UI changes. - Logs for backend behavior. This reduces back-and-forth and shows you have verified your own work. ## 5. Reproducible Tests Even if the testing effort was small, always include a "Testing" section in your MR/PR description. Use it to: - Show what you did to gain confidence (unit tests, manual tests, end-to-end tests, etc.). - Include evidence of that testing (screenshots, screencasts, local commands and logs you ran if manually tested. - If the testing is tricky, explain your decision process: why did you not create a test? Why did you not automate it? ✅ Example: ```markdown ### Testing - Manually deployed on a local k3d cluster with Let’s Encrypt staging. - Ran `kubectl describe challenge` and verified status transitions. - Added a new unit test for the retry logic. - Screenshot attached of successful renewal. ```