Governance for the R data.table project
The purpose of this document is to define how people related to the project work together, so that the project can expand to handle a larger and more diverse group of contributors.
The purpose of the project is to maintain the R data.table package, which is guided by the following principles:
To prioritize developer time, we define what is in and out of current scope. Feature requests in issues and pull requests that are out of current scope should be closed immediately, because they are not the current priority. If someone wants to contribute code that is currently out of scope, they first have to make a pull request that changes the scope as defined below.
The current scope of package functionality includes:
data manipulation and analysis
* reshaping/pivoting
* aggregation/summarizing (via [,, by=...]
and grouping sets)
* filtering rows
* all sorts of joins
* adding/updating/deleting columns
* set operations (union/rbind, intersection, difference)
high-performance common functions (frank
, fcase
, fifelse
, transpose
, chmatch
, fsort
, forder
, uniqueN
, ...)
common convenience functions (%like%
, %notin%
, timetaken
, substitute2
, ...)
ordered data functions (rleid
, shift
, fcoalesce
, locf/nocb nafill
, rolling functions)
date and time related classes and functions (IDate
, ITime
)
technical functions (address
, tables
, update_dev_pkg
)
* Reading/writing of data from/to flat (plain text) files like CSV
Functionality that is out of current scope: Plotting/graphics (like ggplot2) Manipulating out-of-memory data, e.g. data stored on disk or remote SQL DB, (as opposed e.g. to sqldf / dbplyr) Machine learning (like mlr3) Reading/writing of data from/to binary files like parquet
Most decisions in the project happen by Consensus, which means that no active people (typically Reviewers and/or Committers) have expressed major blocking concerns, in a public discussion (typically in a GitHub issue or pull request). In Consensus, non-response by inactive members indicates tacit agreement.
A pull request can be merged by any committer, if there is one approving review, and Consensus from active Reviewers and Committers. approving review must come from someone other than the author of the PR. approving review ideally comes from a reviewer of the affected files. * approving review can and often will be by the committer who merges the PR.
There is no special process for changing this document (submit a PR and ask for review).
As contributors of this project, 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, religion, etc.
Examples of unacceptable behavior 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.
Committers 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. A person with special roles who does not follow the Code of Conduct may have their roles revoked.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by opening an issue or emailing one or more of the Committers.
This Code of Conduct is adapted from Tidyverse code of conduct.
data.table Version line in DESCRIPTION typically has the following meanings
Feb 2024: change team name/link maintainers to committers, to be consistent with role defined in governance.
Nov-Dec 2023: initial version drafted by Toby Dylan Hocking and reviewed by Tyson Barrett, Jan Gorecki, Michael Chirico, Benjamin Schwendinger.
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.