Skip to content

Latest commit

 

History

History
40 lines (27 loc) · 2.54 KB

CONTRIBUTING.md

File metadata and controls

40 lines (27 loc) · 2.54 KB

Contribution Guidelines

👍🎉 First off, thanks for taking the time to contribute! 🎉👍

This document proposes guidelines for contributing to the OpenWhyd repository.

The objectives of the guidelines are:

  • Make sure that contributing is an enjoyable experience, and that contributors are respected. (e.g. avoid endless discussions and flame wars)
  • Make sure that the quality of the codebase increases over time. (or at least remains stable)
  • Make sure that contributions solve more problems than they create. (e.g. a "fix" that was not tested properly will cause long discussions)
  • Make sure to not wasting other contributors' time.

These are just guidelines, not rules, use your best judgment and feel free to propose changes to this document in a pull request.

How to contribute

  1. Setup your environment to match prerequisites and nodejs/npm versions specified in package.json
  2. Clone openwhyd, and make sure it runs properly on your environment
  3. Make changes in the code, commit, send a Pull Request (PR)
  4. Wait for your PR to be reviewed and merged into the repository
  5. Be available to reply if a contributor gets involved in the reviewing process of your PR.

Acceptance criteria for Pull Requests (PR)

  • A PR must contain only one modification. Any PR with more than one independant modification will be rejected. (e.g. "cleaned .gitignore and added installation guide" are two independant PR)
  • A PR must solve an identified and immediate problem. Any PR that intends to solve a future problem will be rejected. (e.g. "added a rule for running tests", even though there are no tests yet in the project)
  • A PR must be tested on the same environment as the production server (including nodejs/npm versions) before being submitted. Make sure to clone your PR and rebuild it from scratch to make sure that it does not cause problems with dependencies and/or the build chain.
  • A PR must not break any functionality of the product. Every precaution (e.g. writing and running automated tests) must be taken to avoid that.

Core principles

More generally, make sure to follow these three principles:

  • Keep your PRs short
  • Keep your PRs simple
  • Avoid submitting PRs that may cause long discussions with the PR reviewer and/or other contributors

Code guidelines

  • Optimize for search: Like in the React.js project, we want to make it easy for contributors to search for symbols (constants, variables and function names. So don't hesitate to give them verbose/specific names.