Making a pull request

Step-by-step

Does your bug fix or feature have a corresponding GitHub issue? If not, open one!
Find the target branch:
- bug fix: goes into the latest release branch, e.g. release_v0.12.3.
- feature: goes into the develop branch

Check out the correct branch locally:

git checkout release_vX.Y.Z
git pull origin release_vX.Y.Z

Create a new issue branch using the following naming convention:
```
git checkout -b issue_1234_short_description_of_issue
```
Add your changes and commit them to your issue branch.
- If it's a bug fix add a test
- If it's a new feature, document it and add tests!
When you're ready, push your local branch to your fork
```
git push fork issue_1234_short_description_of_issue
```
- In order to enable the automatic integration tests directly on your fork, simply register on Travis and add your repository
Create a pull request on GitHub from the branch in your fork to the correct branch of aiidateam/aiida_core
- Open your pull request only once you believe your changes are ready to be merged.
  If you keep pushing changes to an open PR, developers are flooded with emails.
- Use the PR title to describe its contents (bad: "Fix issue 1234", good: "quicksetup now works without sudo")
- Mention the issue number in the description of the PR
If any of the automatic integration tests fail, fix them until you get the green check mark.
Developers will now start reviewing your PR.

All PRs undergo continuous integration testing using Travis. In order to pass, your PR needs to:

pass the pre-commit checks, including coding style and static analysis
pass all aiida tests
- using the django and sqlalchemy database backends
- on python2.7 and python3.6
build the documentation without warnings

On top of this, developers may ask you to document and test added functionality.