Skip to content

Latest commit

 

History

History
83 lines (56 loc) · 2.96 KB

CONTRIBUTING.rst

File metadata and controls

83 lines (56 loc) · 2.96 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-python-ads-sdk.git
  1. Install development dependencies (virtualenv recommended):
pip install -r requirements.txt
  1. Make sure all tests pass before you start:
python setup.py test
  1. Make your changes! (Don’t forget tests and documentation)
  2. Check style and test your changes again to make sure everything is green:
python setup.py flake8 && python setup.py test

The test suite will automatically enforce test coverage and code style. This project adhere’s fully to the PEP-8 style guide (100 character line length allowed) and we use Flake8 to enforce style and code quality.

  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.