search

CrumpLab / vertical

R workflow for sharing psychological research
https://crumplab.github.io/vertical/
Other
35 stars 2 forks source link

add osfr for automating OSF project creation? #22

Closed CrumpLab closed 4 years ago

CrumpLab commented 4 years ago

Based off of the twitter comments, I looked at osfr, an R package for OSF. It looks like that package can be used to create and manage OSF projects from R. If that's true, it would be cool to have a build_osf function that automates some of this for a vertical project.

CrumpLab commented 4 years ago

I checked out osfr this morning, and a couple things:

  1. I used osfr to create a new project on OSF for vertical. osfr allowed me to authenticate with osf, create a project, and add project components from the console, but that's about it. I had to manually add you as an author, and manually link to the github repository. Currently, the osf project for vertical is private, and it's there as an option for us. It makes sense to me that we use OSF for this, it can house both this repository, and the repository for the manuscript if we want and/or just the resulting preprint.

  2. I don't think osfr is quite ready for integration with vertical. It would be nice if additional functions like setting contributors, and linking to github worked from the command line, and there is some suggestion these features would be added in a future release...until then I guess.

mvuorre commented 4 years ago
  1. This is definitely up to you but I am not sure if there is much added value in linking the vertical project to OSF. It's a software project and as such not that suitable for archival on OSF (e.g. you can't install it from osf). But I guess it's nice to get a DOI and a more permanent home for a specific snapshot of vertical.

For projects in general, i.e. from a vertical user's perspective, the best way to integrate with OSF might be to manually link the github repo to an OSF project, and then at time of submission (or whenever), create a registration on OSF, which preserves the github repo at that point in time. The OSF just is not suitable for keeping track of dynamic projects where directories and files are regularly updated, and it asks for too much non-filesystem based overhead (wikis, descriptions, etc.), which divorces the workflow from one's local filesystem based workflow.

  1. I took a look at osfr and agree.