Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Have main function to create project, separate functions for the type #72

lwjohnst86 opened this issue Mar 16, 2018 · 3 comments


2 participants
Copy link

commented Mar 16, 2018

since an abstract could turn into a poster or slides or manuscript.

@lwjohnst86 lwjohnst86 added this to To do in v0.4.0 via automation Mar 16, 2018


This comment has been minimized.

Copy link

commented Apr 10, 2018

I wonder if one should not have one "create scientific project" template, with different folders for the different elements a scientific project will have at the end:

  • data
  • ideas
  • material
  • methods
  • experiments list
  • abstracts (for conferences)
  • posters
  • presentation (slides)
  • reproducible reports
  • final report (Manuscript)

This would need some brainstrom about what is indeed needed in such a folder and how to keep things flexible.


This comment has been minimized.

Copy link
Owner Author

commented Apr 11, 2018

Hm, I originally had done this way of structuring projects, but I came across several problems...

  • It makes it difficult to create a single DOI for a stand-alone code repository for a manuscript when you submit it to a journal, or when you create a poster/slides and put the DOI of the code repo on the poster/slides.
  • It deviates from the "one Git repo for a single project/product/output" that I think is a simpler way of doing science. That way, work on an individual scientific output (paper, poster, etc) can be directly associated with a single code repo, so they go hand in hand.
  • Keeping track of which version or tag for the project when more than one scientific output is contained within a single Git repo is pretty challenging.

I think one of the main reasons why I prefer the "single project, single folder/repo" model is that it changes the emphasis and mindset of the code/data/figures/etc as a "means to create the paper, poster, etc" to "the code/data/etc is just as valuable as the paper/etc and is an entity/product on its own and should be treated as such".


This comment has been minimized.

Copy link

commented Apr 11, 2018

I am not sure what you mean by "project", I think there is some misunderstanding between Rprojects, scientific projects and scientific output (poster/presentation/paper) (?).

If you like your doi to refer only to the code for one output and get a different one for the data, one would need a new Rproject folder for that output. I think I got your point here. I would then rename the functions and discussion here, using "create new report for your project" as description of what the functions are doing. One could still have a create new scientific project function on top?

Did I understood you correctly this time?

@lwjohnst86 lwjohnst86 moved this from To do to In progress in v0.4.0 May 10, 2018

lwjohnst86 added a commit that referenced this issue May 10, 2018

v0.4.0 automation moved this from In progress to Done May 10, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.