In the Dec 5th, 2022 working group meeting we discussed the option of making the QA scripts available here more accessible for R package maintainers during the development process.
This issue is up for consideration and involves creating a PoC of tooling to make executing the CRAN QA scripts as easy as possible with high fidelity to what would be expected after a package is submitted.
Approach
We talked about a three-step approach including:
Add an entry point script (e.g. bash or makefile), that is thoroughly documented, to use as a tool to kick-off the QA checks
Create a Github action or similar CI template for package maintainers to use in their projects
Explore opportunities to make compute / infrastructure available to the community
Additional Considerations
Some additional considerations we discussed during the meeting included:
The QA scripts, environments, and configurations can change dynamically, we need to figure out how to keep whatever tooling up to date
The parts that tend to "trip" developers up include checks on Windows, MacOS, or cross-compatibility issues, this infrastructure costs more (or takes more time) on Github and could be hard for hobbyists to get access to
The CRAN team has mentioned they aren't interested in package authors "gaming" the system, e.g. just making sure folks pass the status checks, but instead creating high-quality packages. Can we continue to encourage that while making this part of the workflow easier?
Overview
In the Dec 5th, 2022 working group meeting we discussed the option of making the QA scripts available here more accessible for R package maintainers during the development process.
This issue is up for consideration and involves creating a PoC of tooling to make executing the CRAN QA scripts as easy as possible with high fidelity to what would be expected after a package is submitted.
Approach
We talked about a three-step approach including:
Additional Considerations
Some additional considerations we discussed during the meeting included: