Joss-reviews: [REVIEW]: Stripy: A Python module for (constrained) triangulation in Cartesian coordinates and on a sphere

Created on 24 Apr 2019  ·  77Comments  ·  Source: openjournals/joss-reviews

Submitting author: @lmoresi (Louis Moresi)
Repository: https://github.com/underworldcode/stripy
Version: 1.0.1
Editor: @VivianePons
Reviewers: @santisoler, @rrenka
Archive: 10.5281/zenodo.3243511

Status

status

Status badge code:

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

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

@santisoler & @rrenka, 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.readthedocs.io/en/latest/reviewer_guidelines.html. Any questions/concerns please let @VivianePons know.

✨ Please try and complete your review in the next two weeks ✨

Review checklist for @santisoler

Conflict of interest

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: 1.0.1
  • [x] Authorship: Has the submitting author (@lmoresi) 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 @rrenka

Conflict of interest

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: 1.0.1
  • [x] Authorship: Has the submitting author (@lmoresi) 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)?
accepted published recommend-accept review
Source
picture whedon

All 77 comments

Hello human, I'm @whedon, a robot that can help you with some common editorial tasks. @santisoler 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:

watching

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

notifications

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

@whedon commands
whedon picture whedon on 24 Apr 2019 
Attempting PDF compilation. Reticulating splines etc...
whedon picture whedon on 24 Apr 2019

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

/app/vendor/ruby-2.4.4/lib/ruby/2.4.0/find.rb:43:in block in find': No such file or directory - tmp/1410 (Errno::ENOENT) from /app/vendor/ruby-2.4.4/lib/ruby/2.4.0/find.rb:43:incollect!'
from /app/vendor/ruby-2.4.4/lib/ruby/2.4.0/find.rb:43:in find' from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-a1723d160bb6/lib/whedon/processor.rb:57:infind_paper_paths'
from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-a1723d160bb6/bin/whedon:50:in prepare' from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor/command.rb:27:inrun'
from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in invoke_command' from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor.rb:387:indispatch'
from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor/base.rb:466:in start' from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-a1723d160bb6/bin/whedon:116:in from /app/vendor/bundle/ruby/2.4.0/bin/whedon:23:in load' from /app/vendor/bundle/ruby/2.4.0/bin/whedon:23:in

'

whedon picture whedon on 24 Apr 2019

@whedon generate pdf from branch paper

santisoler picture santisoler on 24 Apr 2019 
Attempting PDF compilation from custom branch paper. Reticulating splines etc...
whedon picture whedon on 24 Apr 2019

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

sh: 1: cd: can't cd to tmp/1410
/app/vendor/ruby-2.4.4/lib/ruby/2.4.0/find.rb:43:in block in find': No such file or directory - tmp/1410 (Errno::ENOENT) from /app/vendor/ruby-2.4.4/lib/ruby/2.4.0/find.rb:43:incollect!'
from /app/vendor/ruby-2.4.4/lib/ruby/2.4.0/find.rb:43:in find' from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-a1723d160bb6/lib/whedon/processor.rb:57:infind_paper_paths'
from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-a1723d160bb6/bin/whedon:50:in prepare' from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor/command.rb:27:inrun'
from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in invoke_command' from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor.rb:387:indispatch'
from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor/base.rb:466:in start' from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-a1723d160bb6/bin/whedon:116:in from /app/vendor/bundle/ruby/2.4.0/bin/whedon:23:in load' from /app/vendor/bundle/ruby/2.4.0/bin/whedon:23:in

'

whedon picture whedon on 24 Apr 2019

@VivianePons seems like whedon is having some problems generating the PDF.
Is this related to the fact that the repository ulr is pointing to the paper branch instead of pointing to the repo itself (https://github.com/underworldcode/stripy/)?

santisoler picture santisoler on 24 Apr 2019

Hi @lmoresi and @brmather. I was assigned as reviewer for your submitted paper.
Let me read through your PDF, explore your stripy repo and experiment with your software.
I'll try to meet the two weeks deadline, but in case I get delayed I'll let you know so you don't get worried about the status of the review.

I'm still thinking my review strategy, but I'll probably will open issues on your repo regarding each section of the checklist (e.g. General Checks, Functionality, Documentation, Software Paper).
Besides that, I'm open to help you solve the issues that may appear. My goal is to contribute to get this published! So don't hesitate asking for help or guidance, I'm willing to help with everything that's on my reach.

I'm sure this will be a nice experience for all of us. Be patient, I'll contact you when I have some news.

santisoler picture santisoler on 24 Apr 2019

Thanks - we’ll work with the way you prefer to review. issues sounds like the obvious strategy. We have a “paper” branch of the code to make sure that any developments we make during the review process do not cause problems for you. Any suggestions you make st this stage will be merged back when the process is done.

Prof Louis Moresi

louis.[email protected]louis.moresi@unimelb.edu.au

(w) +61 3 8344 1217

(m) +61 4 0333 1413

(us) +1 505 349 4425

www.moresi.infohttp://www.moresi.info/

www.facebook.com/underworldcodehttp://www.facebook.com/underworldcode

@LouisMoresihttps://twitter.com/LouisMoresi

On 24 Apr 2019, 07:20 -0700, Santiago Soler notifications@github.com, wrote:

Hi @lmoresihttps://github.com/lmoresi and @brmatherhttps://github.com/brmather. I was assigned as reviewer for your submitted paper.
Let me read through your PDF, explore your stripy repo and experiment with your software.
I'll try to meet the two weeks deadline, but in case I get delayed I'll let you know so you don't get worried about the status of the review.

I'm still thinking my review strategy, but I'll probably will open issues on your repo regarding each section of the checklist (e.g. General Checks, Functionality, Documentation, Software Paper).
Besides that, I'm open to help you solve the issues that may appear. My goal is to contribute to get this published! So don't hesitate asking for help or guidance, I'm willing to help with everything that's on my reach.

I'm sure this will be a nice experience for all of us. Be patient, I'll contact you when I have some news.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/openjournals/joss-reviews/issues/1410#issuecomment-486262060, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADABPI5V7F7RR6NJBZEVFJLPSBUAVANCNFSM4HID64OA.

lmoresi picture lmoresi on 24 Apr 2019

@whedon generate pdf from branch paper

VivianePons picture VivianePons on 25 Apr 2019
👍1 
Attempting PDF compilation from custom branch paper. Reticulating splines etc...
whedon picture whedon on 25 Apr 2019

:point_right: Check article proof :page_facing_up: :point_left:

whedon picture whedon on 25 Apr 2019

@lmoresi @brmather

We have a “paper” branch of the code to make sure that any developments we make during the review process do not cause problems for you. Any suggestions you make st this stage will be merged back when the process is done.

Thanks for pointing this out. I've started reviewing some of the more basic aspects of the publication.
I'll open some issues on your repo so we can start talking about them.
I'll try to get into the other subjects next week, so I can continue opening issues if they are needed.
So far the paper is looking great and most of the issues I found are really minor and very easy to tackle down.

santisoler picture santisoler on 25 Apr 2019

Hi @VivianePons. I have a small question regarding how versioning works on the review process.
The authors have submitted the 0.7.0 version of stripy, although on the review process they'll surely make some changes.
Is it possible that after acceptance the authors create a new release, 0.7.1 for instance, and make that the final version?
Thanks in advance!

santisoler picture santisoler on 26 Apr 2019

Yes, don't worry about the version. When the paper is approved, we update the version before the final publication

VivianePons picture VivianePons on 29 Apr 2019

I have a question for @arfon : I have contacted Robert Renka to be a second reviewer on this paper (as suggested by the author). He would be willing to do it but he is also the author of the original Fortran code on which the software is based. He is wondering if this is a case of conflict of interest.

I believe it's ok. I actually think that his opinion on the paper would be very valuable. Besides, we have a second independent reviewer so the publication is not based on his opinion alone. What do you think?

VivianePons picture VivianePons on 29 Apr 2019

I believe it's ok. I actually think that his opinion on the paper would be very valuable. Besides, we have a second independent reviewer so the publication is not based on his opinion alone. What do you think?

👍 this sounds OK to me. Thanks for checking.

arfon picture arfon on 29 Apr 2019

Yes, don't worry about the version. When the paper is approved, we update the version before the final publication

Thanks for answering this @VivianePons!

santisoler picture santisoler on 30 Apr 2019

@whedon add @rrenka as reviewer

VivianePons picture VivianePons on 30 Apr 2019

OK, @rrenka is now a reviewer

whedon picture whedon on 30 Apr 2019

@whedon generate pdf from branch master

lmoresi picture lmoresi on 2 May 2019 
Attempting PDF compilation from custom branch master. Reticulating splines etc...
whedon picture whedon on 2 May 2019

:point_right: Check article proof :page_facing_up: :point_left:

whedon picture whedon on 2 May 2019

I believe this software adds enormous value to my code, and
it is gratifying to see that the geophysics community is benefiting
from my efforts.

rrenka picture rrenka on 2 May 2019

Dear all, where are we on this? I see we still have some unchecked boxes.

VivianePons picture VivianePons on 20 May 2019

Hi @VivianePons. The submitted code is robust and works as expected. The manuscript is very well written and the statement of need is very clear. The public functions are all documented inside the sources files and the repository has a lot of notebooks showing examples on how to use the code.

Most of the issues the authors are solving are related with the organization of the files inside the repository, pypi packaging, Docker container creation and improvement of automated tests in order to make them more robust.
I left some unchecked boxes in order to remember which aspects of the publication are not yet entirely improved. Although, most of them are being solved. Hope to get all of them checked off soon!

Would you please take a look at https://github.com/underworldcode/stripy/issues/14? We need some help regarding one of the references. Thanks!

santisoler picture santisoler on 20 May 2019

Response to reviews —  @VivianePons

The review process has been thorough and very helpful. We felt that it might be useful to provide a brief summary of the action we have taken in response to the reviews as documented in the issue tracker:

  1. A number of the issues that were raised during the review were routine typos and minor bugs that we fixed as soon as they were brought to our attention. These include:

    • underworldcode/stripy#25
    • underworldcode/stripy#21
    • underworldcode/stripy#24
    • underworldcode/stripy#19

    1. Reviewer 2 (Renka) had some difficulty running the tests and so we incorporated pytest into our build process and also added the test suite to the dockerfile. Reviewer 1 (Soler) also commented on the lack of comprehensive unit testing and so we introduced a larger number of unit tests into the revised test suite. (underworldcode/stripy#21 , underworldcode/stripy#29 )

    2. Reviewer 1 commented on our use of the monorepo style of release and asked us to remove the litho1pt0 module from the repository. We have done so. (underworldcode/stripy#26)

    3. Reviewer 1 commented on the structure of the repository: notebooks bundled in the source code and other idiosyncratic choices. We initially restructured the repository along the lines suggested by the reviewer but found that this did not permit us to bundle the documentation with the installation which is a reasonably common way to deal with a self-documenting module. We reached a compromise restructure with rev 1 which is closer to a standard python package repository but still allows bundling of the documentation in the form of notebooks. (underworldcode/stripy#27).

    4. Our approach to installation was to provide multiple pathways to working examples and that included docker images, links to mybinder.org deployment and installation via pip. Some of the issues raised by Reviewer 1 wrt the repository structure were associated with the need to have multiple branches to handle incompatible versions of (for example) dockerfiles for different pathways. This is something of a moving target and became easier recently. We were therefore able to remove some of the persistent branches and this is certainly an improvement in reducing fragility for future releases. This is discussed in underworldcode/stripy#17 in some length and also in underworldcode/stripy#16

  2. In underworldcode/stripy#17 there was also some discussion about release tags and semantic versioning. We partially addressed Reviewer 1's requirements here (we moved to a github-commit versioning for non-release installations) but have not dealt with this at the docker image / tagging level. This remains a manual process.

  3. We adopted Reviewer 1's suggestions for applying our licences via github so that they would be automatically recognised. We also added contribution guidelines as suggested. (underworldcode/stripy#15, underworldcode/stripy#30)

  4. Reviewer 1 asked us to consider using Sphinx to provide a web-based documentation stream for stripy. We agree that this is a nice suggestion but also felt that this should still be discretionary as it was not part of our original plan. We collectively closed that issue on the basis that we would consider this later - Reviewer 1 had offered his assistance and we felt that this would need to wait until the review was complete. (underworldcode/stripy#28).

We think that we have addressed all the issued raised in the review process so far and hope that it can be drawn to a close. We would like to make a new release of the code that corresponds to to the version post review and would like to check if this is the standard operating procedure for JOSS and, if so, when it should be done.

Thanks for the opportunity to respond.

lmoresi picture lmoresi on 1 Jun 2019

Hi, thank you for the summary. I am happy to see that the review has been helpful and has improved the overall quality!

Where are we on the reviewer side? Whenever I have your green light, I can move forward with the process.

VivianePons picture VivianePons on 5 Jun 2019

Hi @VivianePons.

I don't think I can improve @lmoresi summary. But I can add a few things.

I consider the paper and the repository have gone through a great improvement in comparison with the first submitted version.
Regarding JOSS's requirements, I think they are all almost satisfied. I open a small issue (https://github.com/underworldcode/stripy/issues/36) and two Pull Requests (https://github.com/underworldcode/stripy/pull/34 and https://github.com/underworldcode/stripy/pull/35) in order to add some instructions to the README.md. That's why I haven't checked off the Installation instructions box.
The other box left to check off is the one related with the Version. I'm awaiting for the authors to make a new release whenever they feel ready.

I've also raised the possibility to implement automated test through pytest and compiled documentation through Sphinx. Although I stated that solving these issues was not mandatory to accept the publication, the authors implemented the automated tests with pytest and published a compiled documentation to GitHub Pages using pdoc instead of Sphinx. They found pdoc to be better suited than Sphinx due to the not so large size of their repository and its ease of use. I didn't even know pdoc existence, but I found it out to be a very nice alternative to Sphinx for small to medium projects.
I think it would be nice to have it into account for other JOSS papers that wants to quickly implement nice looking documentation.

In summary, when the README.md is updated accordingly to the issues I raised and a new release is created, I'll be ready to accept the paper for publication.
Nevertheless, I feel the authors are very excited by implementing a Continuous Integration to automate the tests and the documentation build. Maybe would be nice to wait for them to be ready. That's up to them.

Finally I want to thanks the authors for the effort and responsiveness to each of one of the issues and comments I opened. They were always very respectful and created a nice atmosphere to discuss possible solutions to those issues. Besides they were always open to take into account each one of my advises, even if that implied to dive into new software or tools. I know the effort that takes reading through documentation for the first time and get used to a new tool, so I really appreciate that.
Also, I want to thanks the authors for the patience with my use of English. It's not my first language and I apologize if it led to any misunderstanding.
I had a very nice experience reviewing this paper. I really liked the review process of JOSS and would be glad to do it again if needed.
Thanks you @VivianePons and every one behind JOSS for all your work.

santisoler picture santisoler on 5 Jun 2019
👍1

I have checked all the boxes. Congratulations to the authors on your excellent work!

rrenka picture rrenka on 7 Jun 2019

All the issues I open are already solved, so I checked off every box but the Version one.
Once the authors make a new release, I consider the submitted paper will be ready for publication.

santisoler picture santisoler on 10 Jun 2019

Perfect! The editorial process will include releasing a new version anyway and I'll update it here.

I consider the paper to be accepted, good job everyone! It was great to see so much interactions between reviewers and authors.

VivianePons picture VivianePons on 11 Jun 2019

@whedon check references

VivianePons picture VivianePons on 11 Jun 2019 
Attempting to check references...
whedon picture whedon on 11 Jun 2019

```Reference check summary:

OK DOIs

  • 10.1016/j.tecto.2016.12.004 is OK
  • 10.1029/2007GC001743 is OK
  • 10.1145/275323.275329 is OK
  • 10.1145/275323.275330 is OK
  • 10.1145/225545.225546 is OK
  • 10.1145/225545.225547 is OK
  • 10.1002/2013JB010626 is OK

MISSING DOIs

  • None

INVALID DOIs

  • None
    ```
whedon picture whedon on 11 Jun 2019

@whedon generate pdf from branch master

VivianePons picture VivianePons on 11 Jun 2019 
Attempting PDF compilation from custom branch master. Reticulating splines etc...
whedon picture whedon on 11 Jun 2019

:point_right: Check article proof :page_facing_up: :point_left:

whedon picture whedon on 11 Jun 2019

@lmoresi could you:

  • release the new updated version
  • create Zenodo archive

(question: is the "from branch master" still necessary to generate the pdf?)

VivianePons picture VivianePons on 11 Jun 2019

(question: is the "from branch master" still necessary to generate the pdf?)

Whedon by default uses master so this is redundant.

arfon picture arfon on 11 Jun 2019

I explicitly stated “master” last time simply to stop anyone (likely myself) pasting the previous command that used the “paper” branch.
Redundant in every computational sense other than to account for human fallibility.

L

Prof Louis Moresi

louis.[email protected]louis.moresi@unimelb.edu.au

(w) +61 3 8344 1217

(m) +61 4 0333 1413

(us) +1 505 349 4425

www.moresi.infohttp://www.moresi.info/

www.facebook.com/underworldcodehttp://www.facebook.com/underworldcode

@LouisMoresihttps://twitter.com/LouisMoresi

On 11 Jun 2019, 1:10 PM +0100, Arfon Smith notifications@github.com, wrote:

(question: is the "from branch master" still necessary to generate the pdf?)

Whedon by default uses master so this is redundant.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/openjournals/joss-reviews/issues/1410?email_source=notifications&email_token=ADABPI25AJ7WAAYSO2YFBD3PZ6I2LA5CNFSM4HID64OKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXM42MI#issuecomment-500813105, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADABPI6D4L577MJ3YV5SCNDPZ6I2LANCNFSM4HID64OA.

lmoresi picture lmoresi on 11 Jun 2019
😄1

@VivianePons

I have made the release (it's 1.0.1 on both PYPI and Github) and it is automatically propagated to zenodo at doi.org/10.5281/zenodo.3243511

whedon can automatically build from the default branch now.

Thanks for all the help. That was a very useful / interesting experience and we will be happy to publish with JOSS again.

@lmoresi could you:

  • release the new updated version
  • create Zenodo archive
lmoresi picture lmoresi on 11 Jun 2019

Could you update the Zenodo archive to have same title as the paper?

Thanks

VivianePons picture VivianePons on 13 Jun 2019

OK - done
https://zenodo.org/record/3243511

lmoresi picture lmoresi on 13 Jun 2019

@whedon set 10.5281/zenodo.3243511 as archive

VivianePons picture VivianePons on 13 Jun 2019

OK. 10.5281/zenodo.3243511 is the archive.

whedon picture whedon on 13 Jun 2019

@whedon set 1.0.1 as version

VivianePons picture VivianePons on 13 Jun 2019

OK. 1.0.1 is the version.

whedon picture whedon on 13 Jun 2019

Congratulations! Your paper has been officially accepted to JOSS. I leave it to @openjournals/joss-eics for finalization

VivianePons picture VivianePons on 13 Jun 2019

/ooo June 14 until October 3

VivianePons picture VivianePons on 13 Jun 2019

:+1: Marked @VivianePons as OOO from Friday, June 14th 2019 to Thursday, October 3rd 2019. :calendar:

ooo[bot] picture ooo[bot] on 13 Jun 2019

:tada: :confetti_ball: Congratulations! :confetti_ball: :tada:

santisoler picture santisoler on 13 Jun 2019

@whedon accept

arfon picture arfon on 13 Jun 2019 
Attempting dry run of processing paper acceptance...
whedon picture whedon on 13 Jun 2019

```Reference check summary:

OK DOIs

  • 10.1016/j.tecto.2016.12.004 is OK
  • 10.1029/2007GC001743 is OK
  • 10.1145/275323.275329 is OK
  • 10.1145/275323.275330 is OK
  • 10.1145/225545.225546 is OK
  • 10.1145/225545.225547 is OK
  • 10.1002/2013JB010626 is OK

MISSING DOIs

  • None

INVALID DOIs

  • None
    ```
whedon picture whedon on 13 Jun 2019

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

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

whedon picture whedon on 13 Jun 2019

@lmoresi - could you merge this PR, it fixes the position of the figure caption: https://github.com/underworldcode/stripy/pull/41

arfon picture arfon on 13 Jun 2019

@whedon accept

arfon picture arfon on 13 Jun 2019 
Attempting dry run of processing paper acceptance...
whedon picture whedon on 13 Jun 2019

```Reference check summary:

OK DOIs

  • 10.1016/j.tecto.2016.12.004 is OK
  • 10.1029/2007GC001743 is OK
  • 10.1145/275323.275329 is OK
  • 10.1145/275323.275330 is OK
  • 10.1145/225545.225546 is OK
  • 10.1145/225545.225547 is OK
  • 10.1002/2013JB010626 is OK

MISSING DOIs

  • None

INVALID DOIs

  • None
    ```
whedon picture whedon on 13 Jun 2019

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

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

whedon picture whedon on 13 Jun 2019

@whedon generate pdf

arfon picture arfon on 13 Jun 2019 
Attempting PDF compilation. Reticulating splines etc...
whedon picture whedon on 13 Jun 2019

:point_right: Check article proof :page_facing_up: :point_left:

whedon picture whedon on 13 Jun 2019

@whedon accept

arfon picture arfon on 13 Jun 2019 
Attempting dry run of processing paper acceptance...
whedon picture whedon on 13 Jun 2019

```Reference check summary:

OK DOIs

  • 10.1016/j.tecto.2016.12.004 is OK
  • 10.1029/2007GC001743 is OK
  • 10.1145/275323.275329 is OK
  • 10.1145/275323.275330 is OK
  • 10.1145/225545.225546 is OK
  • 10.1145/225545.225547 is OK
  • 10.1002/2013JB010626 is OK

MISSING DOIs

  • None

INVALID DOIs

  • None
    ```
whedon picture whedon on 13 Jun 2019

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

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

whedon picture whedon on 13 Jun 2019

@whedon accept deposit=true

arfon picture arfon on 13 Jun 2019 
Doing it live! Attempting automated processing of paper acceptance...
whedon picture whedon on 13 Jun 2019

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

whedon picture whedon on 13 Jun 2019

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

Here's what you must now do:

  1. Check final PDF and Crossref metadata that was deposited :point_right: https://github.com/openjournals/joss-papers/pull/757
  2. Wait a couple of minutes to verify that the paper DOI resolves https://doi.org/10.21105/joss.01410
  3. If everything looks good, then close this review issue.

  4. Party like you just published a paper! 🎉🌈🦄💃👻🤘

    Any issues? notify your editorial technical team...

whedon picture whedon on 13 Jun 2019

@santisoler, @rrenka - many thanks for your reviews and to @VivianePons for editing this submission ✨

@lmoresi - your paper is now accepted into JOSS :zap::rocket::boom:

arfon picture arfon on 13 Jun 2019

: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.01410/status.svg)](https://doi.org/10.21105/joss.01410)

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

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

This is how it will look in your documentation:

DOI

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:

whedon picture whedon on 13 Jun 2019

The Software repository link on the final article is 404. It should probably point to the repo, not a subdirectory.

QuLogic picture QuLogic on 14 Jun 2019

I have added a ‘paper’ tag to the repo that snapshots the current / published state so that the link no longer fails.

However, this is a snapshot of the published release and I am not sure that this is what is intended by that link.

Prof Louis Moresi

louis.[email protected]louis.moresi@unimelb.edu.au

(w) +61 3 8344 1217

(m) +61 4 0333 1413

(us) +1 505 349 4425

www.moresi.infohttp://www.moresi.info/

www.facebook.com/underworldcodehttp://www.facebook.com/underworldcode

@LouisMoresihttps://twitter.com/LouisMoresi

On 14 Jun 2019, 5:27 AM +0100, Elliott Sales de Andrade notifications@github.com, wrote:

The Software repository link on the final article is 404. It should probably point to the repo, not a subdirectory.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/openjournals/joss-reviews/issues/1410?email_source=notifications&email_token=ADABPI7KPCXRBCY5WU3IKXTP2MM27A5CNFSM4HID64OKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXVVS2I#issuecomment-501963113, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADABPI2JNT4NTI6PLGAIFPDP2MM27ANCNFSM4HID64OA.

lmoresi picture lmoresi on 14 Jun 2019

This is fixed now. Thanks for catching this.

arfon picture arfon on 14 Jun 2019
Was this page helpful?
0 / 5 - 0 ratings

Related issues

whedon picture whedon  ·  12Comments
whedon picture whedon  ·  12Comments
whedon picture whedon  ·  12Comments
whedon picture whedon  ·  12Comments
whedon picture whedon  ·  13Comments