Skip to content

Latest commit

 

History

History
121 lines (97 loc) · 3.96 KB

CONTRIBUTING.md

File metadata and controls

121 lines (97 loc) · 3.96 KB
Raw

Contributing

  1. Please sign one of the contributor license agreements below!
  2. Fork the repo, develop and test your code changes, add docs.
  3. Make sure that your commit messages clearly describe the changes.
  4. Send a pull request.

Table of contents

Community Guidelines

This project follows Google's Open Source Community Guidelines.

Contributor License Agreement

Contributions to this project must be accompanied by a Contributor License Agreement. You (or your employer) retain the copyright to your contribution; this simply gives us permission to use and redistribute your contributions as part of the project. Head over to https://cla.developers.google.com/ to see your current agreements on file or to sign a new one.

You generally only need to submit a CLA once, so if you've already submitted one (even if it was for a different project), you probably don't need to do it again.

Opening an issue

If you find a bug in the proxy code or an inaccuracy in the documentation, please open an issue. GitHub provides a guide, Mastering Issues, that is useful if you are unfamiliar with the process. Here are the specific steps for opening an issue:

  1. Go to the project issues page on GitHub.
  2. Click the green New Issue button located in the upper right corner.
  3. In the title field, write a single phrase that identifies your issue.
  4. In the main editor, describe your issue.
  5. Click the submit button.

Thank you. We will do our best to triage your issue within one business day, and attempt to categorize your issues with an estimate of the priority and issue type. We will try to respond with regular updates based on its priority:

  • Critical respond and update daily, resolve with a week
  • High respond and update weekly, resolve within six weeks
  • Medium respond and update every three months, best effort resolution
  • Low respond and update every six months, best effort resolution

The priority we assign will be roughly a function of the number of users we expect to be impacted, as well as its severity. As a rule of thumb:

Severity Number of users
Handful Some Most All
Easy, obvious workaround Low Low Medium High
Non-obvious workaround available Low Medium High Critical
Functionality blocked High High Critical Critical

Running tests

The test suite contains both unit tests and integration tests. Integration tests are skipped by default. To run only unit tests, run

mvn clean verify

Note: The unit tests currently fail to run on Mac OS. Pull Requests will run these tests and as a result they may be skipped locally if necessary.

Before running integration tests, it is necessary to set some environment variables for database credentials. A sample .envrc.example file is included in the root directory which documents which environment variables must be set to run the integration tests. Copy this example file to .envrc at the root of the project, supply all the correct values for each variable, source the file (source .envrc, or consider using [direnv][]), and then run:

mvn clean verify -P e2e

Code Reviews

All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Consult GitHub Help for more information on using pull requests.