-
Notifications
You must be signed in to change notification settings - Fork 494
Pull Requests workflow & guidelines
Stella Rouzi edited this page Mar 29, 2017
·
1 revision
Please open a pull request (PR) only when you have finished coding, and your changes are ready to be reviewed for merging.
- It should include a comprehensive title about what the pull request is doing
- It should not reference issue number on the PR title, as this is not giving any information about what this PR is about
- It should be short, max 50 characters
- It should include a couple of lines about the problem you are trying to solve and how you have addressed it
- It can have bullet points about the new things you are introducing, if applicable
- It should reference the issue(s) you are addressing
- It should have a screenshot of your change, if you are working on something that changes how the app looks like
- We automatically run the test suite and security checks on every PR
- Check back later to see if all checks were successful, if not, address them or leave a comment to ask for help
- Always add new commits; this tremendously helps reviewers
- Do not squash commits, unless explicitly requested by the reviewer
- Make sure you check the status of your PR regularly
- Address your reviews, make the necessary changes, ask if something is not clear to you
- Rebase against newest changes, whenever needed; we cannot properly review PRs that are not rebased
One of the maintainers will review your code and will leave comments and/or a review. Please ask if something is unclear, if you don't understand what is asked of you, of if you are uncertain of why the suggested approach might be better.
Reviewing your PR might take some time, as we are all volunteers. Please be respectful, and responsive.