Pull Requests

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.

Be mindful about what you're trying to contribute and the type of contribution.

• Double-check Branching Conventionsand 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.

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)