This document outlines how to propose a change to immunarch.
There are three general ways to contribute to the package.
- Code contribution via pull requests. Helps us improve the codebase of the package, add new features or fix bugs and typos in the documentation.
- Bug reports and feature requests via GitHub issues. Helps us notice important issues and improvements to address.
- Helping others by answering tickets in GitHub issues. Greatly helps build the community and accelerates the immune repertoire research progress.
Before you make a substantial pull request, you should always file an issue and make sure someone from the team agrees that it's a problem. If you've found a bug, create an associated issue and illustrate the bug with a minimal reprex. If you need to send a data and can't do that via GitHub, please note it in the issue.
-
Always start by forking the
dev
branch from here to make sure you have the latest pre-release version ofimmunarch
. Name it accordingly to your contributions.repClonality refactor
orfix-issue-12
would work. -
We recommend that you create a Git branch for each pull request (PR).
-
We follow the following guidelines for commit naming.
-
New code should follow our style guide that is the tidyverse style guide You can use the styler package to
apply these styles, but please don't restyle code that has nothing to do with
your PR.
-
We use roxygen2 for documentation.
-
We use testthat. Contributions
with test cases included are easier to accept.
-
Look at the CI (Continuous Integration) build status before and after making changes.
The
README
should contain badges for any continuous integration services usedby the package.
Small typos or grammatical errors in documentation may be edited directly using the GitLab web IDE functionality / GitHub web interface, so long as the changes are made in the source file. Please make sure to create a Pull Request instead of commiting directly to the master
branch.
- YES: you edit a roxygen comment in a
.R
file belowR/
. - NO: you edit an
.Rd
file belowman/
.
We employ Major.Minor.Patch. E.g., 0.4.0.
Hotfixes: Major.Minor.Patch → Major.Minor.(Patch + 1)
Guidelines: http://r-pkgs.had.co.nz/release.html
We follow the following guidelines for commit naming.
There are eight types of commits: chore
, docs
, feat
, fix
, refactor
, test
, perf
, style
. Most used are feat
for implementation of a new feauture, docs
for updating the documentation, fix
for fixing a bug.
Commit name examples: feat(diversity): added the Chao1 method for diversity estimations
, fix(clonality): fixed a bug in clonality computations #12
, where #12
is a link to the issue on the immunarch issue page.
- Changes in analysis- and visualisation-specific functions:
diversity
,overlap
,pub-rep
,clonality
,gene-usage
,explore
,kmers
,spectratype
,dynamics
,tools
,single-cell
. - General changes in visualisation functions (e.g., replace one package with another, or change a non-specific visualisation function such as
vis_bar
):vis
- Changes in parsing:
io
- Changes in databases support:
db
- Changes in additional functions such as general statistics functions:
utility
- Changes in data:
data
- Changes in NAMESPACE, DESCRIPTION, citations, ISSUE_TEMPLATE.md, etc., without README:
upkeep
- Changes in README and vignettes:
vignette
- Changes in Continuous Integration:
ci
- Changes in Shiny applications:
shiny
We have a rich list of templates for Issues here. Go to the GitHub Issues page for immunarch
and create a new Issue ticket from there.
Got to GitHub Issues page and find Issues that you are familiar with to answer.
Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.
(adapted from dplyr contribution guide)