|
| 1 | +# multiOmicsSuite |
| 2 | + |
| 3 | +## Description |
| 4 | + |
| 5 | +multiOmicsSuite (`MOSuite`) is an R package for differential multi-omic analysis. |
| 6 | +It defines an S7 class called `multiOmicDataSet` to store data and analyses from |
| 7 | +multi-omic experiments. |
| 8 | + |
| 9 | +Development of MOSuite follows the R packages 2nd edition (https://r-pkgs.org/), |
| 10 | +with a few minor exceptions noted below. |
| 11 | +Helper functions from `usethis` and `devtools` are used extensively for development tasks. |
| 12 | + |
| 13 | +## Package conventions |
| 14 | + |
| 15 | +- **Internal functions should have roxygen2 documentation** (with `@keywords internal`). Do not strip roxygen docs from internal functions. |
| 16 | +- R code should pass `lintr` and `air format` (run `air format .` from the package root). |
| 17 | +- Tests should be written with `testthat`. |
| 18 | +- The package must pass `devtools::check()`. |
| 19 | +- R code should adhere to the tidyverse style guide. https://style.tidyverse.org/ |
| 20 | +- Only include one return statement at the end of a function, if a return statement is used at all. Explicit returns are preferred but not required for R functions. |
| 21 | + |
| 22 | +## Commit messages |
| 23 | + |
| 24 | +- Commit messages must follow [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) (as enforced in `CONTRIBUTING.md`). |
| 25 | +- Generate messages from staged changes only (`git diff --staged`); do not include unrelated work. |
| 26 | +- Commits should be atomic: one logical change per commit. |
| 27 | +- If mixed changes are present, split into multiple logical commits; the number of commits does not need to equal the number of files changed. |
| 28 | +- Subject format must be: `<type>(optional-scope): short imperative summary` (<=72 chars), e.g., `fix(profile): update release table parser`. |
| 29 | +- Add a body only when needed to explain **why** and notable impact; never include secrets, tokens, PHI, or large diffs. |
| 30 | +- For AI-assisted commits, add this final italicized footer line in the commit message body: _commit message is ai-generated_ |
| 31 | + |
| 32 | +## Pull request (PR) process |
| 33 | + |
| 34 | +- When opening a PR, use the request template (`.github/PULL_REQUEST_TEMPLATE.md`) and fill out all sections of the template in the PR description. |
| 35 | +- Do not allow the developer to proceed with opening a PR if it does not fill out all sections of the template. |
| 36 | +- Before a PR can be moved from draft to "ready for review", all of the relevant checklist items must be checked, and any |
| 37 | +irrelevant checklist items should be crossed out. |
| 38 | +- If code is AI-generated, the PR should be labeled `generated-by-AI`. There should be a brief, concise statement in the PR description of how AI was used in creating the PR (model used, high-level prompt intent, manual review confirmation). |
| 39 | +- When new features, bug fixes, or other behavioral changes are introduced to the code, |
| 40 | +unit tests must be added or updated to cover the new or changed functionality. |
| 41 | +- If there are any API or other user-facing changes, the documentation must be updated both inline via roxygen comments and long-form docs in the `vignettes/` directory as R Markdown files. |
| 42 | +- The `R-CMD-check` github actions workflow must pass before the PR can be approved. |
| 43 | + |
| 44 | +### Changelog |
| 45 | + |
| 46 | +The changelog for the repository is maintained in `NEWS.md` at the root of the repository. |
| 47 | +Each pull request that introduces user-facing changes must include a concise |
| 48 | +entry with the PR number and author username tagged. |
| 49 | +Developer-only changes (i.e. updates to CI workflows, development notes, etc.) |
| 50 | +should never be included in the changelog. |
| 51 | + |
| 52 | +Example: |
| 53 | + |
| 54 | +``` |
| 55 | +## development version |
| 56 | +
|
| 57 | +- Fix bug in `detect_absolute_paths()` to ignore comments. (#123, @username) |
| 58 | +``` |
0 commit comments