PONE-D-20-37776

Easyreporting simplifies the implementation of Reproducible Research Layers in R software

PLOS ONE

Dear Dr. Righelli,

Thank you for submitting your manuscript to PLOS ONE. After careful consideration, we feel that it has merit but does not fully meet PLOS ONE’s publication criteria as it currently stands. Therefore, we invite you to submit a revised version of the manuscript that addresses the points raised during the review process. Please take care all comments and points raised by the reviewers.

Please submit your revised manuscript by Mar 20 2021 11:59PM. If you will need more time than this to complete your revisions, please reply to this message or contact the journal office at plosone@plos.org. When you're ready to submit your revision, log on to https://www.editorialmanager.com/pone/ and select the 'Submissions Needing Revision' folder to locate your manuscript file.

Please include the following items when submitting your revised manuscript:

• A rebuttal letter that responds to each point raised by the academic editor and reviewer(s). You should upload this letter as a separate file labeled 'Response to Reviewers'.
• A marked-up copy of your manuscript that highlights changes made to the original version. You should upload this as a separate file labeled 'Revised Manuscript with Track Changes'.
• An unmarked version of your revised paper without tracked changes. You should upload this as a separate file labeled 'Manuscript'.

If you would like to make changes to your financial disclosure, please include your updated statement in your cover letter. Guidelines for resubmitting your figure files are available below the reviewer comments at the end of this letter.

If applicable, we recommend that you deposit your laboratory protocols in protocols.io to enhance the reproducibility of your results. Protocols.io assigns your protocol its own identifier (DOI) so that it can be cited independently in the future. For instructions see: http://journals.plos.org/plosone/s/submission-guidelines#loc-laboratory-protocols

We look forward to receiving your revised manuscript.

Kind regards,

Eduardo Andrés-León

Academic Editor

PLOS ONE

When submitting your revision, we need you to address these additional requirements.

1. Please ensure that your manuscript meets PLOS ONE's style requirements, including those for file naming. The PLOS ONE style templates can be found at

https://journals.plos.org/plosone/s/file?id=wjVg/PLOSOne_formatting_sample_main_body.pdf and

https://journals.plos.org/plosone/s/file?id=ba62/PLOSOne_formatting_sample_title_authors_affiliations.pdf

[Note: HTML markup is below. Please do not edit.]

Reviewers' comments:

Reviewer's Responses to Questions

Comments to the Author

1. Is the manuscript technically sound, and do the data support the conclusions?

The manuscript must describe a technically sound piece of scientific research with data that supports the conclusions. Experiments must have been conducted rigorously, with appropriate controls, replication, and sample sizes. The conclusions must be drawn appropriately based on the data presented.

Reviewer #1: Yes

Reviewer #2: Yes

**********

2. Has the statistical analysis been performed appropriately and rigorously?

Reviewer #1: N/A

Reviewer #2: N/A

**********

3. Have the authors made all data underlying the findings in their manuscript fully available?

The PLOS Data policy requires authors to make all data underlying the findings described in their manuscript fully available without restriction, with rare exception (please refer to the Data Availability Statement in the manuscript PDF file). The data should be provided as part of the manuscript or its supporting information, or deposited to a public repository. For example, in addition to summary statistics, the data points behind means, medians and variance measures should be available. If there are restrictions on publicly sharing data—e.g. participant privacy or use of data from a third party—those must be specified.

Reviewer #1: Yes

Reviewer #2: Yes

**********

4. Is the manuscript presented in an intelligible fashion and written in standard English?

PLOS ONE does not copyedit accepted manuscripts, so the language in submitted articles must be clear, correct, and unambiguous. Any typographical or grammatical errors should be corrected at revision, so please note any specific errors here.

Reviewer #1: Yes

Reviewer #2: Yes

**********

5. Review Comments to the Author

Please use the space provided to explain your answers to the questions above. You may also include additional comments for the author, including concerns about dual publication, research ethics, or publication ethics. (Please upload your review as an attachment if it exceeds 20,000 characters)

Reviewer #1: I have been reading your manuscript, as well as have had a look at `easyreporting` code. As you have already stated, this R package is focused on human-focused reports generation which help on research reproducibility. So, which strategy would you recommend to generate reports which involve mixed scenarios, like running a first part of R code which generates both intermediate and final results, a second part which uses these results with one or more web services or third party tools, getting additional results, and a last part of R code which uses as input a selection of the previous result files? I guess you could generate a report for the R dependent parts, but I'm missing your recommendation for this kind of scenario in the manuscript or in supplementary materials. I'm also missing some clearer hints to the readers of your manuscript related to provenance tracking or provenance injection in the generated report which help to obtain all the supplementary data needed to successfully reproduce the analysis.

Page 3, paragraph starting at line 73. I agree that it is relevant for the end user realizing that an analysis report is an instance of `easyreporting`, but is relevant for the end user of the package to learn the technical detail of `easyreporting` being structured as an S4 class (http://adv-r.had.co.nz/S4.html)?

I have also been having a look at the supplementary materials 1, and its associated repository https://github.com/drighelli/easyreporting_supplementary , and I have found an issue against reproducibility outside the installation where the report was generated. The file `rnaseq_report_live.Rmd` at `Report_files` directory, generated from `report.R` (on the same directory), has next sentence on each of its codeblocks

source("/Library/Frameworks/R.framework/Versions/4.0/Resources/library/easyreporting/script/importFunctions.R")

(permalink to first occurrence https://github.com/drighelli/easyreporting_supplementary/blob/ef9e498d4eb431dd488cc7db615a4c3fe3d19e1f/Report_files/rnaseq_report_live.Rmd#L15 )

That sentence has an absolute path, derived from

mkdCodeChunkSt(bioEr, sourceFilesList=system.file("script/importFunctions.R", package="easyreporting"), isComplete=TRUE)

(permalink https://github.com/drighelli/easyreporting_supplementary/blob/ef9e498d4eb431dd488cc7db615a4c3fe3d19e1f/Report_files/report.R#L11 )

so it limits the reproducibility, as codeblocks cannot be run as is. It would not work in a Linux or a Windows installation without a extensive revision, for instance. Also, the report could disclose sensitive data related to these absolute paths.

I have several recommendation for future releases of `easyreporting`. In analyses with more than one author, package should allow showing all of them on the generated reports. I'm also missing richer ways to attach metadata related to an specific analysis:

* `easyreporting` should provide a mechanism to attach the optional ORCID, Researcher Id or similar of each author, in order to avoid ambiguity among researchers with similar names.

* The report could optionally contain a list of used files in the analysis, both sourced scripts and input files, along with their digest. This could help identifying whether the report is stale because either the scripts or input files have changed.

* I'm missing some specific method which allows injecting high level annotations about the inputs. If some analysis depends on specific public or under request data which are not provided by R / Bioconductor packages, there should be a standardized or, at least, recommended way to tell where to find those inputs, or publicly accepted identifiers associated to the data (i.e. EGA or COSMIC ids, DOIs, etc...). These annotations in the generated report would help a lot when some researcher tries to reproduce the described analysis, but it depends on the report authors' collaboration.

Reviewer #2: The authors present a new R package to facilitate the creation of reproducible research reports. Their package can be added to a growing number of resources for this important task and it's commendable that researches from within the *omics are investing time and ingenuity to improve the mechanics of the modern, largely computational scientific process in these fields.

So while this is by itself a great goal, the paper did not convince me that the suggested workflow for reporting script based analysis is superior to using simple RMarkdown reports. RMarkdown is not (!) a complicated markup language and learning it appears to me less involved then using the easyreporting wrapper functions, which add another layer of complexity to the already long RMarkdown rendering pipeline. So I would suggest to the authors not to focus on this first (rather theoretical) usecase of easyreporting, but to go all in on the second one, which is the ability to add a reporting level to Shiny applications. Here the paper presents indeed a novel solution which might be relevant AND practical. Of course the paper then only addresses the admittedly small group of R Shiny developers, but again I do not see how normal R users outside of this circle would benefit from the suggested additional layer on top of RMarkdown.

So accordingly I suggest to change the title, wording and section order of the paper to emphasise the Shiny-enhancing feature of the package. Here I would also ask the authors to state more clearly that this is only intended to work with Shiny apps, not any GUI framework. Shiny is of course only one of many GUI systems and it should be clear from the beginning that easyreporting can only provide a human-readable logging system for this specific one. Shiny is simple and popular at the moment, but also too slow and fickle for many of the large-data applications in the *omics.

These were my main comments. Finally a list of minor observations:

- I think it would be better to speak more generally about "virtualisation solutions such as Docker containers" instead of "dockers". The authors should add a reference to a paper explaining these solutions. I never read the term "dockers" for "Docker containers".

- As the authors present a new R package they should make it clear in the introduction which package version the paper describes exactly.

- The text in the subsection "easyreporting for GUI implementation" is a duplication of the text in the caption for figure 2. The figure caption can be shortened.

- The code in strings for mkdCodeChkunkSt, mkdVariableAssignment, etc. is not a good solution, because it makes writing the respective code tricky (no syntax highlighting etc.). Maybe the authors could come up with a better implementation based on base::quote() or base::deparse().

b <- quote({

a <- 1 + 2

a + a

})

format(b)

eval(b)

I am not qualified to review the scientific validity of the case study presented in the supplementary material.

**********

6. PLOS authors have the option to publish the peer review history of their article (what does this mean?). If published, this will include your full peer review and any attached files.

If you choose “no”, your identity will remain anonymous but your review may still be made public.

Do you want your identity to be public for this peer review? For information about this choice, including consent withdrawal, please see our Privacy Policy.

Reviewer #1: Yes: José M. Fernández

Reviewer #2: No

[NOTE: If reviewer comments were submitted as an attachment file, they will be attached to this email and accessible via the submission site. Please log into your account, locate the manuscript record, and check for the action link "View Attachments". If this link does not appear, there are no attachment files.]

While revising your submission, please upload your figure files to the Preflight Analysis and Conversion Engine (PACE) digital diagnostic tool, https://pacev2.apexcovantage.com/. PACE helps ensure that figures meet PLOS requirements. To use PACE, you must first register as a user. Registration is free. Then, login and navigate to the UPLOAD tab, where you will find detailed instructions on how to use the tool. If you encounter any issues or have any questions when using PACE, please email PLOS at figures@plos.org. Please note that Supporting Information files do not need this step.

Easyreporting simplifies the implementation of Reproducible Research Layers in R software

PONE-D-20-37776R1

Dear Dr. Righelli,

We’re pleased to inform you that your manuscript has been judged scientifically suitable for publication and will be formally accepted for publication once it meets all outstanding technical requirements.

Within one week, you’ll receive an e-mail detailing the required amendments. When these have been addressed, you’ll receive a formal acceptance letter and your manuscript will be scheduled for publication.

An invoice for payment will follow shortly after the formal acceptance. To ensure an efficient process, please log into Editorial Manager at http://www.editorialmanager.com/pone/, click the 'Update My Information' link at the top of the page, and double check that your user information is up-to-date. If you have any billing related questions, please contact our Author Billing department directly at authorbilling@plos.org.

If your institution or institutions have a press office, please notify them about your upcoming paper to help maximize its impact. If they’ll be preparing press materials, please inform our press team as soon as possible -- no later than 48 hours after receiving the formal acceptance. Your manuscript will remain under strict press embargo until 2 pm Eastern Time on the date of publication. For more information, please contact onepress@plos.org.

Kind regards,

Eduardo Andrés-León

Academic Editor

PLOS ONE

Additional Editor Comments (optional):

Please take into account the comments regarding the R versions

Reviewers' comments:

Reviewer's Responses to Questions

Comments to the Author

1. If the authors have adequately addressed your comments raised in a previous round of review and you feel that this manuscript is now acceptable for publication, you may indicate that here to bypass the “Comments to the Author” section, enter your conflict of interest statement in the “Confidential to Editor” section, and submit your "Accept" recommendation.

Reviewer #1: All comments have been addressed

Reviewer #2: All comments have been addressed

**********

2. Is the manuscript technically sound, and do the data support the conclusions?

The manuscript must describe a technically sound piece of scientific research with data that supports the conclusions. Experiments must have been conducted rigorously, with appropriate controls, replication, and sample sizes. The conclusions must be drawn appropriately based on the data presented.

Reviewer #1: Yes

Reviewer #2: (No Response)

**********

3. Has the statistical analysis been performed appropriately and rigorously?

Reviewer #1: N/A

Reviewer #2: (No Response)

**********

4. Have the authors made all data underlying the findings in their manuscript fully available?

The PLOS Data policy requires authors to make all data underlying the findings described in their manuscript fully available without restriction, with rare exception (please refer to the Data Availability Statement in the manuscript PDF file). The data should be provided as part of the manuscript or its supporting information, or deposited to a public repository. For example, in addition to summary statistics, the data points behind means, medians and variance measures should be available. If there are restrictions on publicly sharing data—e.g. participant privacy or use of data from a third party—those must be specified.

Reviewer #1: Yes

Reviewer #2: (No Response)

**********

5. Is the manuscript presented in an intelligible fashion and written in standard English?

PLOS ONE does not copyedit accepted manuscripts, so the language in submitted articles must be clear, correct, and unambiguous. Any typographical or grammatical errors should be corrected at revision, so please note any specific errors here.

Reviewer #1: Yes

Reviewer #2: (No Response)

**********

6. Review Comments to the Author

Please use the space provided to explain your answers to the questions above. You may also include additional comments for the author, including concerns about dual publication, research ethics, or publication ethics. (Please upload your review as an attachment if it exceeds 20,000 characters)

Reviewer #1: I have read the revised manuscript and supplementary materials, as well as the solutions and answers to each one of the issues from the referees. When I read that easyreporting release 3.12 will appear on ongoing Bioconductor 3.13, I went to https://bioconductor.org/developers/release-schedule/ , and I realized Bioconductor 3.13 will be tied to R-4.1.0, which will be released maybe on 2021-05-18. So, I started wondering how backward compatible are usually bioconductor packages, in terms of R language and dependences on other package.

So, my question to you is, how backward compatible is easyreporting? Could release 1.3.2 of easyreporting be used in R 4.0.x or 3.6.x , for instance? File https://github.com/drighelli/easyreporting/blob/master/DESCRIPTION is not declaring any minimal version of R, but for instance one of its imports, rlang, depends at least on R >= 3.3.0

Page 6, line 174: I guess there is an unescaped LaTeX underscore in the URL, as it should be https://github.com/drighelli/easyreporting_supplementary

Reviewer #2: (No Response)

**********

7. PLOS authors have the option to publish the peer review history of their article (what does this mean?). If published, this will include your full peer review and any attached files.

If you choose “no”, your identity will remain anonymous but your review may still be made public.

Do you want your identity to be public for this peer review? For information about this choice, including consent withdrawal, please see our Privacy Policy.

Reviewer #1: Yes: José M. Fernández

Reviewer #2: No