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

Closed
lwjohnst86 opened this issue Mar 16, 2018 · 3 comments
Closed
Labels
enhancement A feature, enhancement, or update to the functionality of the package hard Impletementations, problems, or features that are difficult or time consuming high priority

Comments

@lwjohnst86
Copy link
Member

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

@lwjohnst86 lwjohnst86 added enhancement A feature, enhancement, or update to the functionality of the package high priority hard Impletementations, problems, or features that are difficult or time consuming labels Mar 16, 2018
@jcolomb
Copy link

jcolomb 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.

@lwjohnst86
Copy link
Member Author

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".

@jcolomb
Copy link

jcolomb 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement A feature, enhancement, or update to the functionality of the package hard Impletementations, problems, or features that are difficult or time consuming high priority
Projects
None yet
Development

No branches or pull requests

2 participants