Skip to content

Instantly share code, notes, and snippets.

@mdsumner
Created September 14, 2022 21:45
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save mdsumner/50c5556028aab6f0c50fcb83dbe419b4 to your computer and use it in GitHub Desktop.
Save mdsumner/50c5556028aab6f0c50fcb83dbe419b4 to your computer and use it in GitHub Desktop.

Having clarity on what checks will occur and access to the infrastructure to do so - at least recipes to build the machine/s. The submission frontend is very open and happy, "Please fix and resubmit" and very encouraging - and includes automated checks and feedback, and doesn't seem to care much about mistakes and submission churn. But the backend is totally opaque, and despite some promise (rhub, docker, gh actions etc etc) no clear way exists to reproduce the check problems seen (unless you are maybe a total guru of R core godlike status with system admin). The feedback you get is "not fixed, archived again" - silently posted on CRAN, and outside of defined communication protocols (i.e. no email).

The one big thing to reduce friction IMO: leverage the rOpenSci universe to host the checks. If the current maintainer/s simply refuse to open the vaults and help define, curate and maintain accessible check machines, let's be explicit about that and provide clarity about where this very real problem lies. What could be more valuable than transparency around that very obviously hard won sysadmin expertise? Why isn't it open?

We can only guess:

  • it's too hard
  • they don't want to
  • they have very real concerns about why it's a mistake
  • they are protecting their turf
  • it costs too much
  • ??

I would really like answers to these things, I think I can guess given some knowledge of the people and personalities involved. But that's a terrible situation!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment