With the goal of building a community of packages that have similar philosophies and syntax that are separate from data.table (and outside of data.table scope #5722), we would like to set up a “Seal of Approval” (play on the mascots of data.table) process. The process for a package receiving the Seal of Approval could be: 

• The package developer submits a standard application, indicating that their package is on CRAN, is actively maintained, and has at least one of the features listed below.
• A small number of volunteers from the data.table community review the application to ensure that the criteria are met.  (This includes no testing or vetting of the package functionality itself; only checking that it's an appropriate choice for the Seal.)
• There is some variety of public community vote to approve the package. 

Approval will include being listed as a Seal of Approval package on the data.table repository and an SVG of the “seal” that they can include on their own repository/package logo. The initial idea would be packages that do at least one of the following:

• Built on the same principles as data.table (data.table principles #5693)
• Extends the functionality of data.table to other contexts (e.g., to databases) with similar syntax
• Uses data.table on the backend of the package

Possible examples of this could include packages that have few dependencies (e.g. tinytest), extend functionality (e.g. dtplyr, tidytable, tidyfast), and packages that use data.table on the backend (e.g. modelsummary).
 
This process would hopefully help other developers feel more connected to data.table and be more likely to want to support it. Things for us to decide on are:

1. Does this idea resonate with the data.table community?
2. If so, does the list of criteria make sense for the purposes of the Seal of Approval?
3. What else should be considered in designing the Seal of Approval?