teamcapybara--capybara/CONTRIBUTING.md

52 lines
1.9 KiB
Markdown

## 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