Submission: beautier

[richelbilderbeek]

Summary

• What does this package do? (explain in 50 words or less):

The purpose of beautier is to create a valid BEAST2 XML input file from its function arguments. In this way, a scientific pipeline using BEAST2 can be fully scripted, instead of using BEAUti's GUI.

• Paste the full DESCRIPTION file inside a code block below:

Package: beautier
Title: 'BEAUti' from R
Version: 1.13
Date: 2018-03-16
Author: Richel J.C. Bilderbeek <richel@richelbilderbeek.nl>
Maintainer: Richel J.C. Bilderbeek <richel@richelbilderbeek.nl>
Description: 'BEAST2' (<http://www.beast2.org>) is a widely used
  Bayesian phylogenetic tool, that uses DNA/RNA/protein data
  and many model priors to create a posterior of jointly estimated 
  phylogenies and parameters.
  'BEAUti 2' (which is part of 'BEAST2') is a GUI tool 
  that allows users to specify the many possible setups
  and generates the XML file 'BEAST2' needs to run.
  This package provides a way to create 'BEAST2' input
  files without active user input, but using
  R function calls instead.
License: GPL-3 | file LICENSE
LazyData: true
RoxygenNote: 6.0.1
VignetteBuilder: knitr
URL: https://github.com/richelbilderbeek/beautier
BugReports: https://github.com/richelbilderbeek/beautier/issues
Imports:
    ape,
    geiger,
    seqinr,
    stringr,
    testit
Suggests:
    devtools,
    knitr,
    ggplot2,
    lintr,
    rmarkdown,
    testthat

• URL for the package (the development repository, not a stylized html page):

https://github.com/richelbilderbeek/beautier

• Please indicate which category or categories from our package fit policies this package falls under *and why(? (e.g., data retrieval, reproducibility. If you are unsure, we suggest you make a pre-submission inquiry.):

[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

•   Who is the target audience and what are scientific applications of this package?  

Scientists that use the tool 'BEAST2' to do a Bayesian phylogenetic inference on DNA data.

• Are there other R packages that accomplish the same thing? If so, how does
  yours differ or meet our criteria for best-in-category?

No

•   If you made a pre-submission enquiry, please paste the link to the corresponding issue, forum post, or other discussion, or @tag the editor you contacted.

Requirements

Confirm each of the following by checking the box. This package:

• does not violate the Terms of Service of any service it interacts with.
• has a CRAN and OSI accepted license.
• contains a README with instructions for installing the development version.
• includes documentation with examples for all functions.
• contains a vignette with examples of its essential functions and uses.
• has a test suite.
• has continuous integration, including reporting of test coverage, using services such as Travis CI, Coveralls and/or CodeCov.
• I agree to abide by ROpenSci's Code of Conduct during the review process and in maintaining my package should it be accepted.

Publication options

• Do you intend for this package to go on CRAN?
• Do you wish to automatically submit to the Journal of Open Source Software? If so:
  • The package has an obvious research application according to JOSS's definition.
  • The package contains a paper.md matching JOSS's requirements 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)
• Do you wish to submit an Applications Article about your package to Methods in Ecology and Evolution? If so:
  • The package is novel and will be of interest to the broad readership of the journal.
  • The manuscript describing the package is no longer than 3000 words.
  • 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)
  • (Scope: Do consider MEE's Aims and Scope for your manuscript. We make no gaurantee that your manuscript willl 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)

Detail

• Does R CMD check (or devtools::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

[richelbilderbeek]

Note that:

• The package is one of the three sub-packages of the package babette. I intend to have all these packages on rOpenSci. If it would be more convenient to submit the superpackage babette here instead, I'd be happy to do so
• There is already an article about babette in pre-print at bioRxiv. The article (in the section 'Applications') is already submitted to Methods in Ecology and Evolution

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

[richelbilderbeek]

This package is in the process of being accepted by CRAN.

[noamross]

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.

[richelbilderbeek]

Thanks for you question, @noamross!

Sure, I'd be happy to help!

I hope this table will clear things up:

Step	Package	Tool
Configuration	beautier	BEAUti 2 (GUI)
Running	beastier	BEAST2 (command-line interface)
Parsing and analysing results	tracerer	Tracer (GUI)
---	---	---
All of these	babette	None

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, babette (a mix of the three subpackages' names), stitches these three packages together to do the full workflow.

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 /R folder, includes Doxygen lines):

package	SLOC
beautier	11695
beastier	896
tracerer	872
---	---
babette	272

If reviewing babette only/first would be best depends on -I think- on the administrative machinery behind the review process.

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?

[noamross]

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

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 goodpractice::gp() on your packages to catch things that would likely be flagged in editor checks.

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 babette when you are ready, specifying in the text that the review is actually for all four packages.

[richelbilderbeek]

Happy my table helped @noamross !

• About goodpractice::gp(): I already run that on my code, using Travis CI. Code coverage is 100%.
• About CRAN: this has been put on hold, so I can now submit there after the rOpenSci review

I will follow your guidance, close this Issue and make a new one for babette.

(edit: fix typo)