Skip to content

Commit

Permalink
various updates based on comments from Jan and Michael
Browse files Browse the repository at this point in the history
  • Loading branch information
tdhock committed Nov 30, 2023
1 parent 7070a54 commit 45202ee
Showing 1 changed file with 21 additions and 21 deletions.
42 changes: 21 additions & 21 deletions GOVERNANCE.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,28 +11,29 @@ The purpose of this document is to define how people related to the project work
The purpose of the project is to maintain the R data.table package,
which is guided by the following principles:

* Few (if any) dependencies
* No external Imports/LinkingTo/Depends dependencies (external meaning those not maintained by the project)
* Few (if any) Suggests/Enhances dependencies
* Time & memory efficiency
* Concise syntax (minimal redundancy in code)
* Stable code base (easy for users to upgrade to new data.table, and compatible with old R versions)
* Comprehensive and accessible documentation and run-time signals (errors, warnings)
* Clear error and warning messages

To prioritize developer time, we define what is in and out of scope.
To prioritize developer time, we define what is in and out of current scope.
The current scope of package functionality includes:
* Data manipulation and analysis
* reshaping/pivoting
* aggregation/summarizing
* subsetting rows
* all sorts of joins
* adding/updating/deleting columns
* Reading/writing of data from/to many file formats
* Sorting (forder)
* Reading/writing of data from/to flat (plain text) files like CSV

Functionality that is out of scope:
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 / modeling (like mlr3)
* regular expression builders (like rex and nc packages)

# Roles

Expand All @@ -43,7 +44,7 @@ Functionality that is out of scope:

## Project member

* Definition: some one who has submitted at least one PR that has been merged into master.
* Definition: some one who has submitted at least one PR with code contributions, that has been merged into master. (spelling fixes in docs do not count)
* How to obtain this role: any user can become a member by submitting a PR, then having it reviewed and merged into master. Contributors who have written issues should be encouraged to submit their first PR to become a project member.
* How this role is recognized: Members are credited via role="ctb" in DESCRIPTION (so they appear in Author list on CRAN), and they are added to https://github.com/orgs/Rdatatable/teams/project-members so they can create new branches in the Rdatatable/data.table GitHub repo. They also appear on https://github.com/Rdatatable/data.table/graphs/contributors (Contributions to master, excluding merge commits).

Expand All @@ -57,7 +58,7 @@ Functionality that is out of scope:
## Committer

* Definition: permission to commit to, and merge PRs into, master branch.
* How to obtain this role: after a reviewer has a consistent history of careful reviews of others' PRs, then a current GitHub maintainer should ask all other current GitHub maintainers if they approve promoting the reviewer to GitHub maintainer, and it should be done if there is general consensus/agreement.
* How to obtain this role: after a reviewer has a consistent history of careful reviews of others' PRs, then a current Committer should ask all other current Committers if they approve promoting the Reviewer to Committer, and it should be done if there is Consensus among active Committers.
* How this role is recognized: credited via role="aut" in DESCRIPTION (so they appear in Author list on CRAN), and added to https://github.com/orgs/Rdatatable/teams/maintainers which gives permission to merge PRs into master branch.

## CRAN maintainer
Expand All @@ -70,28 +71,29 @@ Functionality that is out of scope:

Each of the below roles is important, and a wiki page should be
created to explain (1) details of responsibilities, (2) who to contact
to obtain this role.
to obtain this role.

* translation manager (to communicate with translators), no special permission.
* triage manager (to decide which issues/PRs to include in next releases), no special permission.
* performance testing manager (to prevent performance regressions), need permission to edit continuous integration scripts.
* reverse dependency manager (to ensure compatibility with other CRAN packages), need access to a computer that can run revdep checks in parallel.
* binary manager (to build binaries of development branches for user testing before release), need permission to edit continuous deployment scripts.
* Triage manager (to decide which issues/PRs to include in next releases), no special permissions.
* Translation manager (to communicate with translators, and source code changes related to i18n, for example making sure messages are translation-ready, updating the .pot template), no special permissions (updates should happen in a pull request as usual).
* Performance testing manager (to prevent performance regressions), no special permissions (updates should happen in a pull request as usual).
* Continuous integration/deployment manager (to maintain script which run tests and build binaries of development branches for user testing before release), no special permissions (updates should happen in a pull request as usual).
* Reverse dependency manager (to ensure compatibility with other CRAN packages), need access to a computer that can run revdep checks in parallel.

# Decision-making processes

## Definition of Consensus

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.

## Pull Requests

A pull request can be merged as long as there is one approving review
(ideally from a reviewer of the affected files, different person from
author of PR), and no opposing/blocking comments from
Reviewers/Committers.
A pull request can be merged as long as there is one approving review (ideally from a reviewer of the affected files, different person from author of PR), and Consensus from active Reviewers and Committers.

## CRAN updates

* Regular CRAN releases should ideally occur twice per year, and can include new features.
* A hotfix/patch CRAN release should occur when CRAN asks for one, at which time the CRAN maintainer should post an issue on github, and ask others to help fix/prepare the release.
* Both kinds of releases should be discussed in an issue, and the release should happen only if there is general consensus that it is OK to go ahead (no Reviewer/Committer has expressed major blocking concerns).
* Both kinds of releases should be discussed in an issue, and the release should happen only if there is Consensus among active Reviewers and Committers.
* It is the responsibility of the CRAN maintainer to ensure quality prior to release. This includes CRAN checks, unit tests, performance tests, etc, and these tasks can be delegated to others.

## Changing this GOVERNANCE.md document
Expand All @@ -107,7 +109,7 @@ We are committed to making participation in this project a harassment-free exper

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.

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. A person with special roles who does not follow the Code of Conduct may have their roles revoked.
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.

Expand All @@ -122,5 +124,3 @@ data.table Version line in DESCRIPTION typically has the following meanings
* z is even for CRAN releases, odd for GitHub development.
* z=99 for master branch with new features (for example 1.14.99 or 1.15.99), which eventually becomes a regular CRAN release, with incremented y and z=0 (for example 1.15.0 or 1.16.0).
* patch/hotfix development should occur on GitHub as z=odd (1.15.1) and release to CRAN as z=even (1.15.2).


0 comments on commit 45202ee

Please sign in to comment.