Any contribution and work taking place in this repository is expected to follow the rules defined by our code of conduct. Please make sure to read and understand it.
To report an issue, please open a GitHub issue in this repository. We accept issues pertaining to the following aspects:
- The OpenAPI specification defined here – missing fields or endpoints, incorrect types, etc…
- The documentation generator (anything under the
codegen/
repository) - The various parts of the API documentation: structure, typos, etc…
- The setup of the website
- The tooling used throughout the repository
- Requesting for endpoints to be made public or for payloads to be augmented with certain fields
Specifically, please avoid opening issues pertaining to the Strava API agreement or the brand guidelines, or to report bugs or issues pertaining to the Swagger/OpenAPI tooling itself.
Please do not comment on an issue with a simple '+1' or 'me too' — use GitHub reactions on the original report to show your support.
Before doing any work that you seek to contribute back, please make sure to open a GitHub issue in this repository so that the work can be better tracked and possibly assigned. If you plan on working on an issue, leave a comment to that effect.
To propose a change:
- Fork this repository into your own workspace
- Make the changes needed and commit them to your fork. Make reference to the issue you worked on in your commit message. We don't enforce strict guidelines for title and commit messages but consider:
- Presenting the context of your change
- Explaining the caveats of your implementation, if any
- If your change makes a functional impact to any models or endpoints, create a changelog entry
- Open a GitHub Pull Request targeting the
master
branch. - Wait for a review from an administrator of the repository.
- If any further change is requested, please submit them as fixup commits in Git, e.g.
git commit --fixup HEAD
. Read more about fixup commits here. Unless required, avoid rebasing your branch ontomaster
during the review.
If you've made changes to the API specification, we have a small test suite that can validate that your changes do not break existing functionality. The suite generates a Java client, compiles the client, and runs some simple tests. You can (and should) run the test locally:
$ docker-compose build --no-cache
$ docker-compose run specs compile
$ docker-compose run specs test <your_access_token>
You can find your access token on your API settings page ('Your Access Token'). Please use your own token to run these tests.