# Contributing Guidelines

First, **thank you** for contributing!

Before starting, you should read, agree to, and follow these three points:

  - [How to contribute?](#how-to-contribute)
    - [Report bugs](#report-bugs)
    - [Submit feedback](#submit-feedback)
  - [Pull Request Guidelines](#pull-request-guidelines)
  - [Code of Conduct](CODE_OF_CONDUCT.md)

This page is largely inspired from a [blog post of William Durand](https://williamdurand.fr/2013/11/20/on-creating-pull-requests/).

---

## How to contribute?

### Report bugs

Report bugs at: https://github.com/patrickfuchs/buildH/issues/new.

When reporting a bug, please include:

* Any details about your local setup which might be helpful in troubleshooting
* Detailed steps to reproduce the bug. Where possible, please write a test case

If you are not able to do that, that's fine! Open an issue anyway and let us
know as much information as you can. We will get back to you to determine the
problem, and (hopefully) fix it.


### Submit feedback

The best way to send feedback is to [create a new
issue](https://github.com/patrickfuchs/buildH/issues/new) on GitHub.

If you are proposing a feature:

* Explain how you see it working. Try to be as detailed as you can.
* Try to keep the scope as narrow as possible. This will help make it easier to
  implement.
* Feel free to include any code you might already have, even if it is
  just a rough idea. This is a volunteer-driven project, and contributions are
  welcome :)


## Pull Request Guidelines

Here are a few rules to follow in order to make code reviews and discussions go
more smoothly before maintainers accept and merge your work:

* You MUST run the test suite.
* You MUST write (or update) unit tests.
* You SHOULD write documentation.

Please, write [commit messages that make
sense](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html),
and [rebase your branch](http://git-scm.com/book/en/Git-Branching-Rebasing)
before submitting your Pull Request.

You may be asked to [squash your
commits](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html)
too. This is to "clean" your Pull Request before merging it (we try to avoid
commits such as `fix tests`, `fix 2`, `fix 3`, etc.).

Also, while creating your Pull Request on GitHub, you MUST write a description
which gives the context and/or explains why you are creating it.

For further information about creating a Pull Request, please read [this blog
post](http://williamdurand.fr/2013/11/20/on-creating-pull-requests/).

Thank you!