CONTRIBUTING.md
# Contribution guidelines #
[](https://gitter.im/cristim/autospotting)
The usual GitHub contribution model applies, but if you would like to [raise an
issue](https://github.com/AutoSpotting/AutoSpotting/issues/new) or start working
on a [pull request](https://github.com/AutoSpotting/AutoSpotting/pulls), please
get in touch on [gitter](https://gitter.im/cristim/autospotting) to discuss it
first so we make sure everything is clear and that nobody else is already
working on it.
Any random questions are also better asked there.
## Feature requests ##
The use case should be presented in detail in the issue, and should also
be discussed on gitter to make sure nothing was lost in translation.
## Bug reports ##
Bug reports should contain enough details to be reproduced by a developer.
The commonly required information is already pre-filled when creating any GitHub
issue, but be prepared to provide more when asked, either in the issue comments
or on gitter.
## Pull requests ##
Pull requests will need to pass code review by the project maintainers before
they can be merged, in order to ensure the high quality of the software and the
maintainability of the codebase.
As part of the review process the maintainers will often just verify that the
patch meets the requirements listed in the pull request
[checklist](.github/PULL_REQUEST_TEMPLATE.md), but they may also suggest other
changes deemed appropriate.
Anyone is more than welcome to review the content of any issues labelled as
'review wanted', but only project maintainers can approve reviews for being
merged.
You can usually make the process faster by submitting smaller changes, larger
reviews can also be sped up by asking for review on Gitter, we try to be as
responsive as possible, but be prepared to iterate your pull request a number of
times until it is ready to be approved. This may take a while for big
contributions, so don't be discouraged if this may take longer than you
initially expected.
You can submit iterations as additional commits to make the review process
easier, but the reviewer may squash them into a single big commit at merge time,
in order to clean up the mainline commit history.