Skip to content

Latest commit

 

History

History
61 lines (48 loc) · 2.12 KB

CONTRIBUTING.md

File metadata and controls

61 lines (48 loc) · 2.12 KB
Raw

How to contribute to kbtbr

Code of Conduct

kbtbr was initiated within CorrelAid. As such, it falls under the CorrelAid Code of Conduct.

Reporting issues

Issue reports are always welcome. Please provide a Reprex if possible. This might not be possible because of the nature of the kbtbr package. In this case, please describe your problem as well as possible, including screenshots and HTTP responses (excluding sensitive data such as API tokens).

Contribute

We welcome contributions in the form of Pull Requests. Before opening a PR, please open an issue describing what problem you'd like to be working on so that the maintainers can discuss the issue with you and propose feasible solution approaches.

Code styling

Please style any code with the following styler command:

styler::style_pkg(style = styler::tidyverse_style, indent_by = 2)

Package development workflow

Branching model

We follow a feature (or topic) branching workflow. This means that you should create a new Git branch for each issue (or set of related issues) that you are working on. The branch name should contain the issue number to allow for easier cross-referencing.

Long-lived branches

  • main: default branch. Should only contain the releases of the package + hotfixes (small, critical bug fixes that can't wait until the next release)
  • dev: this is where we develop and branch off the feature branches

Short-lived branches

Short-lived branches for feature development and bugfixes ("feature branches") should be branched off from the dev branch.

# create branch from dev branch
git checkout dev
git switch -c 1-project-skeleton # or git checkout -b 1-project-skeleton
# ... work on your branch with add, commit, push

before making a Pull Request to dev, pull in the changes from the dev branch to avoid running into merge conflicts. With your feature branch checked out, run:

git merge dev