Create a process for developer to push/request a package to be added

[nicolekjones]

Overall we need the following requirements:

1. A portal to submit request for package validation [this could be a shiny app] This protal should:
   • validate user input [i.e. minimum requirement of information provided]
   • inform users where they can check status of submitted request
2. Post the request This could be done in a few ways:
   • save the request to a database somewhere that we can check [stored somewhere like AWS]
   • use "pins" package to post request to board [could be directly to github, posit connect or some other location]
3. Create a means of tracking the request This could be:
   • creating an Issue in Github
   • populating a database for tracking
4. Update status of request once validation has been completed

[dgkf]

We discussed this topic briefly at our meeting today, and I just wanted to do some brainstorming about a process that might integration with a r-hub/repos style repository.

This doesn't cover the requesting of a new package. It would serve a slightly different purpose where all package updates on CRAN immediately run through a pipeline.

flowchart LR
  sync --> stage --> val --> publish

  sync["`**update-repos action**
  scheduled github action
  `"]

  stage["`**stage updates**
  derive PACKAGES updates
  `"]

  val["`**R CMD check** + **riskmetric** 
  run against all updated packages and their reverse dependencies, using staged snapshot
  `"]

  publish["`**publish** 
  PACKAGES with additional metadata,
  check and metric logs for each package
  `"]

---

Questions that occurred to me as I was thinking through this:

• How would we want logs being stored? I was imagining that they'd be committed into the repo in a subdirectory next to PACKAGES
• What is the policy on reverse dependencies? Which packages' risk scores should be invalidated by a package update? Theoretically, any reverse dependency (direct or indirect) could be affected. There's also the chance that packages don't declare a dependency but are still affected.
• What should happen when a package fails our checks, even though it still lives on the CRAN mirror?
• What should happen when a package is archived/removed from CRAN? Do we also want to remove it?

[dgkf]

From discussion on April 4,

• How are packages requested?
• If via a form/api, what tasks should then be kicked off?
  • repeatable tasks ushered into api-able behaviors