Closed dmkaplan2000 closed 4 years ago
Hello @dmkaplan2000 and thanks for your submission.
It is hard to evaluate package functionality from the current README. Could you please add more detail on what the package is and what it does in the README so that we can assess whether the package is in scope or not?
Hi,
I have beefed up the readme a bit, but I am not sure exactly what you are looking for. The main piece of information that was probably missing is that the package is an extension to knitr to create standalone Rmarkdown documents that can provide a single source for the contents of a paper.
If you are not satisfied with the modifications I have made, would you mind giving me a bit of a better idea of what you are looking for in the README? In the current README, I provide a brief description of what the package does, how to install it and how to use it, pointing to the package vignette for more details. The vignette is pretty detailed, so I didn't want to duplicate too much information in the README.
Thanks, David
On 5/29/20 15:45, Anna Krystalli wrote:
Hello @dmkaplan2000 https://github.com/dmkaplan2000 and thanks for your submission.
It is hard to evaluate package functionality from the current README. Could you please add more detail on what the package is and what it does in the README so that we can assess whether the package is in scope or not?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ropensci/software-review/issues/379#issuecomment-635980710, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEOYJPYVPIZJ22PJA75GDDRT6377ANCNFSM4NLHPSOA.
Hi @dmkaplan2000,
Ultimately at this stage of the review, the editor in chief should be able to get a feel for the scope and function of the package from the README. The problem with the vignette is that the package needs to be installed and the docs built locally to be viewed, unless you include a pkgdown online version of the docs. That's not meant to happen at this stage.
The README is important not just for us but for any user also. They will have a look at the README first. If they can't understand what the package does and how it is used they can't assess whether it's something they can make use of. They are unlikely to at that point install it and build the vignettes to find out more. The README is essentially the advertisement for your package. So anticipate what high-level information a user might want / need to know straight up. There are more specific recommendations in the rOpenSci packaging guide: https://devguide.ropensci.org/building.html#readme
The added demo definitely helps me understand how to use the package. I still have questions of what a good use case would be though and the full extent of its functionality. Eg for the example you give, I could just include something like the following and get a very similar result:
tibble::tribble(
~colA, ~colB,
"a", 1,
"b", 2,
"c", 3
)
#> # A tibble: 3 x 2
#> colA colB
#> <chr> <dbl>
#> 1 a 1
#> 2 b 2
#> 3 c 3
Created on 2020-05-29 by the reprex package (v0.3.0)
Help me understand why or when in particular I should be considering your package instead.
Hi,
I just pushed a new version that includes several more examples that hopefully answer your questions.
Cheers, David
On 5/29/20 16:40, Anna Krystalli wrote:
Hi @dmkaplan2000 https://github.com/dmkaplan2000,
Ultimately at this stage of the review, the editor in chief should be able to get a feel for the scope and function of the package from the README. The problem with the vignette is that the package needs to be installed and the docs built locally to be viewed, unless you include a pkgdown online version of the docs. That's not meant to happen at this stage.
The README is important not just for us but for any user also. They will have a look at the README first. If they can't understand what the package does and how it is used they can't assess whether it's something they can make use of. They are unlikely to at that point install it and build the vignettes to find out more. The README is essentially the advertisement for your package. So anticipate what high-level information a user might want / need to know straight up. There are more specific recommendations in the rOpenSci packaging guide: https://devguide.ropensci.org/building.html#readme
The added demo definitely helps me understand how to use the package. I still have questions of what a good use case would be though and the full extent of its functionality. Eg for the example you give, I could just include something like the following and get a very similar result:
tibble::tribble( ~colA,~colB, "a",1, "b",2, "c",3 )
> # A tibble: 3 x 2
> colA colB
>
> 1 a 1
> 2 b 2
> 3 c 3
^Created on 2020-05-29 by the reprex package https://reprex.tidyverse.org (v0.3.0)
Help me understand why or when in particular I should be considering your package instead.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ropensci/software-review/issues/379#issuecomment-636010949, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEOYJODFVBZ6OI3SCNVDCDRT7CPXANCNFSM4NLHPSOA.
Hi,
Thanks, that's much better! We'll discuss with the rest of the editors and get back to you shortly.
Hello again @dmkaplan2000 .
After discussion, we decided that although interesting, the package is ultimately out of scope.
General tools for literate programming. (e.g., R markdown extensions) are out of scope and while exceptions might be made for extensions that have a very specific research application, we ultimately deemed knitrdata
too general for the rOpenSci scope.
Thanks again for your submission.
Hi,
Thanks for your message. While I respect your decision, I do see among the list of packages on the rOpenSci website at least one package that has quite similar goals to mine - making use of knitr for science richer and more flexible - and that is a knitr extension, just like mine:
https://docs.ropensci.org/ezknitr/
There is also RefManageR which is for literate programming. I don't really see why those packages are within the ropensci scope, but mine is not.
Cheers, David
On 6/5/20 12:16, Anna Krystalli wrote:
Hello again @dmkaplan2000 https://github.com/dmkaplan2000 .
After discussion, we decided that although interesting, the package is ultimately out of scope.
General tools for literate programming. (e.g., R markdown extensions) are out of scope and while exceptions might be made for extensions that have a very specific research application, we ultimately deemed |knitrdata| too general for the rOpenSci scope.
Thanks again for your submission.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ropensci/software-review/issues/379#issuecomment-639388869, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEOYJNZ3WWJ6TQJFAVJNI3RVDAYVANCNFSM4NLHPSOA.
Hi David,
Our scope definitions change over time. In the dev guide it does state that: “As this is a living document, these categories may change through time and not all previously onboarded packages would be in-scope today.”. This is the case with ezknitr
which was reviewed 4 years ago.
As for RefManageR
, it falls under the category "citation management and bibliometrics" which makes in scope.
I hope this clarifies our decision more.
Cheers
Anna
Submitting Author: @dmkaplan2000 Repository: dmkaplan2000/knitrdata Version submitted: 0.2.1 Editor: TBD Reviewer 1: TBD
Reviewer 2: TBD
Archive: TBD
Version accepted: TBD
Scope
Please indicate which category or categories from our package fit policies this package falls under: (Please check an appropriate box below. If you are unsure, we suggest you make a pre-submission inquiry.):
Explain how and why the package falls under these categories (briefly, 1-2 sentences):
knitrdata extends the capabilities of knitr to allow one to create chunks containing text and binary data directly in Rmarkdown documents. This opens the possibility of creating entirely self-contained Rmarkdown document capable of communicating data, methods, code, formatting and interpretation in a single document.
All scientific researchers aiming for computational reproducibility and open science.
Not to my knowledge.
Technical checks
Confirm each of the following by checking the box.
This package:
Publication options
JOSS Options
- [ ] The package has an **obvious research application** according to [JOSS's definition](https://joss.readthedocs.io/en/latest/submitting.html#submission-requirements). - [ ] The package contains a `paper.md` matching [JOSS's requirements](https://joss.readthedocs.io/en/latest/submitting.html#what-should-my-paper-contain) with a high-level description in the package root or in `inst/`. - [ ] The package is deposited in a long-term repository with the DOI: - (*Do not submit your package separately to JOSS*)MEE Options
- [X] The package is novel and will be of interest to the broad readership of the journal. - [X] The manuscript describing the package is no longer than 3000 words. - [X] You intend to archive the code for the package in a long-term repository which meets the requirements of the journal (see [MEE's Policy on Publishing Code](http://besjournals.onlinelibrary.wiley.com/hub/journal/10.1111/(ISSN)2041-210X/journal-resources/policy-on-publishing-code.html)) - (*Scope: Do consider MEE's [Aims and Scope](http://besjournals.onlinelibrary.wiley.com/hub/journal/10.1111/(ISSN)2041-210X/aims-and-scope/read-full-aims-and-scope.html) for your manuscript. We make no guarantee that your manuscript will be within MEE scope.*) - (*Although not required, we strongly recommend having a full manuscript prepared when you submit here.*) - (*Please do not submit your package separately to Methods in Ecology and Evolution*)Code of conduct