We love pull requests from everyone!
We encourage community contributions for all kinds of changes both big and small, but we ask that you adhere to the following guidelines for contributing code.
As a starting point for all changes, we recommend reporting an issue before you begin making any changes. Make sure to search the issues on this repository first to check and see the issue has already been previously discussed and whether or not it's already being worked on.
For small changes, improvements and bug fixes please feel free to send us a pull request with proposed changes along-side the issue you report.
For larger more involved or design related changes, please open an issue and discuss the changes with the other contributors before submitting any pull requests.
Submitting A Pull Request
- Fork us and clone the repository locally.
git clone firstname.lastname@example.org:twitterdev/twitter-ruby-ads-sdk.git
- Install development dependencies:
# install bundler (if you don't have it already) gem install bundler # install all development dependencies bundle install
- Make sure all tests pass before you start:
Make your changes! (Don't forget tests and documentation)
Test your changes again and make sure everything passes:
- Submit your changes!
- Squash your development commits. Put features in a single clean commit whenever possible or logically split it into a few commits (no development commits). Test coverage can be included in a separate commit if preferred.
- Write a good commit message for your change.
- Push to your fork.
- Submit a pull request.
We try to at least comment on pull requests within one business day and may suggest changes.
Release Schedule and Versioning
We have a regular release cadence and adhere to semantic versioning. When exactly your change ships will depend on the scope of your changes and what type of upcoming release its best suited for.