Skip to content

Latest commit

 

History

History
54 lines (48 loc) · 3.1 KB

CONTRIBUTING.md

File metadata and controls

54 lines (48 loc) · 3.1 KB

Contribution Guide

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

Git Workflow Summary

  • Ensure that you've opened an Issue on Github and consensus around the solution has be reached.
    • Minor changes (e.g., grammatical fixes) do not require an Issue first.
  • Create your own fork.
  • When you are starting a new set of changes, fetch any changes from the upstream repo, and start a new feature branch on your fork from that.
  • Make a new branch for each separable set of changes — "one task, one branch"
  • Each commit should make one change. to aide reviewing and (in the worst case) simplify reverting it in the future.
    • A patch commit message should consist of a single short (less than 50 character) line summarizing the change, optionally followed by a blank line and then a more thorough description.
    • Where applicable, a PR or commit message body should reference an Issue by number (e.g. Fixes #33).
  • If you can possibly avoid it, avoid merging upstream branches or any other branches into your feature branch while you are working.
  • Submit a Pull Request from your feature branch against upstream.
    • Use the Draft PR feature on Github or title your PR with WIP if your PR is not ready for a complete review immediately upon submission.
  • Ask on the Exaworks slack if you get stuck.

Pull Request (PR) Merging Process

  • PR reviews should be timely. Both reviewer and PR issuer should make a good attempt at resolving the conversation as quickly as possible.
  • PR reviews exist to check 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, no outstanding requested changes or discussions, and passes CI tests (if configured for the repository).
  • 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"), unless a merge bot is configured for the repository, in which case the PR should be left for the bot to merge.
  • Maintainers should not merge their own patches except in exceptional cases.