Closed whedon closed 6 years ago
Hello human, I'm @whedon. I'm here to help you with some common editorial tasks. @Cadair, 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:
For a list of things I can do to help you, just type:
@whedon commands
Attempting PDF compilation. Reticulating splines etc...
👋 @ngoldbaum @Cadair @tbekolay @ygrange
I went through the checklist and all was great, except for the "Does the release version given match the GitHub release (v1.0.3)?" checkbox. There has been a new release since the paper was submitted (it is now at v1.0.4), but this does not seem to me to be an issue.
This is my first JOSS review, so apologies for the newb questions, but is filling out checklist all that is required for the review? I.e., publication is based on these yes/no metrics and not any other criteria, such as the quality of the paper itself?
As long as those kinds of general comments are not unwelcome, then I'd like to commend @ngoldbaum and the other authors on an excellently written paper, and the whole unyt development team on a well documented and well organized codebase. I'm very pleased to see that yt units has been extracted to a separate project with minimal dependencies and am optimistic that it can become the de facto standard for Python units handling :+1:
@tbekolay thank you! The version mismatch is fine, we recognize the software will change after submission (but hopefully not substantially).
Yes, we do ask that you fill out the checklist—that, plus the resolution of any issues you may bring up, is how we determine that our acceptance criteria is met. There aren't any additional criteria, though any suggestions/comments on the paper itself (or any other part of the software) are welcome.
Ok, I finally got around to have a look at this. I'll try to submit some comments half-way next week.
The main comment I have is: Great paper, I really enjoyed reading it! You did a really good job at analysing the differences in performance and functionality between unyt and the two comparable packages. I will go through the checklist shortly, but let me post my comments on the contents first:
First a comment on the code base: Your code coverage is really great! There is no documentation for users to execute the unit tests after installation from source. It's probably one extra line to the readme, but would certainly be great to have.
On the text then: page 7: “for each of the benchmarks below” -> not all benchmarks are below this text so it’s a bit confusing. Rephrasing to "in this section" or something similar fixes this.
Let me repeat that I really love the thorough profiling here. Very impressive and very nice to read!
I have a few comments
On the dependencies: to do the testing, one needs to install a few extra dependencies.
Documentation: the docstrings look really good and complete. Even though they are quite descriptive by nature I would advice to add a desciption to the exception classes (i.e. if I use unyt in my work, what case is covere by what exception?)
I see the list of authors in the paper.md file, but there is no author listed in the PDF. Is this a technical problem, or is this actually always the case? (question for the @kyleniemeyer I guess).
Done spamming for now 😄 .
Awesome, thank you for the comments. @kyleniemeyer how should I address the comments to the paper? In a pull request to unyt that I ping @ygrange on?
This is a really nice paper, with a great comparison between the three packages. The quality of the code, docs and tests all looks fantastic as I would've expected :smile:. I hope that this package gains a lot of traction by becoming such a lightweight standalone package (something I have thought astropy.units
should do for a long time). I look forward to using it in some of my own code in the future.
One small comment on the paper:
@ngoldbaum you can make a PR or issues over on your repo that reference this one, so that they'll show up in this thread.
@ygrange regarding your question about the authors, I do see the authors right below the title in the PDF—do you see something else?
Ugh, sorry. This is also my second review ever over here so I just discovered the paper in the repo is not the same (certainly in terms of layout) as the proof-read version over here. Whoops. Thanks for pointing that out!
Ah yes, sorry if that was confusing! It was convenient to have a draft PDF in the repo before I submitted to JOSS. I'll replace it with the final version once the review process is finished.
I've gone ahead and opened https://github.com/yt-project/unyt/pull/41, https://github.com/yt-project/unyt/pull/42, https://github.com/yt-project/unyt/pull/43, and https://github.com/yt-project/unyt/pull/44. I'd very much appreciate eyes from any of the reviewers on those pull requests.
@kyleniemeyer once those PRs are merged I'd like to cut a new release and update the metadata json files to reflect the updates from the reviewers. Is there anything else I should do while I'm doing that or do you think I've satisfied all the issues the reviewers pointed out?
Nothing to add. Thanks for the changes! I would be very happy if this one would be published.
@ngoldbaum that plan sounds good to me. Just ping me here when you have finalized the paper edits, and I will take a final look from an editing perspective. After I give the 👍 on that, you'll need to archive the final repo (software + data) in Zenodo (e.g.) and provide the DOI back here.
@kyleniemeyer I've pushed unyt 1.0.5
to pypi and conda-forge. Can you take a look? If you approve I'll put that version on zenodo.
@whedon generate pdf
Attempting PDF compilation. Reticulating splines etc...
@ngoldbaum OK, I have some edits for the paper:
texttt
format to match the rest of the software. Also, ndarray in the 4th paragraph and in the Pint section.After you make these changes, please archive the entire repo to Zenodo and report back the DOI
Thanks for the detailed copy-editing comments. My grandmother was an editor before she retired and helped me many times over the years, it always makes me really appreciative of careful copy-editing.
My bibtex entries were taken from the NASA ADS, which is usually the one-stop shop for astronomers who are doing bibliographic searches. It would be nice if we could make it so it generated bibtex that played nicely with JOSS. I think they'd like they might like the feedback about adding a URL to the arxiv entry directly to the bibtex link. Perhaps @augustfly might know the appropriate person to contact about that?
It also took me a little while to figure out how to archive on Zenodo - I wish the docs on github's release functionality were clearer that it works for existing releases! Anyway, here is the zenodo link:
@whedon generate pdf
Attempting PDF compilation. Reticulating splines etc...
Hi,
I'm not sure what is being asked of me?
Looking at the last version of the bibtex before the last commit, and at the JOSS author guidelines, the only problem I see is that pynbody
wasn't a recent ADS bibtex entry.
The guidelines --
https://joss.readthedocs.io/en/latest/submitting.html#example-paper-and-bibliography
suggest ADS macros (e.g., \pasa
) are supported as are eprint
+ archiveprefix
keys, which is how to encode both arXiv and ASCL entries into anchored URLs (as described here: https://arxiv.org/hypertex/bibstyles/).
FWIW, howpublished
is a bibtex hack that I hope isn't part of anyone's workflow. :-) Not that I'm not one to avoid bibtex hacks, having added version
tags to our Journal's preferred bibtex styles for citing software.
having said all that -- the person you want is @aaccomazzi
Hi August,
Nothing being asked of you in particular, just pinging you because I thought it was highly likely you'd have more context than I would. Apologies for the imposition, that wasn't my intention.
Thanks for the context :)
Then I guess the issue is that JOSS or whedon isn't picking up on the eprint tags or ADS macros, or at least they're not ending up as nicely rendered journal names (in some cases anyway) or URLs in the citation list of a JOSS paper PDF.
Just checked the generated PDF and saw no problems with missing links in the reference, so I assume the issue has been fixed by the authors. If there is a systematic issue with ADS reference generation please file an issue with full details here: https://github.com/adsabs/export_service
No worries. I wasn't upset, Nathan -- this is one of my favorite subjects! I can't rant about howpublished
all day long.
I simply don't see how the JOSS author instructions can use ADS bibtex verbatim but that something needs to change with ADS bibtex for it to be compiled correctly.
@whedon set 10.5281/zenodo.1344605 as archive
OK. 10.5281/zenodo.1344605 is the archive.
@arfon this paper is now accepted and ready to be published!
@ngoldbaum @aaccomazzi @augustfly Arfon is definitely the person to include in the discussion of how we process bibtex... I'm not even sure if we are using biblatex or bibtex. However, in my experience I have never not had to customize a .bib file, for JOSS or otherwise :)
@Cadair, @tbekolay, @ygrange - many thanks for your reviews here and to @kyleniemeyer for editing this submission ✨
@ngoldbaum - your paper is now accepted into JOSS and your DOI is https://doi.org/10.21105/joss.00809 ⚡️:rocket: :boom:
: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](http://joss.theoj.org/papers/10.21105/joss.00809/status.svg)](https://doi.org/10.21105/joss.00809)
HTML:
<a style="border-width:0" href="https://doi.org/10.21105/joss.00809">
<img src="http://joss.theoj.org/papers/10.21105/joss.00809/status.svg" alt="DOI badge" >
</a>
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:
Submitting author: @ngoldbaum (Nathan Goldbaum) Repository: https://github.com/yt-project/unyt Version: v1.0.3 Editor: @kyleniemeyer Reviewer: @Cadair, @tbekolay, @ygrange Archive: 10.5281/zenodo.1344605
Status
Status badge code:
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
@Cadair & @tbekolay & @ygrange, please carry out your review in this issue by updating the checklist below. If you cannot edit the checklist please:
The reviewer guidelines are available here: https://joss.theoj.org/about#reviewer_guidelines. Any questions/concerns please let @kyleniemeyer know.
Review checklist for @Cadair
Conflict of interest
Code of Conduct
General checks
Functionality
Documentation
Software paper
paper.md
file include a list of authors with their affiliations?Review checklist for @tbekolay
Conflict of interest
Code of Conduct
General checks
Functionality
Documentation
Software paper
paper.md
file include a list of authors with their affiliations?Review checklist for @ygrange
Conflict of interest
Code of Conduct
General checks
Functionality
Documentation
Software paper
paper.md
file include a list of authors with their affiliations?