Submission: beautier #208
The purpose of
[e.g., "data extraction, because the package parses a scientific data file format"]
reproducibility, as it provides a way to script a configuration file, as an alternative to an error-prone (and tedious) GUI tool
Scientists that use the tool 'BEAST2' to do a Bayesian phylogenetic inference on DNA data.
Confirm each of the following by checking the box. This package:
Klaus Schliep, KlausVigo
The text was updated successfully, but these errors were encountered:
I assume the better order would be to get the packages accepted by rOpenSci, then publish, but my supervisor does not see the added value of rOpenSci and thus wanted to get the article out ASAP.
As I do appreciate the feedback on my work and the ideology behind rOpenSci, I submit to rOpenSci nevertheless (in my spare time).
Thanks for your submission, @richelbilderbeek! An initial question as we discuss this: can you tell us a bit about your logic for splitting up these functions into different packages? I can see reasons either way - doing One Thing Well and separating, or keeping together to maintain a common workflow. Just curious how you see it as we think about the best way to use reviewer's time without overwhelming them, and also make sure that there is good feedback about the likely use cases of using these packages in tandem.
Thanks for you question, @noamross!
Sure, I'd be happy to help!
I hope this table will clear things up:
As can be seen, each sub-package replaces a GUI or command-line tool (and is named after that tool). It follows the Do One Thing Well idea, and forced me in having no cycling dependencies. The bigger package,
What would be best not to overwhelm reviewers, I do not know. I think 3 out of 4 packages are easily reviewed, as here are the Single Line of Code counts (only files in
Whatever the choice or whatever I need to do, I'd be happy to have some feedback about my work.
Does this answer your question sufficiently?
Thanks, @richelbilderbeek! That helps. After conferring, we've decided it would be best to submit all four as a single submission. The joint workflow will be important and in the end its not that much more (relative) lines of code than
Since this will be a big review, we might assign a little more time than the standard 3 weeks to reviewers. I also hope you can make things smoother by pre-running
We also generally recommend going through review before submitting to CRAN, as review often includes recommendations for breaking changes to the API, and we don't consider being on CRAN reason not to change these. Review usually also catches snafus that will hold up the CRAN submission process, too.
If that all makes sense, close this issue and open a new one for
Happy my table helped @noamross !
I will follow your guidance, close this Issue and make a new one for
(edit: fix typo)