Skip to content

Latest commit

 

History

History
77 lines (51 loc) · 2.63 KB

CONTRIBUTING.md

File metadata and controls

77 lines (51 loc) · 2.63 KB
Raw

Contributing Guidelines

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.

Proposing Changes

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
  1. Fork us and clone the repository locally.
git clone [email protected]:twitterdev/twitter-ruby-ads-sdk.git
  1. Install development dependencies:
# install bundler (if you don't have it already)
gem install bundler

# install all development dependencies
bundle install
  1. Make sure all tests pass before you start:
rake

  1. Make your changes! (Don't forget tests and documentation)

  2. Test your changes again and make sure everything passes:

rake

The test suite will automatically enforce test coverage and code style. For the most part, we follow this community style guide with a few exceptions.

  1. 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.