rOpenSci review and CRAN release

[joeroe]

Although installing from GitHub using devtools works fine, it would be mildly more convenient, and more familiar to newer R users, to install it the standard way from CRAN. This package seems fairly mature, is a CRAN release planned?

Scanning through issues I can find one that would hold up a CRAN release:

• [x] #70: The use of unexported/internal functions called via ::: is not allowed by CRAN

Any others?

[benmarwick]

Yes, that's pretty much it, I just did a R CMD check on Linux and the main thing is this NOTE

N  checking dependencies in R code (939ms)
   Unexported objects imported by ':::' calls:
     ‘usethis:::done’ ‘usethis:::field’ ‘usethis:::git_uncommitted’
     ‘usethis:::todo’ ‘usethis:::value’
     See the note in ?`:::` about the use of this operator.

I agree with @nevrome that we should just duplicate these functions in here, they are pretty simple and stable.

We are also having a discussion about the default behaviours, whether it makes sense in most cases to produce a /R, /man and NAMESPACE. I think we should consider an argument likepackage = c('basic', 'full')where basic just gives a DESCRIPTION and full gives the usual stuff. I think most people are not going to be using/R,/manandNAMESPACE at all. I usually delete them. So I think that default makes more sense than our current default. But it might be good to have some discussion about this before submitting to CRAN.

Thoughts welcome!

[joeroe]

On my setup the package fails to build if there's no NAMESPACE file, so that seems essential? I do use man/ and R/ (a big reason for using packages is to have documented and exported functions, no?), but presumably anyone doing that will be familiar enough with package structure to know to recreate them. roxygen2 also automatically recreates NAMESPACE and man/.

[nevrome]

CRAN release is a good idea. It could be timed for the CAA2020 meeting. What comes to mind:

• [x] A package = c('basic', 'full') option is a good idea. The default does not have to include R/ and man/. The NAMESPACE file though is necessary as pointed out by @joeroe. BM
• [x] The code file structure of the package should be re-evaluated. hello.R is not very speaking and should be split up. That also applies to some of the other files. CS
• [x] #71 is not solved yet. For this and other bugs CS
• [x] #50 update the template docx to show keywords BM
• [x] #70 has now been fixed.
• [x] The osf workflow description shouldn't become a vignette. It's not directly related to the package code, requires a lot of space with the screenshots and maybe won't last very long with changes in the UI of osf.io. I suggest we put this somewhere else. Maybe a gist or a blog post or wiki? BM make wiki, mention in README
• [x] The rrtools.addin should be mentioned somewhere in the README. BM
• [x] rrtools.addin should be tested and made to work very well with the final CRAN version of rrtools CS
• [x] refer reader out to https://github.com/benmarwick/huskydown and similar for writing a thesis BM
• [x] #72 about helping with csl files BM
• [x] #56 codemeta seems simple to add BM
• [x] binder button in readme template BM

For the future

• [ ] #41 rstudio projects template to replace generic use_compedium()

[benmarwick]

Let's aim for rOpenSci review and onboarding, then CRAN, then JOSS paper

[benmarwick]

@nevrome Just want to check with you about what I did in #102. I think it makes sense to check if a directory exists or not. But the workflow gets a bit tangled up if a user does 'New project on GitHub first, then download to RStudio' and then runs use_compendium("pkgname"). Because they may have made a readme file on GitHub or added other things there, then we want to overwrite them with use_compendium.

I did have this experience with a novice student recently who faithfully followed the steps in 'Happy Git With R' to create and clone a repo, but then got confused when using our functions because they did some things on their GitHub repo that we didn't anticipate (checked some boxes on the GitHub web page, etc).

My impression is that there are so many ways things can go wrong with having both of those Git/GitHub options for novices and in workshop situations, and it will be simplest for us to update the readme to limit the universe of possible confusions for the novice user, rather than trying to write code to catch all of the possible edge cases and handle them.

So I propose that we:

• move Create a Git managed directory linked to an online repository to the step after 'rrtools::use_compendium("pkgname")'
  • in that Create a Git managed directory linked to an online repository section, make "New project in RStudio first, then connect to GitHub/GitLab" the recommended option, and recommend advanced use only the "New project on GitHub first, then download to RStudio" option, or omit it altogether. I think my preference it to omit it from the readme, or just hide it away with something like "there are many possible ways to connect your compendium with Git and Github (see ...)"

While we're discussing the instructions, I'll mention my proposal to combine usethis::use_mit_license(name = "My Name") into use_compendium. As always, I look forward to your thoughts and wisdom on these topics.

[nevrome]

Well - #102 broke the suggested workflow, Ben. The check if the directory exists prevents the suggested pipeline of first cloning an empty repo from Github altogether.

This workflow was born from my workshop experience and I still prefer it that way round. Connecting an existing repo to Github later is a lot more awkward that starting from Github with a clean slate.

I suggest the following solution: If the selected directory exists and has files in it, then we ask the user two (!) times if he really likes to use this directory for the research compendium. If he agrees, then we unlink all files in the directory and go from there. Of course we have to make it really clear what that entails: Possibly the irretrievable loss of these files. We should list the files and ask with these nice three-options questions that force you to think about your decision.