Skip to content

Latest commit

 

History

History
62 lines (44 loc) · 4.14 KB

CONTRIBUTING.md

File metadata and controls

62 lines (44 loc) · 4.14 KB
Raw

Contributing

How to contribute code

1. Decide what to work on

Then, tell folks what you'll be working on, and:

2. FORK this repo

Everyone must follow the rules below (inspired by the C4.1 process) to submit code (documentation may be edited directly by maintainers):

  1. Always work in your own fork (Note: it is OK for long-running contributors to work in a branch of this repo, because that is how we get Cypress Dashboard <-> Travis integraton) and submit pull requests (PRs) to master.
  2. Always add/update tests for any new/modified functionality. (:exclamation:)
  3. Always make sure your PR passes all tests (grunt test).
  4. Always ensure your PR adheres to the Contribution Policy described below.

3. Follow this Contribution Policy

This contribution policy will evolve over time. For now it is based on a slightly modified subset of C4.1.

Licensing and Ownership

  1. All contributions to the project source code ("patches" or "pull requests") SHALL use the same license as the project.
  2. All patches are owned by their authors. There SHALL NOT be any copyright assignment process.
  3. Each Contributor SHALL be responsible for identifying themselves in the project Contributor list.

Pull Request Requirements (:exclamation:)

  1. A PR SHOULD be a minimal and accurate answer to exactly one identified and agreed problem.
  2. A PR SHOULD follow the boy scout rule: leave the code cleaner than you found it when the refactor effort is not too big.
  3. A PR MAY NOT include non-trivial code from other projects unless the Contributor is the original author of that code.
  4. A PR MUST pass all tests on at least the principle target platform.
  5. A PR MUST include new tests for any new functionality introduced.
  6. A PR MUST follow the requirements spelled out in this project's Style Guide.
  7. A PR MUST receive approval from at least one long-term contributor before being merged. Contributors MAY NOT review their own PRs, MUST NOT push commits to someone else's PR, and SHOULD NOT merge their own PRs.
  8. A PR MUST receive approval from the designer when it's related to the user interface before being merged.
  9. A PR MAY NOT be merged if there exist unaddressed concerns from a current maintainer (via the Github "request changes" review feature). Contributors are encouraged to discuss the requested changes, and may even argue against them if there are strong reasons to do so. However, maintainers have veto power over all PRs.

How to help by translating

We always appreciate translation efforts, even if they're not perfect or complete! The instruction are here.

How to submit an issue