Skip to content

Instantly share code, notes, and snippets.

@chand1012

chand1012/CONTRIBUTING.md

Created December 23, 2022 04:26
Show Gist options
  • Save chand1012/6b2bb638efbf63375e2248f56d7404fa to your computer and use it in GitHub Desktop.
Save chand1012/6b2bb638efbf63375e2248f56d7404fa to your computer and use it in GitHub Desktop.
Download ZIP
The CONTRIBUTING.md file that I use.
Raw
CONTRIBUTING.md

Contributing

Please note we have a code of conduct, please follow it in all your interactions with the project.

Branches, Issues, & Pull Requests

Branch Names

Branch names should be

  • Prefixed with your GitHub username followed by a slash so that they can easily be searched. For example, chand1012/feature-here.
  • Anything after the slash should either be
    • The word issue followed by a corresponding issue number. For example, jfrase/issue69.
    • A one to four word explanation of the feature or fix, separated by dashes. For example, kjv13/fixing-a-bug.
  • Branches should be deleted once an issue is finished.
  • While it is encouraged to make sure your branches can compile as well as pass all unit tests, it is not required.
  • Branches should be deleted once their respective PR is merged or closed.

Issues

Please double check that an issue containing your feature or bug doesn't already exist.

Issues should contain, at the very least a high level overview of the bug or feature that the issue is describing.

Issues should be

  • Limited to a single bug.
  • Used as a method to converse about the issue. Post chat messages that may be relevant to the issue, and/or adding screenshots, sketches, charts, and possible solutions to the issue, are encouraged!

While issues are limited to a single bug, they can encompass multiple issues for a single feature, however if said feature should be broken out into a task list, those tasks may be broken into separate issues if they can be completed regardless of order. For example, if we have tasks A, B, and C, and they must be completed in the order A->B->C, they should remain a task list. However if the task list can be completed in any order, and/or multiple developers could work on any of the issues asynchronously with minimal or no blockage, they should be broken out into separate issues.

Pull Requests

Pull requests should

  • Be linked to the issue it is resolving. See here for more information.
  • Be reviewed by at least one other contributor on the project.
    • Exception: This can be ignored if there are less than 3 consistent contributors on the project, as long as all units test and other CI/CD checks pass.
  • Pass all CI/CD checks configured on the repository.
  • Be squashed into a single commit to keep the commit history on main/master clean.
  • Not contain any installation or build dependencies in the commit.
  • Update any relevant documentation. This includes but is not limited to:
    • Changes in interface.
    • New environment variables.
    • Exposed Ports.
    • Useful File Locations.
    • Container Parameters.
  • Bump any version numbers in any example files and the README that this pull request would represent. We use the SemVer versioning scheme.

Code of Conduct

See the Contributor Covenant.

Community Leader Contact: Chandler [email protected].

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment