## Questions about Capybara?

To get your questions answered, please ask on the [mailing list]. Do not open
an issue.

## Bug Reports

If you are at all unsure whether it's a bug in Capybara or a problem with your
code, post on the [mailing list] instead. If it turns out that it is a bug, we
can always open an issue later.

If you are sure that it's a bug in Capybara, open a new [issue] and try to
answer the following questions:

- What did you do?
- What did you expect to happen?
- What happened instead?

Please also post code to replicate the bug. Ideally a failing test would be
perfect, but even a simple script demonstrating the error would suffice. You
could use [this template](https://gist.github.com/jnicklas/5137053) as a
starting point. Please don't send us an entire application, unless the bug is
in the *interaction* between Capybara and a particular framework.

Make sure to specify which version of Capybara you are using.

Feature requests are great, but they usually end up lying around the issue
tracker indefinitely. Sending a pull request is a much better way of getting a
particular feature into Capybara.

## Pull Requests

- **Add tests!** Your patch won't be accepted if it doesn't have tests.

- **Document any change in behaviour**. Make sure the README and any other
  relevant documentation are kept up-to-date.

- **Consider our release cycle**. We try to follow semver. Randomly breaking
  public APIs is not an option.

- **Create topic branches**. Don't ask us to pull from your master branch.

- **One pull request per feature**. If you want to do more than one thing, send
  multiple pull requests.

- **Send coherent history**. Make sure each individual commit in your pull
  request is meaningful. If you had to make multiple intermediate commits while
  developing, please squash them before sending them to us.

[mailing list]: http://groups.google.com/group/ruby-capybara
[issue]: https://github.com/teamcapybara/capybara/issues