[PRE REVIEW]: Genetic code finder: Determine CUG codon usage in yeasts

[whedon]

Submitting author: @smuehlh (Stefanie Mühlhausen)
Repository: https://github.com/smuehlh/genetic-code-finder
Version: v1.0.0
Editor: Pending
Reviewer: Pending
Managing EiC: Daniel S. Katz

⚠️ JOSS reduced service mode ⚠️

Due to the challenges of the COVID-19 pandemic, JOSS is currently operating in a "reduced service mode". You can read more about what that means in our blog post.

Status

Status badge code:

HTML: <a href="https://joss.theoj.org/papers/1a337f12a01561b9169b68f30149af75"><img src="https://joss.theoj.org/papers/1a337f12a01561b9169b68f30149af75/status.svg"></a>
Markdown: [![status](https://joss.theoj.org/papers/1a337f12a01561b9169b68f30149af75/status.svg)](https://joss.theoj.org/papers/1a337f12a01561b9169b68f30149af75)

Author instructions

Thanks for submitting your paper to JOSS @smuehlh. Currently, there isn't an JOSS editor assigned to your paper.

@smuehlh if you have any suggestions for potential reviewers then please mention them here in this thread (without tagging them with an @). In addition, this list of people have already agreed to review for JOSS and may be suitable for this submission (please start at the bottom of the list).

Editor instructions

The JOSS submission bot @whedon is here to help you find and assign reviewers and start the main review. To find out what @whedon can do for you type:

@whedon commands

[whedon]

Hello human, I'm @whedon, a robot that can help you with some common editorial tasks.

⚠️ JOSS reduced service mode ⚠️

Due to the challenges of the COVID-19 pandemic, JOSS is currently operating in a "reduced service mode". You can read more about what that means in our blog post.

For a list of things I can do to help you, just type:

@whedon commands

For example, to regenerate the paper pdf after making changes in the paper's md or bib files, type:

@whedon generate pdf

[whedon]

Reference check summary (note 'MISSING' DOIs are suggestions that need verification):

OK DOIs

- 10.1038/nbt.1511 is OK
- 10.1016/j.cub.2018.04.085 is OK
- 10.1101/gr.200931.115 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[whedon]

Software report (experimental):

github.com/AlDanial/cloc v 1.88  T=0.02 s (977.9 files/s, 90093.6 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Ruby                            18            302            312           1154
Markdown                         2             55              0            141
R                                2             12             10             83
TeX                              1              2              0             48
-------------------------------------------------------------------------------
SUM:                            23            371            322           1426
-------------------------------------------------------------------------------


Statistical information for the repository '1e37699aefa022b218b9e615' was
gathered on 2021/06/12.
The following historical commit information, by author, was found:

Author                     Commits    Insertions      Deletions    % of changes
Stefanie Muehlhausen            20           791            291           42.97
Stefanie Mühlhausen             33          1352             84           57.03

Below are the number of rows from each author that have survived and are still
intact in the current revision:

Author                     Rows      Stability          Age       % in comments
Stefanie Muehlhausen        578           73.1          2.6               21.80
Stefanie Mühlhausen        1190           88.0          8.4               18.66

[whedon]

👉📄 Download article proof 📄 View article proof on GitHub 📄 👈

[danielskatz]

@smuehlh - Thanks for your submission. Due to the relatively small amount of code, the editors will now discuss if it meets the substantial scholarly effort criterion for review by JOSS. You should hear back in a week or so. I also ask that the editors look at the packaging.

[danielskatz]

@whedon query scope

[whedon]

Submission flagged for editorial review.

[arfon]

@smuehlh – many thanks for your submission to JOSS. After a review by our editorial team we have determined that this submission is out of scope for JOSS. The primary reason for this is that this code currently feels like a collection of standalone scripts, rather than software packaged in a way that is designed for others to easily reuse.

JOSS' submission guidelines state that your software must be designed for "maintainable extension" and it is our assessment that this repository currently falls well below this standard for Ruby. Please take a look at this guide on how to package software in Ruby as a Rubygem.

If you are able to make these changes, we'd welcome a resubmission.

[arfon]

@whedon reject

[whedon]

Paper rejected.

[smuehlh]

@arfon – many thanks for your assessment. Let me briefly comment on your main concerns.

First – on the code feeling like a collection of standalone scripts. Well, yes, the code is a collection of two (currently three, but I agree that there is no benefit in keeping scripts 2 and 3 separate and thus plan on merging those two) connected scripts. This design is on purpose, as the nature of the task requires a separation into two parts: First, a database for the mass spectrometry software MaxQuant needs to be generated. Then, this MaxQuant software needs to process experimental measurements against the precomputed database. Lastly, the vast MaxQuant output needs to be parsed for measurements of interest.
For a yeast with an average sized genome and peptide recall in mass spectrometry, both script parts may easily take several days to compute. In my humble opinion, a script for execution in shell works best for this run time and is flexible towards any setup between desktop machine and compute cluster.

We have proposed and published this workflow as part of our original publications on yeast genetic codes. Others (see, for example, https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5951914/) have picked up this suggestion and written their own set of custom scripts closely following our workflow. Thus, without any doubt others have found our workflow useful and would have benefitted from our scripts. While this group already has their own set of custom scripts, other groups might yet benefit from ours. Besides the actual standalone scripts, our code contains a library for interaction with MaxQuant output that can easily be used for mass spectrometry analysis beyond CUG usage in yeasts.

Second – on design for maintainable extension. I agree on Ruby Gems being generally the way to go for maintainable extensions. I could envision turning parts of the library this code comes with (namely those classes parsing MaxQuant output) into a Ruby Gem. However, I fail to see the advantage of turning the whole code base into a Ruby Gem. Given the nature of the task, i.e. the need to call an external, computationally intensive software in between, the Ruby Gem would still have to have two executables. The only difference to the current code would be calling the executables as scriptname [options] vs ruby scriptname.rb [options]. I don’t think this warrants the changes necessary.

Would you reconsider your decision given I follow through with the changes proposed above?