[REVIEW]: Git-RDM: A research data management plugin for the Git version control system

[whedon]

Submitting author: @ctjacobs (Christian T. Jacobs)
Repository: https://github.com/ctjacobs/git-rdm
Version: v1.0.0
Editor: @arfon
Reviewer: @jsta
Archive: 10.6084/m9.figshare.3443750.v1

Status

Status badge code:

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

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v1.0.0)?
• Archive: Does the software archive resolve?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
• Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• Functionality documentation: Is the functionality of the software documented to a satisfactory level (e.g. API method documentation)?
• Automated tests: Are there automated tests or manual steps described so that the function of the software can be verified?
• 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

Paper PDF: 10.21105.joss.00029.pdf

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

[arfon]

/ cc @openjournals/joss-reviewers - would anyone be willing to review this submission?

If you would like to review this submission then please comment on this thread so that others know you're doing a review (so as not to duplicate effort). Something as simple as :hand: I am reviewing this will suffice.

Reviewer instructions

• Please work through the checklist at the start of this issue.
• If you need any further guidance/clarification take a look at the reviewer guidelines here http://joss.theoj.org/about#reviewer_guidelines
• Please make a publication recommendation at the end of your review

Any questions, please ask for help by commenting on this issue! 🚀

[jsta]

✋ I am reviewing this

[jsta]

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v1.0.0)?
  No, setup.py has a version number of 1.0 while the github release is 1.0.0
• Archive: Does the software archive resolve?

Functionality

• Installation: Does installation proceed as outlined in the documentation?

I am concerned about the instruction to install as root with sudo although I understand that this may be necessary in order for system-wide functionality. Also, I had to do a fair amount of fighting with PATH variables because I am a conda user.

• Functionality: Have the functional claims of the software been confirmed?

Verified functionality for all items!

• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.

I would really prefer a more automated package installation solution like integration with conda.

• Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).

Overall, I think git-rdm works great! I wonder if you could include instructions for viewing and verifying the .rdm/publications.db file.

• Functionality documentation: Is the functionality of the software documented to a satisfactory level (e.g. API method documentation)?
• Automated tests: Are there automated tests or manual steps described so that the function of the software can be verified?

There are no automated tests. However, I think the example usage in README.md is sufficient.

• 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

Recommendation: Accept with Minor Revisions

[desilinguist]

I had replied last night that I would be reviewing this via email. I guess that not everyone saw that? Anyway, I deleted my comment and I am happy to let @jsta review this one 👍.

[olexandr-konovalov]

Similar thing happened to me with another paper last week. I was away from browser and was only able to reply by email, but my comment did not appear under that paper so it was reviewed by another person (thanks!).

Could it be a more general problem?

[jsta]

@desilinguist I saw your reply. However, I neglected to do a thorough check of other submissions or I would have seen that it was the norm to only have one reviewer per submission. I just assumed that multiple people reviewed each submission. My apologies!

[desilinguist]

Ah, I see. No worries at all! You finished your review faster than I would have anyway which is better for all of us 👍

[ctjacobs]

Thank you all so much for your interest in this, and for the extremely fast review! I'll start addressing your comments within the next few days.

[jsta]

I realized that my comment about .rdm/publications.db in the Example Usage section is solved by:

$ git rdm ls

However, I ended up verifying the contents of the file separately using:

$ sqlite3 .rdm/publications.db '.header on' '.mode csv' '.once test.csv' 'SELECT * FROM publications'

I can see some room for improvement in the way the output of $ git rdm ls is formatted.

[arfon]

Could it be a more general problem?

@alex-konovalov - I'm not sure what we can do about this sorry. The only tried-and-tested solution here is to visit the review issue to see if anyone has already commented on it.

Also, while we don't have a firm policy about this, having a second review isn't really a bad thing 😉

[ctjacobs]

I have addressed @jsta's comments in the review branch of the git-rdm repository. The main changes are:

• Added a new option git rdm ls --raw which outputs the raw contents of the .rdm/publications.db file for database verification purposes. Also added an example of its use in README.md.
• Bumped the version in setup.py to v1.0.1 (rather than deleting and re-releasing this revised code as v1.0.0); v1.0.1 will be released via the Git-RDM repository's Releases page (and archived again on Figshare) once everyone is happy with the changes I've made here.
• Packaged up Git-RDM and PyRDM (and the SWORD2 dependency), and uploaded it to my anaconda.org package channel. Instructions for installing Git-RDM via Conda are now provided in README.md. Once again, the Conda package for Git-RDM will be updated to v1.0.1 once everyone is happy with the changes.

[ctjacobs]

For a full diff, please see ctjacobs/git-rdm#2

[jsta]

Awesome! I was able to install from your conda channel and test the git rdm ls --raw command. Also, I really like the improvements to README.md describing local installs. Everything is good-to-go for acceptance as far as I am concerned.

[ctjacobs]

Fantastic - many thanks for trying it out. I'll merge in the changes and update to v1.0.1.

[ctjacobs]

All done. The archive for v1.0.1 is available at the following (different) DOI: https://dx.doi.org/10.6084/m9.figshare.3443750.v1

@arfon, is it possible to have the "Archive DOI" here updated please?

The Conda package has also been updated to v1.0.1

[arfon]

Thanks for the excellent review @jsta!

@ctjacobs your paper DOI is http://dx.doi.org/10.21105/joss.00029 . The DOI isn't quite live yet (i.e. it doesn't resolve) but should start working in the next couple of hours once the Crossref queue processes the registration request. 🎉 🚀 💥

[ctjacobs]

Excellent. Thank you everyone!

@arfon, I would be happy to review future submissions for JOSS, so feel free to add me to @joss-reviewers.

Cheers!