README.md
In tnewman63/easystats: Jump in the easyverse

easystats

The aim of easystats is to provide a unifying and consistent framework to tame, discipline and harness the scary R statistics and their pesky models.

Installation

The whole easystats suite can be installed at once with the following:

install.packages("devtools")
devtools::install_github("easystats/easystats")

library("easystats")

Features

Find an overview of all postings here.

Dependencies

Most of easystats packages are very lightweight, i.e., they don’t rely nor import any other packages! This means that you can safely use them as dependencies in your own packages, without the risk of butterfly effects (a small change in a distant downstream dependency with unexpected upstream consequences).

There is one exception. The see package is one of our high-level packages that is responsible for plotting and creating figures, relying thus on other packages such as ggplot2, which itself is plugged in the tidyverse, increasing package dependencies by a substantial amount. On the bright side of things, it gives a good overview of the place of easystats in the R ecosystem.

Citation

How to reference easystats?

Cite specific packages

The most parsimonious approach is to cite only the particular package that helped you, e.g., “using bayestestR (Makowski, Ben-Shachar, & Lüdecke, 2019)”. However, as easystats is meant to be an ecosystem, with different people working on its different aspects (some being more “citeable” than others), please consider including also the “main” publication: not available yet.

Cite the whole ecosystem

Want to really help us boost our h-index? Or simply credit the whole network of interconnected aspects of easystats? This can be done with a sentence like the following:

Data processing was carried out with R (R Core Team, 2019) and the easystats ecosystem (Lüdecke, Waggoner, & Makowski, 2019; Makowski, Ben-Shachar, & Lüdecke, 2019)

The corresponding bibtex entries are the following:

@article{ludecke2019insight,
    journal = {Journal of Open Source Software},
    doi = {10.21105/joss.01412},
    issn = {2475-9066},
    number = {38},
    publisher = {The Open Journal},
    title = {insight: A Unified Interface to Access Information from Model Objects in R},
    url = {http://dx.doi.org/10.21105/joss.01412},
    volume = {4},
    author = {Lüdecke, Daniel and Waggoner, Philip and Makowski, Dominique},
    pages = {1412},
    date = {2019-06-25},
    year = {2019},
    month = {6},
    day = {25},
}


@article{makowski2019bayestestr,
    title = {{bayestestR}: {Describing} {Effects} and their {Uncertainty}, {Existence} and {Significance} within the {Bayesian} {Framework}},
    volume = {4},
    issn = {2475-9066},
    shorttitle = {{bayestestR}},
    url = {https://joss.theoj.org/papers/10.21105/joss.01541},
    doi = {10.21105/joss.01541},
    number = {40},
    urldate = {2019-08-13},
    journal = {Journal of Open Source Software},
    author = {Makowski, Dominique and Ben-Shachar, Mattan and Lüdecke, Daniel},
    month = aug,
    year = {2019},
    pages = {1541}
}

Versioning

Package version numbers indicate following: MAJOR.MINOR.PATCH.DEVELOPMENT. As long as packages are in a more or less rapidly developing and changig state, the major version number is typically 0. Once we think we will have a stable base that will likely not change dramatically or soon, the major version number will be set to 1, and increased for following major changes that probably break the current API. When new features are added or (re)moved, we typicaly increase the minor version number. Minimal changes or bug fixes only are indicated by increasing the patch version number. Current development versions of our poackages (i.e. master branchs from GitHub) additionally have a development version number. You typically won’t find packages on CRAN with a development version number.

Downloads

Convention of code-style

Following conventions apply to the easystats-ecosystem, to ensure that function and argument names as well as element names for return-values follow a consistent pattern across all packages.

Importing other packages

No full import, only selective import of functions
Use base-R wherever possible (reduce dependencies)
Make sure R-version requirements are not too strict

Helper-functions

Own re-implementation of helper-functions, if it’s not too much effort (e.g. I typically use own functions to check if a string starts / ends with a pattern, or if an object (list, data frame) contains an element with a given name (like tibble::has_name()), to reduce dependencies.

Function names

Lower case, underscore separated if more than one verb
Common prefix for functions that focus on specific “tasks” or workflows (e.g. insight, get_*() to get data, find_*() to find information, or performance, performance_*() to compute measures of model quality, check_*() to check model assumptions…)
Internal functions (that are not exported, like the previously mentined helper-functions) should always start with a . (e.g., .do_some_internal_stuff()).

Argument names

lower case, underscore separated if more than one verb

Element / Column names (for returned data frames)

1) First letter of the column name is capital, unless (6) applies (example: Parameter) 2) First letter of nouns is capital, unless (6) applies (example: ROPE_Percentage, Prior_Scale) 3) Using underscore rather than camelCase to separate words (example: CI_high) 4) Multiple words: common/main part first and adjective/specifier/variational part after (example: Median_standardized, ROPE_percentage) 5) Abbreviations: all uppercase (example: ESS, MCSE, ROPE) 6) Keep conventions for reserved words (example: p, pd, Rhat) 7) Adjectives / verbs: all lower case, unless (1) applies (example: high or low in CI_high or CI_low)