We have a number of requirements for PRs to ensure they are as easy to review as possible and to ensure that they are up to standard with the code.
### Title & Content
Start by providing a short and concise title. Don’t put something generic (e.g. bug fixes), and instead mention more specifically what your PR achieves, for instance “Fixes dropdown not expanding on settings page”.
For the PR description, you should go into much greater detail about what your PR adds or fixes. Firstly, the description should include a link to any relevant issues or discussions surrounding the feature or bug that your PR addresses.
#### Feature PRs
Give a functional overview of how your feature works, including how the user can use the feature. Then, share any technical details in an overview of how the PR works (e.g. “Once the user enters their password, the password is hashed using BCrypt and stored in the Users database field”).
#### Bug Fix PRs
Give an overview of how your PR fixes the bug both as a high-level overview and a technical explanation of what caused the issue and how your PR resolves this.
Feel free to add a short video or screenshots of what your PR achieves. Loom is a great way of sharing short videos.
### Code Quality & Styling
All submitted code must match our [code styling](/docs/code-styling) standards. We will reject pull requests that differ significantly from our standardised code styles.
All code is automatically checked by Codacy and our linting process, and will notify you if there are any issues with the code that you submit. We require that code passes these quality checks before merging.
## PR review process
At least two members of the Calendso team should review and approve any PR before it is merged.
Once two members of the team have approved this, someone from the team will merge the PR. If you are part of the Calendso team, you should merge your own PRs once you have received both approvals.
