Merge pull request #52 from mixmaxhq/update-pr-repo

chore(github): updates PR template

.github/pull_request_template.md

@@ -1,11 +1,65 @@
-#### Changes Made
+<!-- Author/Reviewer expectations are described in the last comment -->
 
-#### Potential Risks
-<!--- What can go wrong with this change? How will these changes affect adjacent code/features? How will we handle any adverse issues? --->
+> **Note** - Since this is a public repository, make sure that we're not publishing private data in the code, commit comments, or this PR.
 
-#### Test Plan
-<!--- How do we know this PR does what it's supposed to do? How do we ensure that adjacent code/features are still working? How do we evaluate the performance implications of this PR?--->
+## 📚 Context/Description Behind The Change
+<!--
+  What changes have you made to the code, and why?
 
-#### Checklist
-- [ ] I've increased test coverage
-- [ ] Since this is a public repository, I've checked I'm not publishing private data in the code, commit comments, or this PR.
+  As skilled engineers, we all know how to read and interpret code, so take this opportunity
+  to be a bit more verbal about your changes.
+
+  Giving the context behind your changes will make your PR review quicker,
+  as the reviewer will not need to guess your intent.
+-->
+
+## 🚨 Potential Risks & What To Monitor After Deployment
+<!--
+  What can go wrong with this deploy?
+  Does it touch any critical services?
+  How will these changes affect adjacent code/features?
+  How will we handle any adverse issues?
+-->
+
+## 🧑‍🔬 How Has This Been Tested?
+<!--
+  Imagine: How do I (and the Reviewer):
+  How do we know this PR does what it's supposed to do?
+  How do we ensure that adjacent code/features are still working?
+  How do we evaluate the performance implications of this PR?
+-->
+
+## 🚚 Release Plan
+<!--
+  Imagine: If you had to leave in a rush, what should the backup engineer do to deploy this?
+
+  Add any tasks that need to be done before/during/after release (i.e, creating indices, deploying
+  other services, bumping modules, notifying PM or other engineers, etc).
+-->
+
+
+
+<!--
+  ## 🤝 Expectations
+
+  When Opening/Reviewing a PR, please keep in mind:
+
+  ### As the PR Author
+  - Provide all the necessary context on "Why" you have performed your changes
+  - Assume that the reviewer has no previous knowledge about the codebase: would he/she be able to
+    review it the way it is right now?
+  - If changes are extensive, break them into smaller commits that tell a story, instead of 1 commit
+    with 15 files changed.
+  - Split Refactors and New-Code-Changes into different commits, ideally: different PRs.
+  - Test your code before requesting review — unless some rare exceptions, we shouldn't ship any code
+    without testing it before.
+  - If your PR is UI related, consider adding screenshots/videos with the behavior and before/after.
+
+  ### As the PR Reviewer
+  - Be kind. Don't nitpick.
+  - Expect to have all the necessary context to review the PR on (or linked on) the PR itself.
+  - When in doubt: ask.
+  - Validate if the author's tests have any missing coverage points. Do not approve an untested PR.
+  - Pay extra attention to the "Potential Risks" and "Release Plan" sections.
+  - If the PR alters the product UI, consider checking out the branch to visually inspect it.
+-->