Skip to content

Latest commit

 

History

History
38 lines (31 loc) · 1.84 KB

CONTRIBUTING.md

File metadata and controls

38 lines (31 loc) · 1.84 KB

Contribution Guide

This project welcomes all contributors. This short guide (based loosely on Collective Code Construction Contract) details how to contribute in a standardized and efficient manner.

Development Process

  • A contributor shall not commit changes directly to the project.
  • To submit a patch, a contributor shall create a pull request back to the project.

Submitting a Pull Request (PR)

  • Before submitting a PR, an Issue describing the problem should be submitted, and a general consensus around the solution should be achieved.
    • Minor changes (e.g., grammatical fixes) do not require an Issue first.
  • A PR should be a minimal and accurate answer to exactly one identified and agreed upon problem. PRs that tackle multiple problems are harder to review and slower to merge when uncontroversial changes are held up by changes that require more discussion.
  • Where applicable, a PR or commit message body should reference an Issue by number (e.g. "Fixes #33”).
  • Use the Draft PR feature on GitHub or title your PR with WIP if your PR is not ready for review immediately upon submission.

Pull Request (PR) Merging Process

  • PR reviews should be timely. Both reviewer and PR issuer should attempt to resolve the conversation as quickly as possible.
  • PR reviews exist to check that obvious things aren't missed, not to achieve perfection.
  • A PR is eligible for merging if it has at least one approval from a project maintainer and no outstanding requested changes or discussions.
  • Discussions created via an inline comment on GitHub should only be "resolved" by whomever opened the discussion.
  • The person to mark the last open discussion "resolved" should also merge the PR ("close the door when you leave").
    • Note: This usually implies that someone should not merge their own PR.