malept/thermite

# Contributing to Thermite

Thermite is a part of the Rust ecosystem. As such, all contributions to this project follow the
[Rust language's code of conduct](https://www.rust-lang.org/conduct.html) where appropriate.

This project is hosted at [GitHub](https://github.com/malept/thermite). Both pull requests and
issues of many different kinds are accepted.

## Filing Issues

Issues include bugs, questions, feedback, and feature requests. Before you file a new issue, please
make sure that your issue has not already been filed by someone else.

### Filing Bugs

When filing a bug, please include the following information:

* Operating system and version. If on Linux, please also include the distribution name.
* System architecture. Examples include: x86-64, x86, and ARMv7.
* Ruby and Rake versions that run Thermite.
* The version (and/or git revision) of Thermite.
* If it's an error related to Rust, the version of Rust, Cargo, and how you installed it.
* A detailed list of steps to reproduce the bug. A minimal testcase would be very helpful,
  if possible.
* If there are any error messages in the console, copying them in the bug summary will be
  very helpful.

## Filing Pull Requests

Here are some things to keep in mind as you file a pull request to fix a bug, add a new feature,
etc.:

* Travis CI is used to make sure that the project conforms to the coding standards.
* If your PR changes the behavior of an existing feature, or adds a new feature, please add/edit
  the RDoc inline documentation (using the Markdown format). You can see what it looks like in the
  rendered documentation by running `bundle exec rake rdoc`.
* Please ensure that your changes follow the Rubocop-enforced coding standard, by running
  `bundle exec rake rubocop`.
* If you are contributing a nontrivial change, please add an entry to `NEWS.md`. The format is
  similar to the one described at [Keep a Changelog](http://keepachangelog.com/).
* Please make sure your commits are rebased onto the latest commit in the master branch, and that
  you limit/squash the number of commits created to a "feature"-level. For instance:

bad:

```
commit 1: add foo
commit 2: run rubocop
commit 3: add test
commit 4: add docs
commit 5: add bar
commit 6: add test + docs
```

good:

```
commit 1: add foo
commit 2: add bar
```

Squashing commits during discussion of the pull request is almost always unnecessary, and makes it
more difficult for both the submitters and reviewers to understand what changed in between comments.
However, rebasing is encouraged when practical, particularly when there's a merge conflict.

If you are continuing the work of another person's PR and need to rebase/squash, please retain the
attribution of the original author(s) and continue the work in subsequent commits.