-
-
Notifications
You must be signed in to change notification settings - Fork 104
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
Submission: beautier #208
Comments
Note that:
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). |
This package is in the process of being accepted by CRAN. |
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
If reviewing 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) |
Summary
The purpose of
beautier
is to create a valid BEAST2 XML input file from its function arguments. In this way, a scientific pipeline usingBEAST2
can be fully scripted, instead of usingBEAUti
's GUI.https://github.com/richelbilderbeek/beautier
[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.
yours differ or meet our criteria for best-in-category?
No
Requirements
Confirm each of the following by checking the box. This package:
Publication options
paper.md
matching JOSS's requirements with a high-level description in the package root or ininst/
.Detail
Does
R CMD check
(ordevtools::check()
) succeed? Paste and describe any errors or warnings:Does the package conform to rOpenSci packaging guidelines? Please describe any exceptions:
If this is a resubmission following rejection, please explain the change in circumstances:
If possible, please provide recommendations of reviewers - those with experience with similar packages and/or likely users of your package - and their GitHub user names:
Klaus Schliep, KlausVigo
Luke Harmon, lukejharmon
Jonathan Eastman, eastman
Joseph W. Brown, josephwb
The text was updated successfully, but these errors were encountered: