data.table has no formal governance document; Matt Dowle, the original author and only current maintainer, has commit permissions on github, and he submits the package to CRAN. The only other author, Arun, has been inactive for several years.
Matt has done a fantastic job at creating a highly efficient and widely used R package, and he continues to submit "patch" releases to CRAN (containing minimal fixes so that the package continues to pass CRAN checks). data.table has many contributors, who have submitted PRs, which have been reviewed and merged by Matt. This form of project leadership/governance is similar to the former python model, Benevolent Dictator For Life (BDFL). This form of governance can handle as many contributions/PRs as the BDFL (Matt) has time to review and merge. The purpose of this issue is to discuss alternative forms of governance which may be able to handle more contributions, from a larger and more diverse group of contributors.

I therefore propose that we use this issue to write constructive, thoughtful, respectful, and inclusive comments containing concrete propositions for the future governance of the data.table project. At the end of three months (end of November 2023), I will synthesize the comments into a draft governance document, which I will publish as a PR that creates a new GOVERNANCE.md file. After that, there will be a three one month period of open comments, where people can discuss the strengths/weaknesses of the draft, and we can discuss possible edits to make. At the end of that second period (end of Dec 2023), I will consider the consensus of the comments, make corresponding edits, and publish a second draft (by editing the PR). If that draft is sufficient, I will ask contributors to sign that document by adding their names to the GOVERNANCE.md file in that PR. If there are still significant concerns, we can use another three one month period of comments to resolve them, after which I will publish another (hopefully final) draft in end of Jan 2024.

Some significant questions that I suggest we try to answer in the governance document: (others are welcome too)

• What is the purpose/scope of the data.table package? What kinds of functions should it contain? And what is out of scope? What is "within scope" for the data.table package? #5722
• What are the guiding principles of the data.table project? efficiency? simplicity? inclusion of diverse contributors? backwards compatibility? See data.table principles #5693
• How should conflicts be resolved? By consensus? voting? who should be allowed to vote? Suggestion: consensus, meaning that no formal voting is required, but discussion must continue until everyone who is participating in the discussion agrees. (we should not have to wait for people who are absent to express their approval)
• What roles and/or permissions should we define? What process must a contributor follow in order to obtain special roles and/or permissions? see below, Formal governance document #5676 (comment)
• How to decide when to merge a PR? Suggestion: need approval from at least one reviewer other than the PR submitter. (and do not merge if anyone has serious/blocking concerns)
• How to interpret version numbers? version number conventions #5715
• What standards of conduct should we expect from contributors, in their writing, in order to encourage diversity/inclusion? Code of conduct #5708
• What is the frequency of releases to CRAN that should be expected? What process should be followed by the CRAN maintainer? (for updates in response to requests from CRAN, and for regular releases) See CRAN maintainer communication standards and release checklist #5714
• If some one asks a question, or wants a code review, how much time is reasonable to expect a response? 1 week? 1 month? If no response after that time period, what are the consequences? How do we give due credit to past/inactive contributors while at the same time giving enough permission to current/active contributors?
• What process should we use to make modifications to the GOVERNANCE.md document, after it has been initially accepted/ratified? 2/3 of people who signed the GOVERNANCE.md must approve? 50%+1?

We are not the first open-source project to have a governance document, here is a reading list about open-source governance, which can inform our discussion:

• Rust, OpenStack, Jupyter, Django, Typescript, Astropy, Microsoft, which are discussed in https://peps.python.org/pep-8002/
• arrow https://arrow.apache.org/committers/
• pandas https://pandas.pydata.org/about/governance.html
• ggplot2 https://ggplot2.tidyverse.org/GOVERNANCE.html
• substrait https://substrait.io/governance/ (thanks @assignUser )
• rOpenSci https://softdev4research.github.io/4OSS-lesson/04-contributions/ (thanks @waynelapierre )

About the roles to define, I suggest replacing the current flat leadership model (one maintainer role at the top, many contributors on the bottom), with a hierarchical model containing intermediate "reviewers," similar to the successful model of subsystem maintainers from the linux kernel project. See figure below, but note that the names are totally arbitrary (for example, I do not expect Kelly to be release manager, but it would be nice to have someone take the role of release manager).

I would suggest that each intermediate “reviewer” volunteer to be in charge of reviewing and merging PRs for specific features/files, as defined in the CODEOWNERS file, #5629 So far only @ben-schwen @MichaelChirico and @jangorecki have volunteered to be reviewers.

In addition to the reviewer role in the figure above, there could be at least five other roles (with responsibilities):

• release manager (to communicate with CRAN and submit new releases),
• translation manager (to communicate with translators),
• performance testing manager (to prevent performance regressions),
• reverse dependency manager (to ensure compatibility with other CRAN packages),
• binary manager (to build binaries of development branches for user testing before release).

I would volunteer to be reverse dependency manager, as I have set up the revdep-check system

I would nominate @MichaelChirico for translation manager and @jangorecki for binary manager.

Who would volunteer for release manager and performance testing manager?