[REVIEW]: DataLad: distributed system for joint management of code, data, and their relationship

whedon commented 3 years ago

Submitting author: @yarikoptic (Yaroslav Halchenko) Repository: https://github.com/datalad/datalad Version: 0.14.3 Editor: @arokem Reviewer: @szorowi1, @jkanche Archive: 10.5281/zenodo.5034875

:warning: JOSS reduced service mode :warning:

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/be6dfc853d7993c156456a6450b24dbc"><img src="https://joss.theoj.org/papers/be6dfc853d7993c156456a6450b24dbc/status.svg"></a>
Markdown: [![status](https://joss.theoj.org/papers/be6dfc853d7993c156456a6450b24dbc/status.svg)](https://joss.theoj.org/papers/be6dfc853d7993c156456a6450b24dbc)

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) by leaving comments 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

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

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

The reviewer guidelines are available here: https://joss.readthedocs.io/en/latest/reviewer_guidelines.html. Any questions/concerns please let @arokem know.

✨ Please start on your review when you are able, and be sure to complete your review in the next six weeks, at the very latest ✨

Review checklist for @szorowi1

Conflict of interest

[x] I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

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] Contribution and authorship: Has the submitting author (@yarikoptic) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
[x] Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines

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 functionality 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] Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
[x] A statement of need: Does the paper have a section titled 'Statement of Need' that clearly states what problems the software is designed to solve and who the target audience is?
[x] State of the field: Do the authors describe how this software compares to other commonly-used packages?
[x] Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
[x] References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

Review checklist for @jkanche

Conflict of interest

[x] I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

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] Contribution and authorship: Has the submitting author (@yarikoptic) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
[x] Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines

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 functionality 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] Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
[x] A statement of need: Does the paper have a section titled 'Statement of Need' that clearly states what problems the software is designed to solve and who the target audience is?
[x] State of the field: Do the authors describe how this software compares to other commonly-used packages?
[x] Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
[x] References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

whedon commented 3 years ago

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

OK DOIs

- 10.1515/nf-2020-0037 is OK
- 10.5281/zenodo.4773629 is OK
- 10.5281/ZENODO.2431914 is OK
- 10.5281/ZENODO.2558512 is OK
- 10.5281/ZENODO.3874225 is OK
- 10.5281/ZENODO.3900277 is OK
- 10.5281/ZENODO.4495560 is OK
- 10.1038/sdata.2016.18 is OK
- 10.1038/s41467-021-21970-2 is OK
- 10.21203/rs.3.rs-264855/v1 is OK
- 10.1038/sdata.2016.44 is OK
- 10.31234/osf.io/w8trm is OK

MISSING DOIs

- None

INVALID DOIs

- None

arokem commented 3 years ago

OK! At this point could you:

[x] Make a tagged release of your software and list the version tag of the archived version here.
[x] Archive the reviewed software in Zenodo or a similar service (e.g., figshare, an institutional repository)
[x] Check that the archival deposit (e.g., in Zenodo) has the correct metadata. This includes the title (should match the paper title) and author list (make sure the list is correct and people who only made a small fix are not on it). You may also add the authors' ORCID.
[x] Please list the DOI of the archived version here.

We can then move forward with a final check by one of the EiC, before accepting the paper.

yarikoptic commented 3 years ago

Just to make sure - paper branch can remain detached (not merged into) from a release branch (maint) and tag, correct?

arokem commented 3 years ago

I believe that's correct, but let's bring in @openjournals/joss-eics to help resolve this.

This is a case where the paper is on a separate branch. The release version that gets tagged and archived does not have to include this branch in it, does it?

arfon commented 3 years ago

Just to make sure - paper branch can remain detached (not merged into) from a release branch (maint) and tag, correct?

Yes, that's right. We can accept the submission without the paper actually landing in the merged code into the repository.

yarikoptic commented 3 years ago

Check that the archival deposit (e.g., in Zenodo) has the correct metadata. This includes the title (should match the paper title) and author list (make sure the list is correct and people who only made a small fix are not on it).

Does it require to have author list in the same order in this paper and on Zenodo, or just that the "set" of authors match?

yarikoptic commented 3 years ago

While revisiting the list of the requirements for Zenodor archive entry, another concern is

... make sure the list is correct and people who only made a small fix are not on it

we have contributors who contributed no "fix" at all, but were significant and notable contributors to see to the success of the project. I think this requirement/statement should be adjusted for JOSS to not suggest a demand only for major "in commit/code" contributions: projects do often need administrators, mentors, user support, and other "personnel" which would not be submitting a "fix" but would be critical.
our zenodo entry might have (didn't check) minor "small fix" contributors to the software which decided to not become a co-author to the paper (and rather just to be acknowledged in Acknowledgements section). I would hate to remove them from the list of authors on Zenodo.

So I hope that it would be acceptable to have Zenodo list of authors to be a superset of the authors for the publication and not necessarily matching the order.

If not acceptable: I guess we can mint a single release just for the purpose of JOSS publication with the desired listing/order.

Thank you in advance for the clarification(s). (attn @arokem @arfon )

arfon commented 3 years ago

So I hope that it would be acceptable to have Zenodo list of authors to be a superset of the authors for the publication and not necessarily matching the order.

Yes this is OK. We absolutely must have an archive of the software to associate with the review, and we prefer that the archive metadata (authors, title etc.) match the JOSS paper. This later requirement though is a soft one so it's OK to proceed.

yarikoptic commented 3 years ago

We have been meticulously archiving datalad on zenodo (and pypi and debian and neurodebian and their snapshots repos) through the years and https://zenodo.org/record/5034875#.YNsmFXWYXjE is the one for recent datalad/datalad: 0.14.6. Would it be sufficient (given the relaxed prefer for the metadata)?

arokem commented 3 years ago

Yes. I think this is fine.

arokem commented 3 years ago

@whedon set 10.5281/zenodo.5034875 as archive

whedon commented 3 years ago

OK. 10.5281/zenodo.5034875 is the archive.

arokem commented 3 years ago

@openjournals/joss-eics : I believe this article is ready for your review.

arfon commented 3 years ago

@whedon recommend-accept

☝️ @arokem – we have this dedicated command now for flagging submissions as ready to hand over to the EiC team.

whedon commented 3 years ago

Attempting dry run of processing paper acceptance...

whedon commented 3 years ago

PDF failed to compile for issue #3262 with the following error:

 Can't find any papers to compile :-(

arfon commented 3 years ago

@whedon recommend-accept from branch paper-joss

whedon commented 3 years ago

Attempting dry run of processing paper acceptance...

whedon commented 3 years ago

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

OK DOIs

- 10.1515/nf-2020-0037 is OK
- 10.5281/zenodo.4773629 is OK
- 10.5281/ZENODO.2431914 is OK
- 10.5281/ZENODO.2558512 is OK
- 10.5281/ZENODO.3874225 is OK
- 10.5281/ZENODO.3900277 is OK
- 10.5281/ZENODO.4495560 is OK
- 10.1038/sdata.2016.18 is OK
- 10.1038/s41467-021-21970-2 is OK
- 10.21203/rs.3.rs-264855/v1 is OK
- 10.1038/sdata.2016.44 is OK
- 10.31234/osf.io/w8trm is OK

MISSING DOIs

- None

INVALID DOIs

- None

whedon commented 3 years ago

:wave: @openjournals/joss-eics, this paper is ready to be accepted and published.

Check final proof :point_right: https://github.com/openjournals/joss-papers/pull/2425

If the paper PDF and Crossref deposit XML look good in https://github.com/openjournals/joss-papers/pull/2425, then you can now move forward with accepting the submission by compiling again with the flag deposit=true e.g.

@whedon accept deposit=true from branch paper-joss

arfon commented 3 years ago

@whedon accept deposit=true from branch paper-joss

whedon commented 3 years ago

Doing it live! Attempting automated processing of paper acceptance...

whedon commented 3 years ago

🐦🐦🐦 👉 Tweet for this paper 👈 🐦🐦🐦

whedon commented 3 years ago

🚨🚨🚨 THIS IS NOT A DRILL, YOU HAVE JUST ACCEPTED A PAPER INTO JOSS! 🚨🚨🚨

Here's what you must now do:

Check final PDF and Crossref metadata that was deposited :point_right: https://github.com/openjournals/joss-papers/pull/2426
Wait a couple of minutes, then verify that the paper DOI resolves https://doi.org/10.21105/joss.03262
If everything looks good, then close this review issue.
Party like you just published a paper! 🎉🌈🦄💃👻🤘

Any issues? Notify your editorial technical team...

arfon commented 3 years ago

@szorowi1, @jkanche – many thanks for your reviews here and to @arokem for editing this submission! JOSS relies upon the volunteer effort of people like you and we simply wouldn't be able to do this without you ✨

@yarikoptic – your paper is now accepted and published in JOSS :zap::rocket::boom:

whedon commented 3 years ago

: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 snippets:

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

HTML:
<a style="border-width:0" href="https://doi.org/10.21105/joss.03262">
  <img src="https://joss.theoj.org/papers/10.21105/joss.03262/status.svg" alt="DOI badge" >
</a>

reStructuredText:
.. image:: https://joss.theoj.org/papers/10.21105/joss.03262/status.svg
   :target: https://doi.org/10.21105/joss.03262

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: https://joss.theoj.org/reviewer-signup.html
Making a small donation to support our running costs here: https://numfocus.org/donate-to-joss

yarikoptic commented 3 years ago

Thank you @arfon @szorowi1, @jkanche and the last but not least @arokem for making this mundane Thursday a "once in a life time" special occasion ;)
The idea for the "DataLad paper" was painful (we exercised a number of concepts to pursue), and the goals, format and structure of JOSS publication and review process helped us tremendously to finally make it happen!

FWIW, if might come handy for some, https://github.com/datalad/datalad-git-bug-dumps/tree/master/tools provides some extra helper we used (on top of git-bug dump) to decide on co-authors etc to invite! No JOSS paper is expected to come for that ;) But may be it could give ideas to establish some JOSS-tools collection of helpers on how to objectively figure out the list of co-authors to invite etc.

openjournals / joss-reviews