Joss-reviews: [REVIEW]: malan: MAle Lineage ANalysis

[whedon]

Submitting author: @mikldk (Mikkel Meyer Andersen)
Repository: https://github.com/mikldk/malan
Version: v1.0.0
Editor: @brainstorm
Reviewer: @afrubin, @ajank
Archive: 10.5281/zenodo.1241769

Status

Status badge code:

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

Reviewers and authors:

Please avoid lengthy details of difficulties in the review thread. Instead, please create a new issue in the target repository and link to those issues (especially acceptance-blockers) in the review thread below. (For completists: if the target issue tracker is also on GitHub, linking the review thread in the issue or vice versa will create corresponding breadcrumb trails in the link target.)

Reviewer instructions & questions

@afrubin & @ajank, please carry out your review in this issue by updating the checklist below. If you cannot edit the checklist please:

1. Make sure you're logged in to your GitHub account
2. Be sure to accept the invite at this URL: https://github.com/openjournals/joss-reviews/invitations

The reviewer guidelines are available here: https://joss.theoj.org/about#reviewer_guidelines. Any questions/concerns please let @brainstorm know.

Review checklist for @ajank

Conflict of interest

• [x] As the reviewer I confirm that I have read the JOSS conflict of interest policy and that there are no conflicts of interest for me to review this work.

Code of Conduct

• [x] I confirm that I read and will adhere to the JOSS code of conduct.

General checks

• [x] Repository: Is the source code for this software available at the repository url?
• [x] License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• [x] Version: Does the release version given match the GitHub release (v0.0.3)?
• [x] Authorship: Has the submitting author (@mikldk) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

Functionality

• [x] Installation: Does installation proceed as outlined in the documentation?
• [x] Functionality: Have the functional claims of the software been confirmed?
• [x] Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

• [x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• [x] Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
• [x] Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• [x] Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
• [x] Automated tests: Are there automated tests or manual steps described so that the function of the software can be verified?
• [x] Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Software paper

• [x] Authors: Does the paper.md file include a list of authors with their affiliations?
• [x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• [x] References: Do all archival references that should have a DOI list one (e.g., papers, datasets, software)?

Review checklist for @afrubin

Conflict of interest

• [x] As the reviewer I confirm that I have read the JOSS conflict of interest policy and that there are no conflicts of interest for me to review this work.

Code of Conduct

• [x] I confirm that I read and will adhere to the JOSS code of conduct.

General checks

• [x] Repository: Is the source code for this software available at the repository url?
• [x] License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• [x] Version: Does the release version given match the GitHub release (v0.0.3)?
• [x] Authorship: Has the submitting author (@mikldk) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

Functionality

• [x] Installation: Does installation proceed as outlined in the documentation?
• [x] Functionality: Have the functional claims of the software been confirmed?
• [x] Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

• [x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• [x] Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
• [x] Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• [x] Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
• [x] Automated tests: Are there automated tests or manual steps described so that the function of the software can be verified?
• [x] Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Software paper

• [x] Authors: Does the paper.md file include a list of authors with their affiliations?
• [x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• [x] References: Do all archival references that should have a DOI list one (e.g., papers, datasets, software)?

[whedon]

Hello human, I'm @whedon. I'm here to help you with some common editorial tasks. @afrubin it looks like you're currently assigned as the reviewer for this paper :tada:.

:star: Important :star:

If you haven't already, you should seriously consider unsubscribing from GitHub notifications for this (https://github.com/openjournals/joss-reviews) repository. As a reviewer, you're probably currently watching this repository which means for GitHub's default behaviour you will receive notifications (emails) for all reviews 😿

To fix this do the following two things:

1. Set yourself as 'Not watching' https://github.com/openjournals/joss-reviews:

1. You may also like to change your default settings for this watching repositories in your GitHub profile here: https://github.com/settings/notifications

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

@whedon commands

[whedon]

Attempting PDF compilation. Reticulating splines etc...

[whedon]

--> Check article proof :page_facing_up: <--

[mikldk]

Thanks @afrubin and @ajank for being able and willing to review! Please let me know if you have any questions or if I can provide any support.

[mikldk]

@whedon commands

[whedon]

Here are some things you can ask me to do:

# List all of Whedon's capabilities
@whedon commands

# Assign a GitHub user as the sole reviewer of this submission
@whedon assign @username as reviewer

# Add a GitHub user to the reviewers of this submission
@whedon add @username as reviewer

# Remove a GitHub user from the reviewers of this submission
@whedon remove @username as reviewer

# List of editor GitHub usernames
@whedon list editors

# List of reviewers together with programming language preferences and domain expertise
@whedon list reviewers

# Change editorial assignment
@whedon assign @username as editor

# Set the software archive DOI at the top of the issue e.g.
@whedon set 10.0000/zenodo.00000 as archive

# Open the review issue
@whedon start review

🚧 🚧 🚧 Experimental Whedon features 🚧 🚧 🚧

# Compile the paper
@whedon generate pdf

[mikldk]

@whedon generate pdf

[whedon]

Attempting PDF compilation. Reticulating splines etc...

[whedon]

--> Check article proof :page_facing_up: <--

[mikldk]

@brainstorm / @arfon, I had an awfully embarrassing typo with a missing "a" in the title (ANlysis / ANalysis). I have updated my paper.md in my repo and had @whedon recompile proofs. Can you change the title in the submission (including the title of this issue -> "malan: MAle Lineage ANalysis").

[arfon]

Can you change the title in the submission (including the title of this issue -> "malan: MAle Lineage ANalysis").

Fixed here. The version on the main JOSS site will be updated when the submission is processed.

[arfon]

@afrubin, @ajank - please remember to complete your review by updating the checklist above.

[ajank]

@mikldk, you may wish to fix the typo in the description at https://github.com/mikldk/malan as well.

[mikldk]

@ajank , yes, indeed. Thanks for catching that.

[mikldk]

@ajank , also thanks for your suggestions, they er now all addressed.

[ajank]

@mikldk, it seems that instant reviewer feedback might have its downsides -- when the author addresses all the reviewer's comments, only to find out that the reviewer hasn't finished yet, and may have more comments coming a few days later. Anyway, many thanks for the prompt feedback, and sorry for the longer response time on my side!

[mikldk]

@ajank , Sorry, but I don't understand what you mean. Do you mean that it would be easier for you that I had waited until you said you were finished? In that case, I am sorry. I thought it was easier to do the changes and notify you about them instantly. Sorry about that.

[ajank]

@mikldk, maybe I should have added a smiley here ;) being new to JOSS, it was an experience on its own for me! No need to worry :)

[mikldk]

@ajank , me too :). Thanks for your help.

[ajank]

@brainstorm, it was a very nice experience to review this paper. I has some minor suggestions to clarify the documentation and code. My comments were all properly addressed. It is with pleasure that I recommend it to be accepted.

[brainstorm]

Thanks @ajank, I'll wait for @afrubin to go ahead with his co-review and complete his share of checkboxes.

[afrubin]

@mikldk Thanks for your prompt response to the build-related GitHub issues. There are a few JOSS-specific things I'd like to bring up here, as they are relate to the checklist rather than the code itself.

• The package version matches, but there is no GitHub release with that version number.
• While the installation instructions are clear and dependencies are handled by R, dependencies in the DESCRIPTION should be listed in the documentation.
• I didn't see a Zenodo or similar link stable to the release version of the software. This should be created and provided in the paper.

[mikldk]

@afrubin Thank you very much.

• Github release: Sorry. Now, there is: https://github.com/mikldk/malan/releases/tag/0.0.3
• Dependencies: Added in mikl/malan@d92e8f35ca1f72b972c988ed49a335af49b60869.
• Zenodo: Sorry, now, there is: https://zenodo.org/record/1240896 / DOI: 10.5281/zenodo.1240896 http://doi.org/10.5281/zenodo.1240896 (DOI doesn't work, yet)

[mikldk]

@brainstorm For some reason it seems like I can edit the reviewers checklists (I haven't dared trying, but the checkboxes are not disabled).

@afrubin Stupid question: So now that the version 0.0.3 is locked and have a DOI number. What happens if there is now any blocking changes that I need to do in this review? Do the changes, delete the Github release and create that same 0.0.3 again? And when the paper is hopefully accepted at some point, I should increment the version number for future changes, to e.g. 0.0.4 or whatever, right? Or how should this version numbering / DOI / publishing workflow be done?

[afrubin]

@mikldk If there are changes that need to be made during the review, it is simple enough to change the version number (e.g. to 0.0.4 or 0.0.3.1) and update the version number and DOI in the manuscript. IMO the manuscript should reflect the most current version at the time of acceptance and there's no reason why it has to match 0.0.3.

As for version numbering post-acceptance, Zenodo will automatically generate a new DOI for you. I don't think that the manuscript needs to be updated.

Zenodo does make it easy to give the right DOI and version in future publications that use the software, and you should consider adding the Zenodo badge next to your Travis badge in the README.

[mikldk]

@afrubin Thanks. But if I now add a badge then that change will not be in the release. But maybe it doesn't matter dor such small changes?

[arfon]

@afrubin Thanks. But if I now add a badge then that change will not be in the release. But maybe it doesn't matter dor such small changes?

I think it's OK for the release number we're quoting here not to have the badge in the README.

[mikldk]

@afrubin I hope that I have now addressed all your remarks.

I have updated the software to version 1.0.0 including DESCRIPTION and codemeta.json as well as made a new release at Github and updated README with the new DOI from Zenodo. I also updated paper.md (date and a new keyword).

@afrubin and @ajank : Thank you both for helping me improving the software. Should you have any more comments, please let me know either here or by opening a new issue in malan's repository.

[afrubin]

@mikldk All of the major outstanding issues have been addressed and I am happy for the paper to proceed to the next stages. Thank your quick feedback and assistance with the Mac OS build issues in particular. The documentation has improved quite a lot during the review, and I hope that this will help your future users.

There are two very minor points that I think should be addressed before publication:

• The version of the software being published is now 1.0.0 instead of 0.0.3
• The Zenodo DOI for the 1.0.0 release should be included in the paper.md (@arfon is this done automatically when the PDF is built?)

[mikldk]

@afrubin

The version of the software being published is now 1.0.0 instead of 0.0.3

I changed it the places I could find the versioning mentioned. Is there anywhere I can help here or do you mean JOSS internally (e.g. version mentioned in this issue)?

[afrubin]

@mikldk I think the only place the version needs to be changed is in the JOSS metadata. The repository looks fine. The relevant checkbox above reads:

Version: Does the release version given match the GitHub release (v0.0.3)?

This may be beyond our control.

[mikldk]

@afrubin You haven't checked the References part. Am I missing something there, you think? Or is it related to the versioning?

[afrubin]

Or is it related to the versioning?

@mikldk I hadn't checked this because I didn't see the DOI for the package in the paper, but having looked at some published JOSS papers, it does appear that it's added automatically to the PDF. I've now checked this box.

[arfon]

Thanks folks. I've gone ahead and marked the version as v1.0.0 at the top of the issue.

@brainstorm - I think we're good to accept here?

[arfon]

@whedon set 10.5281/zenodo.1241769 as archive

[whedon]

OK. 10.5281/zenodo.1241769 is the archive.

[brainstorm]

Thanks everyone! Closing the issue, everything looks fine to me, @arfon, do your DOI publishing magic ;)

[mikldk]

Thanks!

@arfon : I hereby remind you about #679: the footer in the pdf article proof contains the Markdown markup. Can you remove this?

[arfon]

Thanks everyone! Closing the issue, everything looks fine to me, @arfon, do your DOI publishing magic ;)

Thanks @brainstorm - please don't close these until I've wrapped up the last few steps. :-)

[arfon]

@afrubin, @ajank - many thanks for your reviews and to @brainstorm for editing this submission ✨

@mikldk - your paper is now accepted into JOSS and your DOI is https://doi.org/10.21105/joss.00684 :zap: :rocket: :boom:

[whedon]

:tada::tada::tada: Congratulations on your paper acceptance! :tada::tada::tada:

If you would like to include a link to your paper from your README use the following code snippet:

[![DOI](http://joss.theoj.org/papers/10.21105/joss.00684/status.svg)](https://doi.org/10.21105/joss.00684)

This is how it will look in your documentation:

We need your help!

Journal of Open Source Software is a community-run journal and relies upon volunteer effort. If you'd like to support us please consider doing either one (or both) of the the following:

• Volunteering to review for us sometime in the future. You can add your name to the reviewer list here: http://joss.theoj.org/reviewer-signup.html
• Making a small donation to support our running costs here: https://www.flipcause.com/secure/cause_pdetails/Mjk3Nzk=