- Submit a ticket for your issue, assuming one does not already exist.
- Clearly describe the issue including steps to reproduce when it is a bug.
- Make sure you fill in the earliest version that you know has the issue.
- Create a topic branch from where you want to base your work.
- This is usually the master branch.
- Only target release branches if you are certain your fix must be on that branch.
- To quickly create a topic branch based on master;
git checkout -b fix/master/my_contribution master
. Please avoid working directly on themaster
branch.
- Make commits of logical units.
- Check for unnecessary whitespace with
git diff --check
before committing. - Make sure your commit messages are in the proper format.
(PEEL-1234) Make the example in CONTRIBUTING imperative and concrete
Without this patch applied the example commit message in the CONTRIBUTING
document is not a concrete example. This is a problem because the
contributor is left to imagine what the commit message should look like
based on a description rather than an example. This patch fixes the
problem by making the example concrete and imperative.
The first line is a real life imperative statement with a ticket number
from our issue tracker. The body describes the behavior without the patch,
why this is a problem, and how the patch fixes the problem when applied.
- Make sure you have added the necessary tests for your changes.
- Run all the tests to assure nothing else was accidentally broken.
- Push your changes to a topic branch in your fork of the repository.
- Submit a pull request to the repository.
- Update your ticket to mark that you have submitted code and are ready for it to be reviewed (Status: Ready for Merge).
- Include a link to the pull request in the ticket.
- The core team looks at Pull Requests on a regular basis
- After feedback has been given we expect responses within an hour.