Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[REVIEW]: webweb: a tool for creating lightweight network visualizations in the browser #1458

Closed
whedon opened this issue May 19, 2019 · 41 comments

Comments

@whedon
Copy link
Collaborator

commented May 19, 2019

Submitting author: @hneutr (Kenneth Hunter Wapman)
Repository: https://github.com/dblarremore/webweb
Version: 0.0.37
Editor: @cMadan
Reviewer: @vc1492a, @jg-you
Archive: 10.5281/zenodo.3366140

Status

status

Status badge code:

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

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

@vc1492a & @jg-you, 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 @cMadan know.

Please try and complete your review in the next two weeks

Review checklist for @vc1492a

Conflict of interest

Code of Conduct

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: 0.0.37
  • Authorship: Has the submitting author (@hneutr) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

Functionality

  • Installation: Does installation proceed as outlined in the documentation?
  • Functionality: Have the functional claims of the software been confirmed?
  • 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

  • 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 core 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

  • 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)?

Review checklist for @jg-you

Conflict of interest

Code of Conduct

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: 0.0.37
  • Authorship: Has the submitting author (@hneutr) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

Functionality

  • Installation: Does installation proceed as outlined in the documentation?
  • Functionality: Have the functional claims of the software been confirmed?
  • 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

  • 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 core 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

  • 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)?
@whedon

This comment has been minimized.

Copy link
Collaborator Author

commented May 19, 2019

Hello human, I'm @whedon, a robot that can help you with some common editorial tasks. @vc1492a, it looks like you're currently assigned as the reviewer for this paper 🎉.

⭐️ 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:

  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

This comment has been minimized.

Copy link
Collaborator Author

commented May 19, 2019

Attempting PDF compilation. Reticulating splines etc...
@whedon

This comment has been minimized.

Copy link
Collaborator Author

commented May 19, 2019

@vc1492a

This comment has been minimized.

Copy link
Collaborator

commented May 27, 2019

Overview: Overall, I think the author(s) did a good job on the software and in providing examples and documentation in order to get started easily. The software is easy to use and I think addresses the needs of the audience as well. While I would have liked to see more refinement in the code base prior to consideration for publication in JOSS (e.g. matching and clear format for version numbers, no unused parameters, static methods when needed, etc.), these items can easily be addressed in newer versions of the software prior to acceptance in JOSS. I particularly like the software's flexibility in the input data - being able to use lists, adjacency matrices, or networkx objects is a nice capability and opens up the software to a broader audience versus implementing functionality with networkx alone.

Version Matching: The version number submitted to JOSS (0.0.29) does not match the latest version of the source code on the master branch in Github (0.0.30 as indicated in setup.py) - the JOSS paper and submission will need to be updated for the latest version of the software. Additionally, the version number does not match the version listed on PyPi (0.0.32 and the section titled development in the project documentation implies a different versioning scheme (e.g. webweb 4, 5) than what is listed on Github and described above, and the source code (webweb.py) indicates version 4). It is thus not clear if this project is using semantic versioning or some other versioning scheme, in addition to the version discrepancies outlined above - these should both be addressed before publication in JOSS. Lastly, I did not see any tagged releases on Github. It may be beneficial to tag the releases that are uploaded to PyPi on Github such that users can download the software directly from Github via a Release as opposed to having to clone or pull the repository.

Installation Instructions: The Github repository as well as the linked documentation provide instructions for installation via PyPi or by cloning the Github repository. After examining both setup.py, requirements.txt, and the source code from the project repository, it seems that the project does not contain any external dependencies but this is in fact not the case as numpy as a requirement for some of the functionality. The project dependencies should be documented in requirements.txt and clearly in the documentation and project readme.md.

Functionality: As indicated in the pre-review, I am only able to review this software's Python language functionality, specifically Python 3. The functionality works as described by the authors and I particularly like the functionality to view different layers of a network. I did notice a small detail that perhaps could be addressed in future versions of the software. When viewing multiple networks as described in the documentation examples, the viewing options (e.g. node color, size, etc.) are reset when transitioning from one network to another. It would be nice if the previous viewing options were saved in a from of cache so that users do not need to reconstruct a network's view when transitioning from one network to another. This isn't a big deal when using toy examples, but I can imagine some users may be frustrated if constructing a particular view in network A, transitioning to network B, only to find that the view is gone when transitioning back to network A. The ability to zoom into and out of a visualized network using the mouse or trackpad would be a welcome addition as well. Lastly, while the Highlight nodes named functionality works well, I think it may be more intuitive to place the Show node names checkbox above the free text field used to highlight particular nodes. I did not test for functionality in Python 2 - if Python 2 is not supported, this should be made explicit in readme.md or in the documentation.

I noticed a lot of use of Python's os library. While this works fine on Linux and Unix devices, it can result in errors on Windows machines. Using Pathlib in place of os would reduce the likelihood of errors on Windows. I am not able to verify the functionality of this software on Windows machines (the editor can decide whether this functionality on windows should be formally verified or whether this potential limitation should be listed in readme.md or documentation), but do know that Pathlib would allow the developers to normalize paths for Windows machines easily. Consider opening an issue with the tag enhancement.

Lastly, the GUI in webweb seems to share a lot of similar capabilities and features with the GUI used in netwulf. Although the aims of each software are different, both sets of authors could potentially reduce future development effort by collaborating on shared features and/or components.

Automated Tests: While I did see a test.py file which I ran successfully, the code contained therin could only be used to verify some of the functionality of webweb. Additionally, I did not see any form of automated tests. While writing automated tests for software that requires some form of user interaction presents its own unique challenges, revisions of this work should include a series of unit tests that can be used to verify the functionality of the software, through testing of function outputs, input and output formatting, etc. There are a variety of ways to write and use unit tests in Python, two of which are the pytest and pytest-cov packages - the former allows developers to execute unit tests (with helpful extensions for writing tests, too) while the latter provides functionality to pytest for coverage statistics, e.g. which lines of code your unit tests cover and the percentage of lines in each file (and overall, the package) that is covered by the written unit tests (this coverage statistic could be reported in readme.md). Additionally, if the authors looking to have others contribute to the project more easily in the future consider setting up a continuous integration pipeline that will automatically run tests and report the test results (e.g. using Travis CI) and coverage (e.g. using Coveralls) with any pushes to master or dev and for any pull requests opened by open-source contributors. This pipeline would ease the burden on making sure new additions and/or changes to software work as intended, and would also allow maintainers to formally test against every version of Python 3 that should be supported. This would allow the authors to state "this software works in Python versions 3.5 - 3.7" as opposed to simply stating "works in Python 3". In preparation for this, I have placed the test.py and related files in a directory called tests in my pull request.

Example Usage: The software documentation does include some examples on how to use the software, which I found helpful for reviewing the software's functionality. I also saw a section for real-world examples which is great!

References: paper.bib had all relevant references, but did not have all DOIs that are available for these references, so added a few and opened a this pull request. Specifically for the netwulf reference, the DOI is pending since it's currently under review by JOSS (#1425). The editor of this work should decide how to handle this reference and whether updating the paper.bib file post publication in JOSS is a possibility so that this reference's DOI may be included for this work once itself is reviewed and later published.

Community Guidelines: The Github repository as well as the documentation contains some guidelines on how to report issues and how to contribute to webweb's development which is great! It may benefit the authors / developers however to include more specific contribution instructions, such as asking users to first fork the repository and then create a new branch with a name that describes the issue or new feature before submitting a pull request. This may result in some additional organization. Additionally, while there is a section titled development in the documentation that serves as a historical record of software updates, it would be nice to include a changelog.md file in the project repository so that users and/or developers do not need to visit the documentation in order to see a record of project updates.

Other: I made a series of other small updates which are contained in the aforementioned pull request, such as moving imports to the top of the files, converting functions that don't use object attributes and functions to static methods, adding numpy to requirements.txt, and removing unused parameters from some functions. Additionally, while the paper does provide some acknowledgements, it would be nice to include the affiliations for those acknowledged in this section, if available.

@vc1492a

This comment has been minimized.

Copy link
Collaborator

commented May 27, 2019

@cMadan I have provided a view of webweb above - I'll be happy to review the software again once some of the above items have been addressed. In the meantime, please let me know if I can assist in any other way. Thanks!

@cMadan

This comment has been minimized.

Copy link
Member

commented Jun 3, 2019

@vc1492a, thank you for the thorough review! I really appreciate you being so detailed in your comments and suggestions.

@hneutr, please let us know when you've had a chance to make the suggested changes or have comments on them.

@hneutr

This comment has been minimized.

Copy link

commented Jun 5, 2019

Version Matching: The version number submitted to JOSS (0.0.29) does not match the latest version of the source code on the master branch in Github (0.0.30 as indicated in setup.py) - the JOSS paper and submission will need to be updated for the latest version of the software.

I've updated setup.py and unified the versioning scheme to match what is on PyPi. I've updated (after making — see point below) the changelog to reflect this versioning scheme.

I apologize if I'm missing where this is described, but I'm not sure how to update the JOSS submission.

Lastly, I did not see any tagged releases on Github. It may be beneficial to tag the releases that are uploaded to PyPi on Github such that users can download the software directly from Github via a Release as opposed to having to clone or pull the repository.

I agree this would be useful. I'm unfamiliar with the tagging process, but am reading up now, and have created an issue to represent this.

The project dependencies should be documented in requirements.txt and clearly in the documentation and project readme.md.

Done. I've updated the readme to point out the requirement of numpy, as well as clarified the index page of the documentation site to make clear that the visualizations have no dependencies, as opposed to the software used to generate those visualizations. Great point!

I did notice a small detail that perhaps could be addressed in future versions of the software. When viewing multiple networks as described in the documentation examples, the viewing options (e.g. node color, size, etc.) are reset when transitioning from one network to another. It would be nice if the previous viewing options were saved in a from of cache so that users do not need to reconstruct a network's view when transitioning from one network to another.

I absolutely agree. I think this pretty annoying. I've added a feature request to represent this, and quoted you as I think you convey the issue and solution well.

The ability to zoom into and out of a visualized network using the mouse or trackpad would be a welcome addition as well.

There's an issue for this — I agree that it would be really useful!

Lastly, while the Highlight nodes named functionality works well, I think it may be more intuitive to place the Show node names checkbox above the free text field used to highlight particular nodes.

No strong feelings to putting it above as opposed to below, but also not entirely sure how big a difference it would make. My general feeling is "if it ain't broke, don't fix it", especially with UI, but I'm certainly open to being convinced of otherwise. What draws you wanting it above?

If Python 2 is not supported, this should be made explicit in readme.md or in the documentation.

Added an explicit disclaimer that the code may not function in python 2.

Using Pathlib in place of os would reduce the likelihood of errors on Windows.

os has been removed in favor of Pathlib. Thanks for pointing me in the direction — this is definitely an improvement!

The GUI in webweb seems to share a lot of similar capabilities and features with the GUI used in netwulf.

I've talked to Dan, and I think collaborating with them is a great idea, and will be reaching out.

Automated Tests: Additionally, I did not see any form of automated tests. While writing automated tests for software that requires some form of user interaction presents its own unique challenges, revisions of this work should include a series of unit tests that can be used to verify the functionality of the software, through testing of function outputs, input and output formatting, etc.

I've added a bunch of automated tests that pytest will run! This covers 70% of the code.

If the authors looking to have others contribute to the project more easily in the future consider setting up a continuous integration pipeline that will automatically run tests and report the test results (e.g. using Travis CI) and coverage (e.g. using Coveralls) with any pushes to master or dev and for any pull requests opened by open-source contributors.

I agree that this would be desirable, and have opened an issue to represent this.

References: paper.bib had all relevant references, but did not have all DOIs that are available for these references, so added a few and opened a this pull request.

I've merged the pull request. Thank you for taking the time to add the DOIs!

Specifically for the netwulf reference, the DOI is pending since it's currently under review by JOSS (#1425). The editor of this work should decide how to handle this reference and whether updating the paper.bib file post publication in JOSS is a possibility so that this reference's DOI may be included for this work once itself is reviewed and later published.

@cMadan, is this something we can do?

It may benefit the authors / developers however to include more specific contribution instructions, such as asking users to first fork the repository and then create a new branch with a name that describes the issue or new feature before submitting a pull request.

Done!

it would be nice to include a changelog.md file in the project repository so that users and/or developers do not need to visit the documentation in order to see a record of project updates.

I added a changelog.md while to the github repo and replaced the development section with the same — these will automatically be kept in-sync, too. Thanks for the tip!

Other: I made a series of other small updates which are contained in the aforementioned pull request

Merged! Thank you again for taking the time to do this.

while the paper does provide some acknowledgements, it would be nice to include the affiliations for those acknowledged in this section

Added!

@hneutr

This comment has been minimized.

Copy link

commented Jun 5, 2019

@vc1492a thank you for your thorough review! I believe I've addressed your points — they were all excellent, and improved the software. The perspective of a seasoned python developer is much appreciated!

@cMadan I've responded to @vc1492a's review above!

I believe I hit everything mentioned, but if there's any points I've missed, please let me know and I'll circle back.

@vc1492a

This comment has been minimized.

Copy link
Collaborator

commented Jun 7, 2019

@hneutr Thanks for your detailed response! I've examined the updates and they look good to me. In reply to your question about what drives me to prefer that ordering on the UI, it just seems to be that a user would first toggle on the option to show node names before doing a secondary filtering.

@hneutr

This comment has been minimized.

Copy link

commented Jun 7, 2019

@vc1492a I buy your logic, and have swapped the widget positions!

@jg-you

This comment has been minimized.

Copy link

commented Jun 11, 2019

webweb is a neat little package that definitely addresses a need of the Network Science community.
It sets out to do one thing---lightweight and easy graph interactive graph viz---and it does it well, so I'm overall pretty excited about the project.

I have been using 0.0.18 in my work for a while, and updated to version 0.0.35, the latest release on PyPI, for this review.
I could not test the MATLAB interface either, because it is incompatible with octave (due to the use of jsonencode), the open-source alternative to which I have access.

Overall, the package passes almost all the checks with very few exceptions.
The review of @vc1492a covers most of the issues I could identify, so my report will be very short.

Version numbers: I'll second @vc1492a in saying that tagging releases on github would be nice, for a different reason:
PyPI does not send out update notifications, but it is easy to watch a github repository for releases.
As the maintainer of the AUR package for python-webweb, it would help me not let the package become out-of-date (as stated above: I was still on v0.0.18!).

Documentation: The examples listed on the website are fantastic for getting an intuitive grasp of what the package is doing.
If I have one comment, it is that the docstring of the all-important Web object could be improved.
It is hard to get a meaningful description of what Web does without going through the online examples because (1) there are no example nor exhaustive description of the interface in the docstring, and (2) the signature doesn't reflect its functionality (nx_G is passed as a kwargs to Network for example).
This is a minor pain point, but since Web is the main interface with the user, taking the time to document it better would improve their experience.
This is especially useful for users (like me!) that always forget what is the exact way to call a module ;)

Installation: The numpy dependency now appears everywhere on github 👍, but it could also be added to the installation section of the webweb website.


What is below is not part of my review per se, but just little comments.

Possible features?: Some things that would be great to have at some point.

  1. Multiple nodes highlight in the GUI (say, with a comma separated list). As far as I can tell, the user can only highlight one node at a time in the current build.
  2. CLI interface. When I want to visualize a small network file, I'll typically boot up an ipython instance, import networkx and webweb, then I'll load the network and I'll finally visualize it. A neat improvement could be to add a main to webweb and make it callable from the CLI directly, e.g. ẁebweb network.edgelist would load network.edgelist and open the browser to the webweb page.
  3. Use an open-source alternative to jsonencode in the MATLAB interface to make webweb accessible to octave users.

Minor things: Consider maintaining the author information in __version__, __authors__, etc., dunders string. Consider adding a hash to the webweb.html page so that many instance can be ran and refreshed without overwriting one another.

@jg-you

This comment has been minimized.

Copy link

commented Jun 11, 2019

@cMadan My review is above! Thanks for your patience everyone.

@hneutr

This comment has been minimized.

Copy link

commented Jun 18, 2019

Hey @jg-you! Thank you for the thorough review, and the great suggestions. Responses inline below:

tagging releases on github would be nice

Upping this priority.

the docstring of the all-important Web object could be improved.
(1) there are no example nor exhaustive description of the interface in the docstring
(2) the signature doesn't reflect its functionality

done in 0.0.37!

The numpy dependency could be added to the installation section of the webweb website.

Added.

Multiple nodes highlight in the GUI (say, with a comma separated list)

Made an issue.

CLI interface. A neat improvement could be to add a main to webweb and make it callable from the CLI directly, e.g. ẁebweb network.edgelist would load network.edgelist and open the browser to the webweb page.

I think this is an awesome idea, very much inline with the "spirit" of webweb. Issue here.

Use an open-source alternative to jsonencode in the MATLAB interface to make webweb accessible to octave users.

Made an issue.

Consider maintaining the author information in version, authors, etc., dunders string.

done in 0.0.37.

adding a hash to the webweb.html page so that many instance can be ran and refreshed without overwriting one another.

done in 0.0.37.

@jg-you

This comment has been minimized.

Copy link

commented Jun 21, 2019

@cMadan: @hneutr applied all the changes (and more) highlighted in my review.

@cMadan

This comment has been minimized.

Copy link
Member

commented Jul 2, 2019

@vc1492a @jg-you, thank you both for your thorough reviews, I greatly appreciate it!

@hneutr, it looks like you're still not using GitHub releases? (And I don't see a response to that suggestion.)

The netwulf DOI will be 10.21105/joss.01425. I am fine with you citing it here, with this DOI (even though not officially registered yet) as it will resolve as a citation to the other package once it is published.

Otherwise I think the review is nearly done and I just need to do some final checks.

@hneutr

This comment has been minimized.

Copy link

commented Jul 8, 2019

@cMadan:

I've added the netwulf DOI to the paper.bib file. I've also tagged the most recent release on GitHub, and will continue to tag commits that are pushed to PyPi.

Let me know if there is anything else that needs to be done!

@cMadan

This comment has been minimized.

Copy link
Member

commented Jul 30, 2019

@hneutr, everything looks good to me!

To move forward with accepting your submission, there are a few last things to take care of:

  • Make a tagged release of your software, and list the version tag of the archived version here.
  • Archive the reviewed software in Zenodo
  • Check the Zenodo deposit 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.
  • List the Zenodo DOI of the archived version here.

You may find this helpful: https://guides.github.com/activities/citable-code/

@hneutr

This comment has been minimized.

Copy link

commented Aug 12, 2019

Hi @cMadan!

  • There's a tagged release here. The released version is 0.0.37.
  • Here is the zenodo upload! Author information matches.
  • The zenodo DOI is: 10.5281/zenodo.3366140

Is there anything else that needs to be done before publication?

Best,
Hunter

@cMadan

This comment has been minimized.

Copy link
Member

commented Aug 12, 2019

@whedon set 0.0.37 as version

@whedon

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 12, 2019

OK. 0.0.37 is the version.

@cMadan

This comment has been minimized.

Copy link
Member

commented Aug 12, 2019

@whedon set 10.5281/zenodo.3366140 as archive

@whedon

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 12, 2019

OK. 10.5281/zenodo.3366140 is the archive.

@cMadan

This comment has been minimized.

Copy link
Member

commented Aug 12, 2019

@hneutr, great! I think you're all good!

@openjournals/joss-eics, we're all set to accept here!

@danielskatz

This comment has been minimized.

Copy link

commented Aug 12, 2019

Thanks to @vc1492a and @jg-you for reviewing and @cMadan for editing!

@danielskatz

This comment has been minimized.

Copy link

commented Aug 12, 2019

@whedon accept

@whedon

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 12, 2019

Attempting dry run of processing paper acceptance...
@whedon

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 12, 2019

Check final proof 👉 openjournals/joss-papers#898

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

@whedon accept deposit=true
@danielskatz

This comment has been minimized.

Copy link

commented Aug 12, 2019

there's a bib typo, fixed in dblarremore/webweb#53
Please merge this or otherwise fix it, then we can finalize the acceptance.

@danielskatz

This comment has been minimized.

Copy link

commented Aug 12, 2019

👋 @hneutr - the above comment is for you - sorry I didn't put your handle on it

@dblarremore

This comment has been minimized.

Copy link

commented Aug 12, 2019

@danielskatz I just merged it. Good catch.

@danielskatz

This comment has been minimized.

Copy link

commented Aug 12, 2019

@whedon accept

@whedon

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 12, 2019

Attempting dry run of processing paper acceptance...
@whedon

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 12, 2019

Check final proof 👉 openjournals/joss-papers#899

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

@whedon accept deposit=true
@danielskatz

This comment has been minimized.

Copy link

commented Aug 12, 2019

@whedon generate pdf

@whedon

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 12, 2019

Attempting PDF compilation. Reticulating splines etc...
@whedon

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 12, 2019

@danielskatz

This comment has been minimized.

Copy link

commented Aug 12, 2019

@whedon accept deposit=true

@whedon

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 12, 2019

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

@whedon whedon added the accepted label Aug 12, 2019

@whedon

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 12, 2019

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

@whedon

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 12, 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 👉 openjournals/joss-papers#900
  2. Wait a couple of minutes to verify that the paper DOI resolves https://doi.org/10.21105/joss.01458
  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

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 12, 2019

🎉🎉🎉 Congratulations on your paper acceptance! 🎉🎉🎉

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

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

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

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:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.