Pull Requests
The diplomatic way to sneak your changes into main. WIP.
Just in case you forgot: Rebasing onto main before continuing work is the
secret to happiness.
Always simple rebase your branch onto main before creating a pull request. This ensures that your branch is up-to-date with the latest changes in the main branch. Branch and PR rules are set up for the repo just in case as a guardrail.
Do your best to close a single issue per pull request, and always use the same PR title as the issue name. This makes debugging easier later.
PRs that close multiple issues are generally only done by the core team in times of emergency.
Be mindful about what you're trying to contribute and the type of contribution.
- Double-check Branching Guidelines, Coding Guidelines and Commit Conventions before making a PR.
- Use the appropriate template that matches with your branch type.
- Ensure your PR scope and subject align with your commit(s).
- If your code isn’t fully ready to be merged, create a draft PR instead.
- Link PR branches with the according issue (if applicable).
- Ensure PR description is solution-specific (describe only the solution since the issue describes the problem at hand already).
If you're getting tired of storing work in progress by stashing changes or amending commits and then switching branches, it's a great sign to look into using Git Worktrees.
Here is an example of a detailed PR.
If your issue blows up and splitting it into multiple issues doesn't make sense, keep the issue open and make multiple PRs that complete it in increments, as shown in Issue #40.
Checklist
Code Quality
| Done | Checklist Item |
|---|---|
| Code is clean and readable (functions used appropriately) | |
| Code is commented appropriately (no unnecessary comments, follows guidelines) | |
| Code is DRY (no repeated code) | |
| Functions are named appropriately (camelCase) | |
| Variables are named appropriately (camelCase) | |
| Files are named appropriately (kebab-case) | |
| Code performs as expected (no errors or issues when running) | |
| Code is committed and branched accordingly |
Review Readiness
| Done | Checklist Item |
|---|---|
| Title is the same as relevant issue name (if applicable) | |
| Linked to relevant issue (if applicable) | |
| PR description follows template guidelines | |
| PR is clear, comprehensible, ready for review (if not, use a draft PR) |
What is a CODEOWNER?
Code owners are subject matter experts for specific areas of the codebase.
The relevant person automatically notified and requested to review changes when a pull request affects their area.
See our CODEOWNERS file below for more info: