Skip to content

Latest commit

 

History

History
107 lines (73 loc) · 4.78 KB

CONTRIBUTING.md

File metadata and controls

107 lines (73 loc) · 4.78 KB
Raw

Contributing

GitHub Flow

For more information see GitHub Flow

GitHub Flow is very lightweight (especially compared to GitFlow). This workflow uses only two kinds of branches:

  • Feature branch
  • Main branch (previously called master)

The feature branches are used to develop new features as well as fixes. These branches are usually created out of main.

Anything in the main branch is deployable. The main branch is expected to be deployed regularly and is considered stable.

How to work with GitHub Flow

For more information see GitHub Flow

TL;DR

  1. anything in the main branch is deployable
  2. create descriptive branches off of main
  3. push to named branches constantly
  4. open a pull request at any time
  5. merge only after pull request review
  6. deploy immediately after review

Please make sure to sign all your commits (See: git-scm).

Working with Forks and Pull Requests

If you want early feedback feel free to open a Draft Pull Request. When you are done, you can convert it to a standard Pull Request (or create one if you did not create a Draft Pull Request).

Generally the TeamDojo project follows the standard GitHub Pull request process.

Please make sure to sign all your commits (See: git-scm).

Bugfixing and Security Fixing Released Features

For bug fixes and security fixes of the current release please follow the following workflow:

  • For the minor release
    • Checkout current minor release branch (e.g. v2.5.x) or create if not existent from latest git tag
    • Create a bugfix branch from release branch
    • Fix Bug
    • Create PR to release branch
    • Generate new semver release
  • For the main branch:
    • Create a bugfix branch from main branch
    • Cherry-Pick Bugfix and commit to bugfix branch
    • Create PR to main branch

Working with Issues – How to Contribute in Issues

It is mandatory to open an issue, if the task takes longer than one hour. Before you open an issue please verify there is no existing one covering your issue.

How to Write Commit Messages

For more information see Chris Beams article.

TL;DR

  1. Separate subject from body with a blank line
  2. Limit the subject line to 50 characters
  3. Capitalize the subject line
  4. Do not end the subject line with a period
  5. Use the imperative mood in the subject line
  6. Wrap the body at 72 characters
  7. Use the body to explain what and why vs. how

Please make sure to sign all your commits (See: git-scm).

Please make sure you don't include @mentions or fixes keywords in your git commit messages. These should be included in the PR body instead.

Please make sure to add your signed-off-by tag as described in our contributors file.

Developer Certificate of Origin and Licensing

We decided to use DCO instead of CLA as described in CLAs and using DCO clearly. The reason for that: We need to be sure that one submitting a contribution to this repository is allowed to do this and does not violates copyrights of someone else. For that purpose you have to do some steps to to fullfil our DCO requirements:

  1. Read carefully our contributors file.
  2. Open a pull request which adds you to the contributors file to agree the DCO.
  3. Always add a signed-of tag to all your commits as described in the contributors file.
  4. Add a SPDX license header to all files your contribution will create. You can use the reuse tool with our helper script.