---
title: "The *R for Mass Spectrometry* project and meta-package"
author:
- name: Laurent Gatto
  affiliation: de Duve Institute, UCLouvain, Belgium
- name: Sebastian Gibb
  affiliation: University Medicine Greifswald, Germany
- name: Johannes Rainer
  affiliation: Eurac Research, Bolzano, Italy
package: RforMassSpectrometry
output:
  BiocStyle::html_document
vignette: |
  %\VignetteIndexEntry{The R for Mass Spectrometry project and meta-package}
  %\VignetteEngine{knitr::rmarkdown}
  %\VignetteEncoding{UTF-8}
---

# Introduction

`RforMassSpectrometry` is a meta-package, to manage and document the
*R for Mass Spectrometry* (https://www.rformassspectrometry.org/)
project. The goal of the project to provide efficient, thoroughly
documented, tested and flexible R software for the analysis and
interpretation of high throughput mass spectrometry assays, including
proteomics and metabolomics experiments. The project formalises the
longtime collaborative development efforts of its members under the
*R for Mass Spectrometry* organisation to facilitate dissemination and
accessibility of their work.

# Installation

To install the core R for Mass Spectrometry packages, you will need
the `BiocManager` package, available on CRAN. If not already
available, install it with

```{r install1, eval = FALSE}
if (!require("BiocManager"))
    install.package("BiocManager")
```

To proceed with the installation, run

```{r install2, eval = FALSE}
BiocManager::install("RforMassSpectrometry/RforMassSpectrometry")
```

Note that some very recent Bioconductor will be needed to install and
run the suite of R for Mass Spectrometry packages, and will require a
recent version of R and possibly even installing the [Bioconductor
development
version](http://bioconductor.org/developers/how-to/useDevel/).


Loading the `RforMassSpectrometry` package with

```{r}
library("RforMassSpectrometry")
```

will load the required core packages.


# Code of Conduct

As contributors and maintainers of the *R for Mass Spectrometry*
initiative, we pledge to respect all people who contribute through
reporting issues, posting feature requests, updating documentation,
submitting pull requests or patches, and other activities. We are
committed to making participation in this project a harassment-free
experience for everyone, regardless of level of experience, gender,
gender identity and expression, sexual orientation, disability,
personal appearance, body size, race, ethnicity, age, or
religion. Examples of unacceptable behaviour by participants include
the use of sexual language or imagery, derogatory comments or personal
attacks, trolling, public or private harassment, insults, or other
unprofessional conduct. Project maintainers have the right and
responsibility to remove, edit, or reject comments, commits, code,
wiki edits, issues, and other contributions that are not aligned to
this Code of Conduct. Project maintainers who do not follow the Code
of Conduct may be removed from the project team. Instances of abusive,
harassing, or otherwise unacceptable behaviour may be reported by
opening an issue or contacting one or more of the project maintainers.

This Code of Conduct is adapted from the Contributor Covenant, version
1.0.0, available from http://contributor-covenant.org/version/1/0/0/

# Contributions

The *R for Mass Spectrometry* project welcomes contributions in the
form of ideas, documentation, code, packages, fixes (bugs and typos),
... We invite you to discuss any of these opening a GitHub issue in
the relevant package github repository.

If you have any direct contributions to an existing repository, we
suggest to first discuss these as an issue if it implies any
substantial changes (no need for an issue if its a simple typo, and we
really appreciate those). 

Contributions, even those from core members, are always expected to
come in the form of a pull request (PR) that then undergoes a formal
review. To do this, start by forking the package you want to
contribute. It is also advised to work in, and make the PR, from a
non-master branch. Good branch names include `issueX` when it relates
to a specific issue, `feat-X`, `bug-Y`, `docs-Z` for new features, bug
fixes and documentation updates respectively. The reviewers might ask
for additional clarifications and/or changes prior to merging the
PR. When contemplating contributing code, please follow the style
guide below.

In particular, when several developers collaborate on a feature, an
admin should create a dedicated branch
`RforMassSpectrometry/Package:branch`. Developers should then fetch
that branch in their local copy of the `Package` repository and send
PRs to that branch too, where it will be reviewed, and eventually
merged into `RforMassSpectrometry/Package:master`.


See also the
[tidyverse](https://github.com/tidyverse/.github/blob/master/CONTRIBUTING.md)
and
[Mycrof](https://github.com/MycroftAI/mycroft-core/blob/dev/.github/CONTRIBUTING.md)
contribution guides for additional resources and instructions.

Reviewers will do their best to help you to get the PR
merged^[Useful reading: The [nodejs reviewing PRs for
reviewers](https://github.com/nodejs/node/blob/main/doc/contributing/pull-requests.md#reviewing-pull-requests)
guide].


We also anticipate to open up some specific requests for contributions
and invite specific members of the community, if we identify a specific
need and/or a specific developer to address that need.

### Commit messages {.unnumbered}

Commit messages should follow the [Conventional
Commits](https://www.conventionalcommits.org/en/v1.0.0-beta.4/#summary)
guidelines. In particular, the following *types* are recommended
(based on [angulars
types](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)):

- `build:` Changes that affect the build system or external
  dependencies (example scopes: depends, suggests, imports, ...).
- `ci:` Changes to the continous integration (CI) configuration files
  and scripts (example: Travis configuration file).
- `docs:` Documentation only changes, including manual pages and vignettes.
- `feat:` A new feature.
- `fix:` A bug fix.
- `perf:` A code change that improves performance.
- `refactor:` A code change that neither fixes a bug nor adds a
  feature.
- `style:` Changes that do not affect the meaning of the code
  (white-space, formatting, ...).
- `test:` Adding missing tests or correcting existing tests.
- `other:` Anything that doesn't fit in the above. Consider opening an
  issue suggestion a new type.


### Credit where credit is due  {.unnumbered}

We also want to offer proper credit to those that provide substantial
contributions. Substantial contributions include, for example

- new functionality that goes beyond e.g. a simple plot function
- bug fixes combined with related unit tests
- extended documentation, examples or vignettes describing a complete
  (potentially alternative) analysis workflow or use-case

Fixing typo(s) isn't considered a substantial contribution per-se,
even though they are highly appreciated.

Once a substantial contribution passes review and is merged, we will
add the contributor in the package's author list as an official
contributor (`ctb` role) or even author (`aut` role) for more
substantial contributions. The contributors name will also be added to
the *R for Mass Spectrometry* web page and to any relevant publications that
directly stem from their work.


# Coding style

The *R for Mass Spectrometry* packages follows the [Bioconductor style
guide](https://bioconductor.org/developers/how-to/coding-style/). In
particular

- Do not use `.` when naming symbols.
- A leading `.` can be used for hidden/local functions or variables.
- Snake case should be restricted to internal functions. For
  consistency, we favour camel case for public functions.
- Class names should start with a capital and each class should posses
  a constructor with identical name. Running the constructor without
  any input should produce a valid empty object.
- Use `##` to start full-line comments.
- For roxygen headers `#'` is preferred, although `##'` is tolerated.
- Use spaces between `=` in function arguments or class definition:
  `f(a = 1, b = 2)`.
- Always use a space after a comma: `a, b, c`.
- Always use spaces around binary operators: `a + b`.
- Lines should be kept shorter than 80 characters. For example the
  following code isn't accepted

```r
# no wrap at 80
someVeryLongVariableName <- someVeryLongFunctionName(withSomeEvenLongerFunctionArgumentA = 1, withSomeEvenLongerFunctionArgumentB = 2)
```

and should be wrapped as shown below:

```r
# alternative 1
someVeryLongVariableName <-
    someVeryLongFunctionName(withSomeEvenLongerFunctionArgumentA = 1,
                             withSomeEvenLongerFunctionArgumentB = 2)
# alternative 2
someVeryLongVariableName <- someVeryLongFunctionName(
    withSomeEvenLongerFunctionArgumentA = 1,
    withSomeEvenLongerFunctionArgumentB = 2)
```


# Contact

Please see the [contact
page](https://www.rformassspectrometry.org/contact/) for instructions
on how to get in touch.

# Session info {.unnumbered}

```{r sessionInfo, echo=FALSE}
sessionInfo()
```
