Thank you for thinking about contributing to repo2docker!
This is an open source project that is developed and maintained entirely by volunteers.
*Your contribution* is integral to the future of the project.
THANK YOU!
## Types of contribution
There are many ways to contribute to repo2docker:
* **Update the documentation.**
If you're reading a page or docstring and it doesn't make sense (or doesn't exist!), please let us know by opening a bug report.
It's even more amazing if you can give us a suggested change.
* **Fix bugs or add requested features.**
Have a look through the [issue tracker](https://github.com/jupyter/repo2docker/issues) and see if there are any tagged as ["help wanted"](https://github.com/jupyter/repo2docker/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22).
As the label suggests, we'd love your help!
* **Report a bug.**
If repo2docker isn't doing what you thought it would do then open a [bug report](https://github.com/jupyter/repo2docker/issues/new?template=bug_report.md).
That issue template will ask you a few questions described in more detail below.
* **Suggest a new feature.**
We know that there are lots of ways to extend repo2docker!
If you're interested in adding a feature then please open a [feature request](https://github.com/jupyter/repo2docker/issues/new?template=feature_request.md).
That issue template will ask you a few questions described in detail below.
As we said above, repo2docker is built by and for its community.
If you know anyone who would like to use repo2docker, please tell them about the project!
You could give a talk about it, or run a demonstration.
The sky is the limit :rocket::star2:.
If you're not sure where to get started, then please come and say hello in our [Gitter channel](https://gitter.im/jupyterhub/binder), or open an discussion thread at the [Jupyter discourse forum](https://discourse.jupyter.org/).
**Bug reports** ([examples](https://github.com/jupyter/repo2docker/issues?q=is%3Aissue+is%3Aopen+label%3Abug), [new issue](https://github.com/jupyter/repo2docker/issues/new?template=bug_report.md)) will ask you for a description of the problem, the expected behaviour, the actual behaviour, how to reproduce the problem, and your personal set up.
Bugs can include problems with the documentation, or code not running as expected.
**Feature requests** ([examples](https://github.com/jupyter/repo2docker/labels/needs%3A%20discussion), [new issue](https://github.com/jupyter/repo2docker/issues/new?template=feature_request.md)) will ask you for the proposed change, any alternatives that you have considered, a description of who would use this feature, and a best-guess of how much work it will take and what skills are required to accomplish.
Very easy feature requests might be updates to the documentation to clarify steps for new users.
Harder feature requests may be to add new functionality to the project and will need more in depth discussion about who can complete and maintain the work.
Feature requests are a great opportunity for you to advocate for the use case you're suggesting.
They help others understand how much effort it would be to integrate the work,and - if you're successful at convincing them that this effort is worth it - make it more likely that they to choose to work on it with you.
7. (optional) Deploy a new version of repo2docker to mybinder.org by [following these steps](http://mybinder-sre.readthedocs.io/en/latest/deployment/how.html)
These are not hard rules to be enforced by 🚓 but they are suggestions written by the repo2docker maintainers to make getting your contribution completed a smooth process for you and for them.
* **Create a PR as early as possible**, marking it with `[WIP]` while you work on it.
This avoids duplicated work, lets you get high level feedback on functionality or API changes, and/or helps find collaborators to work with you.
* **Keep your PR focused.**
The best PRs solve one problem.
If you end up changing multiple things, please open separate PRs for the different conceptual changes.
* **Apply [PEP8](https://www.python.org/dev/peps/pep-0008/)** as much as possible, but not too much.
If in doubt, ask.
* **Use merge commits** instead of merge-by-squashing/-rebasing.
This makes it easier to find all changes since the last deployment `git log --merges --pretty=format:"%h %<(10,trunc)%an %<(15)%ar %s" <deployed-revision>..` and your PR easier to review.
* **Make it clear when your PR is ready for review.**
Prefix the title of your pull request (PR) with `[MRG]` if the contribution is complete and should be subjected to a detailed review.
* **Enter your changes into the [changelog](./../../changelog)** in `docs/source/changelog.rst`.
* **Use commit messages to describe _why_ you are proposing the changes you are proposing.**
* **Try to not rush changes** (the definition of rush depends on how big your changes are).
Remember that everyone in the repo2docker team is a volunteer and we can not (nor would we want to) control their time or interests.