[REVIEW]: IPART: A Python Package for Image-Processing based Atmospheric River Tracking #2407
Comments
|
Hello human, I'm @whedon, a robot that can help you with some common editorial tasks. @sadielbartholomew, @rabernat it looks like you're currently assigned to review this paper 🎉. 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. ⭐ Important ⭐ 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: For example, to regenerate the paper pdf after making changes in the paper's md or bib files, type: |
|
PDF failed to compile for issue #2407 with the following error: /app/vendor/ruby-2.4.4/lib/ruby/2.4.0/find.rb:43:in |
kbarnhart
changed the title
|
@whedon generate pdf |
|
PDF failed to compile for issue #2407 with the following error: Can't find any papers to compile :-( |
|
@arfon / @openjournals/joss-eics could you help me ensure the repository is linked correctly to this review issue. Issues may have cropped up because the authors changed the title of the submission and the repository address during the pre-review stage (#2197). I can edit the title/comments on this thread... @whedon could find the paper in the review issue (e.g., here) repo: https://github.com/ihesp/IPART thanks! |
|
@whedon generate pdf |
|
PDF failed to compile for issue #2407 with the following error: Can't find any papers to compile :-( |
|
👋 @openjournals/dev - can you take a look at this? |
|
@whedon generate pdf |
|
It was the bold markup in the repo link. It was confusing for Whedon. I removed it and now it works. |
|
@xuanxu thank you! Pretty confident that was my fault. |
|
@kbarnhart Just a quick question: I guess I should not update the master branch during the review stage, should I? |
|
@Xunius answer probably depends on what sort of changes you are making. I would not recommend totally restructuring the package. But if you have more moderate changes (adding a feature, updating the documentation, refactoring something internal), I don't see a reason why those sorts of changes would cause a problem. If you make a change that substantially modifies the dependencies such that a reviewer would need to re-create their compute environment used to test out and review IPART, that would probably not be advisable. Using an issue to describe why changes were made, and then a Pull Request that bring those changes into master will also make it clear what changes were made and why. |
|
@sadielbartholomew and @rabernat I wanted to check in with a friendly reminder that we are asking reviewers to complete their reviews within 6 weeks (in about 2 weeks). Please let me know how I can assist throughout the JOSS review process. |
|
Noted, thanks @kbarnhart. As this stage I do not feel I need assistance, I have simply not had much time in recent weeks to move on & finish my review. I plan, and will strive, to have my review completed by the end of this week i.e. the end of July. |
|
Thanks for the reminder. Indeed this had fallen off my radar. I will hopefully be able to get to it today. |
|
@kbarnhart I got another comment regarding installation. I'd like to propose a merge of the |
|
I am quite biased here, but as long as you are considering revamping your I/O routines, I would suggest you to look at xarray. The requirement to operate on files period is a big limitation of this tool. What if the user's data are not in netCDF format? Other formats, like GRIB or Zarr, are common. (For example, there are nearly 1PB of CMIP6 data in Google Cloud in Zarr format.) Or if the user's data are not in files at all, but rather computed on the fly from some other source? If you packages routines were able to accept xarray Dataset objects, you could effectively forget about dealing with files. Let the user open the files and pass an We wrote a little bit about this concept here: http://pangeo.io/packages.html#guidelines-for-new-packages I want to clarify that I don't think this sort of refactor is required to have your JOSS paper published. It's just an optional suggestion based on lots of experience with this sort of thing. |
|
@Xunius I think that changing the dependency makes sense. I had hoped that some of my early feedback in pre-review on installation instructions and packaging would have addressed some of these install issues. This is all to say that I strongly support @rabernat 's comments on ihesp/IPART/issues/5 to follow installation and practicing best practices. I also favor xarray over netcdf4, though if you have reasons for one dependency over another, that is your decision to make. Similarly, I've had good success with taking I/O out of the core of a package (e.g., a user is expected to provide a numpy array, or xarray.Dataset) rather than a file. A user can convert many common file formats into these data-structures in one or two lines of code, so I don't think it places an unnecessary burden on users. Regarding which things are and are not necessary to complete the JOSS process: I think that good packaging definitely is necessary and I would agree with @rabernat that refactoring the I/O is not necessary. You may choose to do it because it makes packaging easier, but that is up to you. If additional extensive discussion on this point is necessary, I may move the thread to an in-repo issue. As always, let me know how I can help with questions/clarifications. |
|
@sadielbartholomew thanks for the update. All sounds good. |
|
@whedon check references |
|
|
@whedon set v3.0.8 as version |
|
OK. v3.0.8 is the version. |
|
@whedon set 10.5281/zenodo.4164826 as archive |
|
OK. 10.5281/zenodo.4164826 is the archive. |
|
@whedon accept |
|
|
👋 @openjournals/joss-eics, this paper is ready to be accepted and published. Check final proof 👉 openjournals/joss-papers#1890 If the paper PDF and Crossref deposit XML look good in openjournals/joss-papers#1890, then you can now move forward with accepting the submission by compiling again with the flag |
|
@Xunius I've now recommended that this submission be accepted. The JOSS handling editor in chief will manage final publication. I agree with the reviewers that the package is much improved since submission. Congratulations on all of your hard work. |
|
|
Thanks @kbarnhart. I reviewed the paper and all looks good. |
|
@whedon accept deposit=true |
|
|
🐦🐦🐦 👉 Tweet for this paper 👈 🐦🐦🐦 |
|
🚨🚨🚨 THIS IS NOT A DRILL, YOU HAVE JUST ACCEPTED A PAPER INTO JOSS! 🚨🚨🚨 Here's what you must now do:
Any issues? Notify your editorial technical team... |
|
@kbarnhart @rabernat @sadielbartholomew Before this gets closed, I'd like to thank all of you for your help in improving this little project. I learned a lot during the process. |
|
🎉🎉🎉 Congratulations on your paper acceptance! 🎉🎉🎉 If you would like to include a link to your paper from your README use the following code snippets: 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:
|
|
@Xunius - see Whedon's guidance above on how to add the DOI to your readme ☝️. @sadielbartholomew, @rabernat - many thanks for your reviews here and to @kbarnhart for editing this submission. @Xunius - your paper is now accepted into JOSS ⚡🚀💥 |
|
🎉🎉🎉 Congratulations on your paper acceptance! 🎉🎉🎉 If you would like to include a link to your paper from your README use the following code snippets: 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: @Xunius (Guangzhi XU)
Repository: https://github.com/ihesp/IPART
Version: v3.0.8
Editor: @kbarnhart
Reviewer: @sadielbartholomew, @rabernat
Archive: 10.5281/zenodo.4164826
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:
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
@sadielbartholomew & @rabernat, 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.readthedocs.io/en/latest/reviewer_guidelines.html. Any questions/concerns please let @kbarnhart know.
✨ Please try and complete your review in the next six weeks ✨
Review checklist for @sadielbartholomew
Conflict of interest
Code of Conduct
General checks
Functionality
Documentation
Software paper
Review checklist for @rabernat
Conflict of interest
Code of Conduct
General checks
Functionality
Documentation
Software paper
The text was updated successfully, but these errors were encountered: